20
Expand DMARC Options/Scoring
Idea shared by kevind - 5/10/2024 at 1:52 PM
Under Consideration
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!

21 Replies

Reply to Thread
5
Yes, I have asked for this as well.  Ticket 2DD-2D39507C-0B13 from January
5
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.
4
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!
3
+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)
2
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.


5
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)
4
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)
6
Yes, 12 votes!  Would be good to make this Under Consideration or In Progress.
3
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)
5
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
3
Zach,
Great – 15 votes!
Thanks!
3
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!
4
+1
3
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)
3
Yes, Happy Birthday to this idea -- 1 year old with 19 votes!
Hoping SmarterTools flips it from Under Consideration to In Progress.
Thanks!
0
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
0
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.   



0
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
0
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.
0
"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)
2
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

Reply to Thread

Enter the verification text