Expand DMARC Options/Scoring
Idea shared by kevind - 5/10/2024 at 1:52 PM
Planned
Currently you can enable DMARC for incoming mail and enter a single score if it's suspicious. But  that seems limited as there are quite a few DMARC results. Suggest the DMARC section be expanded to accomodate the many results:
  • DMARC: [none]
  • DMARC: [failed]
  • DMARC: [passed]
  • DMARC: [skipped] (multiple reasons)
Might make sense to provide a score for each of the above, and passed would be a negative number.

Google and Yahoo now require domains to have DMARC, so let's give SmarterMail the ability to do the same thing. If a spammer sends email with no DMARC, I want to reject or give it a high score. Thanks!
Yes, I have asked for this as well.  Ticket 2DD-2D39507C-0B13 from January
Yes, +1 let's vote this up.

Would be nice to set DMARC [passed]: -5
just like you can specify DKIM [Pass]: -5

Also, curious about the "_ARC: none" in the header. Not familiar with that.
Also, this feature would be nice for blocking spam from onmicrosoft.com domain as most of it doesn't have DMARC.

So when you see this line in SMTP:
DMARC Results: None (Domain: , Reason: No DMARC record found), Reason: No DMARC record found, Reject? False
You could assign it 10 to 20 points!
+1
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
The SmarterMail implementation follows RFC 7489, which is a big problem, because the RFC leads people to make poor decisions.   It implies that Fail with p=Reject is always unwanted, which is false.   IETF wrote a whole RFC on the problem  (RFC 7960).    The RFC also implies that any other Fail is not actionable, which is also false.  

Since 95% of all domains lack a p=reject policy, ignoring No Policy and Fail with p=none will  leave you vulnerable to 95% of all detectable impersonation attacks.  A completely different approach is recommended.

  1. A message is authenticated if it has "Aligned SPF Pass" or "Aligned DKIM Pass".   This test can be applied to every message, using a default alignment rule of relaxed.    It is stupid to ignore this important information simply because the domain owner has not published a policy.   (This approach is predicted to jump your authentication rate to about 85% of all incoming messages.)   When this criteria is satisfied, it becomes safe to flag a Trusted Sender or a BIMI image, because impersonation has been ruled out (within the limits of the technology.)

  2. If a message cannot be authenticated, you are at risk of a malicious impersonation attack.  You either hope to luck that your content filtering will catch the malicious attackers, or you do the hard work of investigating the authentication failure.   I refuse to delegate my network security to strangers, so the stranger's DMARC policy has no impact on how I respond.   My commitment is to investigate EVERY authentication failure.

  3. Authentication failure is ALWAYS an ambiguous result.  You need to investigate the root cause to eliminate the ambiguity so that you will never have to do so again.    Two results are possible:

    1. The message originator is malicious, or otherwise unwanted, so you block the identifiers that represent the message originator.  Now you are protected even if the attacker uses a different attack technique.

    2. The message author is acceptable, so you create an alternate authentication rule that represents the acceptable entity.   
      1. A rule based on server name, verified with fcDNS, can provide proxy authentication for the accompanying "Mail From" address, mimicking the design of SPF.  
      2. A rule based on Mail From domain, verified by SPF or local policy, provides proxy authentication for the From address, mimicking the design of DMARC.
Because future messages will either be blocked by local blacklist policy or verified by local authentication policy, you never need to worry about this ambiguity again.

When the message is authenticated by local policy, the message should be given a custom header to indicate successful authentication.   Then SmarterMail can detect the custom header so that Trusted Sender and BIMI image features can be activated.

I had to build the alternate authentication rule structure using Declude and SQL, because you build long lists and  you are creating 3-attribute authentication rules (underlying identifier, verification result, and proxy authenticated identifier.)  

The implementation process was manageable because I had a good message review tool in my Barracuda appliance.   In the beginning, I let Declude flag the authentication results while relying on content filtering alone.   Then I investigated unauthenticated traffic after it was released to the user.   The process converged pretty quickly, at which point I was able to make authentication mandatory, with unauthenticated messages being sent to quarantine (never to Block!)

Authentication does not solve all problems.   I still have to contend with authenticated-but-unwanted messages, mostly from Gmail, that are sent from computer-generated accounts created for one-time use.   But it helps block most everything else. 

In the short term, what I want SmarterMail to do is to drop the "ALWAYS BLOCK ON FAIL" rule.   This will at least allow me to activate SmarterMail DMARC processing, s that I can take of Trusted Sender and BIMI when their standards-based design generates a PASS result.  But I will not turn it on anything that forces me to block wanted messages.


I think the best thing would be to have a (customizable) list of scores based on the result (DMARC result + domain DMARC policy setting), for example these:

DMARC Pass: 0 or whatever you want (also negative like -5 if you want)
DMARC Fail (policy "none"): 5 or whatever you want
DMARC Fail (policy "quarantine"): 10 or whatever you want
DMARC Fail (policy "reject"): 20 or whatever you want
DMARC not set/nonexistent: 5 or whatever value you want

If there are other possible combinations, they should be added
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
If possible, I would ask SmarterTools to review this request and give us feedback on whether it is possible to implement it.

It would be very, very useful and I think it would greatly increase SmarterMail's ability to block SPAM.
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Yes, 12 votes!  Would be good to make this Under Consideration or In Progress.
Is there anyone who can tell us whether this is feasible or not and whether it will be considered?
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Zach Sylvester Replied
Employee Post
Hello, 

Thank you guys for the suggestion. I have submited this as a feature request in our system. We will keep you guys updated with the status of the feature request. 

Kind Regards, 
Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
Zach,
Great – 15 votes!
Thanks!
Bump for March – 17 votes!

Often messages from Amazon (smtp-out.amazonses.com) get tagged as Spam because they show up on so many RBLs.  Being able to assign -4 points to "DMARC Pass" messages would resolve this.

Thanks!
+1
news?

Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Yes, Happy Birthday to this idea -- 1 year old with 19 votes!
Hoping SmarterTools flips it from Under Consideration to In Progress.
Thanks!
Zach Sylvester Replied
Employee Post
Hey Guys, 

Thanks for your patience on this. I will bring this up in our next meeting. 
@Gabriele, 
Regarding what. you posted here. 

DMARC Pass: 0 or whatever you want (also negative like -5 if you want)
DMARC Fail (policy "none"): 5 or whatever you want
DMARC Fail (policy "quarantine"): 10 or whatever you want
DMARC Fail (policy "reject"): 20 or whatever you want
DMARC not set/nonexistent: 5 or whatever value you want

For reject why would we want to give it a score instead of just rejecting the email?

Kind Regards, 
Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
Because DMARC is a heuristic, and every heuristic is presumed to have errors in both directions.

Mailing lists typically add content when replicating a message.  SmarterMail mailing lists have this feature as well.  Usually the mail From address is rewritten to the list bounce address, which provides SPF pass by not SPF alignment.   Content changes break DKIM signatures, so the message produces DMARC fail.  After a major breach at Verizon 10 years ago, they changed the DMARC policy for all of their domains to p=reject, causing great turmoil to mailing lists everywhere, especially at IETF, which does everything through lists.

The result of that pain is documented in RFC 7960.   Your implementation should have been informed, from the beginning, by both RFC 7489 and RFC 7960.

Another situation applies to email service providers (ESPs), notably sendgrid.net, that send mail on behalf of clients but do not obtain a DKIM private key from those clients. The Mail From account is the ESP domain so that they can track delivery statistics. This provides SPF Pass but not alignment.  The message From address indicates the client, who has been authenticated with login credentials, but authentication cannot be proven because of the missing DKIM signature.  This means that the message is not verifiably authenticated, even though it is not impersonated. 

Finally, there is some impersonation that is not malicious.  These messages typically come from a website where the user has been authenticated by their email address, and then the user takes an action that causes a message to be sent on his behalf using his email address.   It is poor from for websites to do this, but such websites exist.   One such site is run by the US Government.  Several secure email services have been observed with this problem, when a non-client responds to a message and asks for a self-copy of the reply.   Fortunately, I think those observations are out of date, because the services have changed their processes to avoid impersonation.

Overall DMARC Fail is a complex problem, for which weighting instead of automatic reject is the starting point.   The system admin needs to be able to distinguish between the two types of failures:   Acceptable failures that come from acceptable mailing lists or acceptable ESPs and should be allowed based on a rule in local policy.   Unacceptable failures which represent malicious impersonation should be rejected, and the rejection should occur whether the policy is p=reject, p=none, or "no policy".

On the topic of "No Policy", I would also ask for an option to enable "Best Guess DMARC".  This strategy applies the DMARC test, with relaxed alignment, when there is no published policy.   This helps to document that most messages are judged free of impersonation risk, and to identify the subset that cannot be verified by that method alone.   This enhances the ability to affirm trusted sender and trusted images.

To complete the discussion, I will note that false Pass is uncommon, and extremely difficult to detect, so that risk is largely ignored.    Explaining the detection process would need to be a separate discussion if anyone cares.   



Matt Petty Replied
Employee Post
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. I'd say it's not necessarily meant to act as a spam check/heuristic. It really should not fail. One small thing I actually liked the cloud providers doing was enforcing DMARC that way people would finally be inclined on getting it passing for their domains. It failing is a common issue with missing IPs on a IP Bypass list, or misconfigured gateways and sending servers. 

It also drives a lot of other non-spam based functionality like trusted senders, ARC (forwarding reliably), BIMI (another authentication mechanism), and the "green"-trusted checkbox.

Another small note. "reject" is elected by the domain thats getting rejected. Those system administrators want their emails to be rejected if it fails DMARC, this is clearly written into the spec and is the [Conformance] in DMARC. 

*We do have a plan to discuss this though as a team as Zach mentioned earlier.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
The sender policy is a request.   The decision whether to follow or ignore the request is the option of the recipient system administrator, not the developer.   

Consider in particular the case of p=quarantine.   How do I tell the system that I have evaluated the quarantine issue and I know which identifier sets are acceptable, which are unacceptable, and which are unresolved?   Any specific instance of quarantine should be a one-time event, because after the review, the system should be told how to unambiguously handle the next message with the same characteristics.

Soapbox:
All human communication is interpreted in the context of the speaker or author, and the message From address indicates the purported author of an email message.  If the author identity is fraudulent, the message is inherently a threat.  Therefore, every allowed message should be authenticated.  The need for universal authentication means that we need the ability to test every From address, which is why we need what I called Best-Guess DMARC.

Any message without authentication may or may not be an Impersonation, but the risk should not be ignored.  The only way to know the truth is to collect more data by reviewing the message details, contacting the recipient, or contacting the sender.   In short, one-time quarantine is the optimal disposition for any unauthenticated From address.   Sender disposition recommendation is irrelevant.

If quarantine review determines that a message is unacceptable for any reason, the relevant sender identities get blacklisted.   If you block a fraudulent message without investigating to identify the fraudster, you have wasted an opportunity and put yourself at risk for a future penetration when the attacker changes tactics.   

If quarantine review determines that a message is acceptable, an alternate authentication rule is needed to identify the acceptable message.  To prevent successful impersonation, this alternate authentication rule must be based on a verified identifier and whatever other identifiers occur with it.  This is not whitelisting, because alternate authentication does not imply exemption from content filtering.   Whitelisting is a separate decision from alternate authentication.  Whitelisting should never occur without authentication, because doing so creates a security hole --  an impersonation of the whitelisted address will cause the message to bypass both authentication tests and content tests, allowing the message to go straight to the payload detonation target.  Unfortunately, whitelisting without authentication is the only option provided by most "security" products.

Without universal authentication, DMARC provides fake security.  At its best, it forces an attacker to impersonate Yale.edu instead of Citibank.com.  Citibank may consider this a win, but it is not a win for the recipient domain.   If my organization is devastated  with ransomware deployed through impersonation, I will be too busy with damage control to care which company was the one impersonated.

What's worse, DMARC provides lots of ways for the attacker to collect public information to determine which domains he can successfully impersonate.   Because too many people follow the same strategy used by SmarterMail development, an attacker can assume that any domain with "p=none" or "no policy" is fair game.  To test things ever further, he can send a test message that impersonates a domain under his own control, then wait to see what data is returned in the SMTP response and what data is sent back to the "victim" domain in an aggregate report or failure report.   Since most organizations do whitelisting for their most important correspondents, and most security products do whitelisting without authentication, the attacker can form a pretty good idea about the best impersonation domain to ensure penetration of your network.

The only defense against this is to use DMARC to ensure that all messages are authenticated.    This can be done because I have done it, and have been running in this mode for a  couple of years. It has protected me from a lot of stuff, both malicious and merely unwanted.  There are some shortcuts to minimize quaranine effort, but this document is already long enough.

I don't need SmarterMail DMARC for authentication, but I do need it for BIMI.  But I cannot turn on BIMI because I don't want automatic reject.  That is why I need weighting instead of auto-reject.
"For reject why would we want to give it a score instead of just rejecting the email?"

Because I, as a user/administrator, want to have maximum freedom of choice in this regard.

So, if I really want to reject the message in the event of a DMARC "reject", I'll set a very high score, which will automatically cause the message to be rejected.

Otherwise, again because I want it, I might want to set a score slightly lower than the reject limit, so that the email isn't automatically rejected, but it will be if the score is combined with other SPAM indicators.
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Zach Sylvester Replied
Employee Post
Hi everyone, just a quick note to let you know we haven’t forgotten about this! Your feedback around per‑result DMARC scoring, handling of “p=reject” is still under active review by our team. We’ll update this thread as soon as we have more to share. Thanks again for all the votes and detailed suggestions!
Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
Matt Petty Replied
Employee Post
We've done reviews and brought our findings together, we've had a couple discussions as a team on this and another another yesterday. We've also added weights for "quarantine" status already, we feel like we could add another optional weight for a NONE/Missing DMARC record. But we have decided against making any other changes to DMARC. 

DMARC is not a spam check (the abstract of the RFC that defines DMARC mentions this), it's not meant to serve as this kind of filter but as a policy enforcement tool. Also to accurately represent both sides of this discussion I should say, the RFC DOES leave open overriding reject (section 6.7). There will be administrators on both sides who would want this to work the way they wish. Some will want to override reject, other's want their policy respected. We've chosen to just simply leave it as it is right now.

We'll continue to review feedback and talk about posts as we get it but for now, again we're just going to add 1 additional weight for a missing DMARC record and nothing else, keeping SM's current behavior intact. I will mark this thread as PLANNED since this means we will be making additional changes. We should probably create a new topic to change the reject behavior specifically if we wanna continue discussing it so we can more accurately track the status of that desired change.

PS. We did have a note on our discussion topic about implementing the reporting mechanisms of DMARC however, I realize now after typing this up that we didn't get a chance to come to a conclusion on doing this work. I feel like we could also do this, since we're trying to stick to the RFC, I will bring this up with the others to double check if it's okay that we do this.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
Matt, thanks for looking into this and adding a portion of the request to the Planned list! It would be nice to have scoring for all the options (and with 22 votes, others likely agree). But we'll take it one step at a time.

Spammers are finding more ways to deliver junk and we're just looking for additional ways to stop them. Often they don't mess with DMARC, so having a few ways to score this would be very beneficial.  Yes, DMARC isn't a spam check, but most major providers now require DMARC. So why not it would be nice to use it to determine the quality of a message?

For example, here's something I've been seeing lately. Would be nice to score this with some points instead of defaulting to 0. 
  • DMARC [skipped - No Return Path]: 0
Thanks for the consideration and look forward to a future build with this additional DMARC scoring capability.
Just thought of this -- doesn't DMARC use the results of the SPF check (along with DKIM results) to enforce a policy, like reject the message or mark it as fake?

SmarterMail has the option to enter 6 different weights for SPF: Pass, Fail, Soft fail, Neutral, Permanent error, & None.

Why not do the same thing for DMARC?  Just a thought.  Have a nice weekend!
I am very disappointed.    The DMARC policy is a suggestion.   Some random domain owner does not have the authority to decide what I allow or block, that decision is mine and mine alone.

One of the many problems with DMARC is the strange notion that a malicious impersonation of Yale.Edu (assumed p=none) is less important than a malicious impersonation of Citibank.com (assumed p=reject).   Because of DMARC, Yale.Edu is the more common impersonation target in my mail stream.   All malicious impersonation needs to be blocked, and some non-malicious impersonation needs to be allowed.   DMARC is a starting point for that problem, but woefully incomplete as a solution.

A sufficient email filtering solution requires (a) a really good message review tool, and (b) a sophisticated rules engine for documenting the results of quarantine review.   An example rule would be:
 "block unauthenticated messages from *.edu except from messages received with SPF Pass from listserv.utah.edu"   SmarterMail is not close to being a sufficient email filtering solution, and I don't expect you to change that.

Consequently, the sufficient email filtering system needs to happen upstream, on an incoming gateway, which may or may not use SmarterMail as the transport.   All that I want the mail store server do is check for DMARC Pass, for the limited person of flagging Trusted Sender and BIMI status.  Nothing more.   Can you give me that? 
OK, I understand your point and (with great difficulty) accept it...

But I'm really disappointed because, in my opinion, it could have been a really good idea to increase SmarterMail's strength compared to its competitors.
Furthermore, making this feature configurable (perhaps even at the domain level, if possible...) would have eliminated any disputes among potential administrators:
- Do you like it? You configure it and use it as you wish.
- Don't like it? You disable it entirely.


I Agree with KevinD when he says:
<<<<
SmarterMail has the option to enter 6 different weights for SPF: Pass, Fail, Soft fail, Neutral, Permanent error, & None.

Why not do the same thing for DMARC?
>>>>


I hope you change your mind in the (near...) future, but in any case, I congratulate you on the consistently excellent work you do!
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Do not waste effort on penalizing for absence of a DMARC policy.   That is a useless and probably harmful metric.

"Useful" is to apply a default DMARC policy (p=none, aspf=r, adkim=r) when one is missing.    Performing that test will show that most messages without a DMARC policy are not impersonations.  It is not the policy that makes a message authenticated, it is the SPF and DKIM results.

The goal for authentication is to eliminate impersonation.  The only way to eliminate impersonation is to authentication all allowed messages - 100%.  Most spam filters fail because they do not even attempt to provide a glide path toward 100% authentication.

To the specific issue of blocking on authentication failure:   Assuming that the content of a blocked message is discarded without review, it is always a suboptimal action.
- Because most messages are authentic, with or without DMARC, blocking on authentication failure will cause the organization to lose a lot of acceptable traffic.
- For the subset of messages that are malicious impersonations, blocking on authentication failure allows the impersonator to remain undetected, so that he can attack a different way on a different day. 

Consequently, the optimum response to authentication failure is ALWAYS quarantine, leading to one of these results:
1) The message is a malicious impersonation.   Determine the impersonator and blacklist him.
2) The message is legitimate and acceptable.   Create an alternate authentication rule in local policy.
3) The message is legitimate but unwanted.  Create a block rule on the sender.
Whatever the decision, the quarantine investigation produces a permanent disposition rule.

One implication of this principle is that the DMARC policy is important only for the alignment rule.  I think even that datum is unimportant, so I don't bother to check for DMARC policies at all.  It seems like wasted overhead.

If an organization is unwilling to put the effort into quarantine review to attain 100% authentication, then they are choosing to remain vulnerable to ransomware and other malicious acts.

There are perceived feasibility issues in getting to 100% authentication.   Spam filter  inadequacy is the most significant obstacle.   All of the feasibility concerns can be addressed, but that is a longer discussion.

Reply to Thread

Enter the verification text