Hey Sébastien,

Thank you for reaching out regarding your concerns with SmarterMail Beta's DMARC settings. I appreciate your interest and attention to detail on this matter.

After reviewing your inquiry, I would like to provide further clarification on your understanding of DMARC reject and quarantine policies. You are correct that a DMARC reject policy will cause the email to bounce if both DKIM and SPF checks fail. On the other hand, a DMARC quarantine policy will still allow the email to be processed by spam filtering, but with a higher weight.

Regarding the DMARC none policy, it means that no action will be taken on the email if DMARC checks fail. However, it is important to note that normal spam checks will still be applied, as opposed to being skipped, as in the case of the quarantine policy.

I understand that you attempted to disable the DMARC compliance check, but it was still active upon your return to the settings page. This issue is unfamiliar to me, and I would like to request that you open a ticket so we can investigate this matter further.

To clarify, the DMARC compliance check adds extra weight when the policy is set to quarantine, and not when it is disabled. Here are the possible scenarios for DMARC compliance:

I hope this clarifies your concerns. Please let me know if you have any further questions or require further assistance.

Thank you for your time and attention.

Best regards,

Hello Zach,

Thank you for your detailed clarification. It is now clear for me.

I was kinda misled by the "no actions will be taken" as it first sounded to me like it would skip antispam checks and be delivered right away, which seemed strange.

About the the DMARC spam setting not being saved. I can reproduce it like this:

- Go to Settings > Antispam > Spam checks

- Click on DMARC and toggle it off, then [ save ].

Then shift-reload the page and go back to Spam checks. It's on again.

However, if I change the weight and click save, the new weight seems to be saved and is kept even after doing a shift-reload.

One strange thing is that I cheked the settings.json file right after clicking [ save ] and it is indeed saved to "false":

Still, right after a shift-reload it's also back to "true" in the settings file.

The very same happens if I set DMARC to off then [ save ], logout of the admin and log in again.

It is set back to enabled. Looks to me like some kind of "default" value for the setting that is applied when the web interface is (re)loaded.

Let me know if you still can't reproduce it, i'll go on and open a ticket so you can take a look on our test server.

Kind regards.

But what happens when you get DMARC FAIL on a message that you want?    The design needs an exception management process.

Doug Foster

Hey Sébastien, 

Also, please keep in mind that SmarterMail did already have DMARC handling in previous builds. In the BETA, we have simply added support for the Quarantine policy. To elaborate: 

In the public build, we had an Antispam setting for 'Enable DMARC policy compliance check'. If the email failed DMARC, and the sender's policy was set to Reject, we would reject the message in SMTP. If the sender's policy was set to Quarantine or None, we did nothing extra with the email. It was delivered and managed via standard spam filtering. 

In the BETA build, we've removed the Antispam setting for 'Enable DMARC policy compliance check', and we've replaced it with a new DMARC spam check which now handles the Quarantine policy as well, as Zach described above. If someone would prefer not to implement the new handling for the Quarantine policy, they can simply change the Quarantine Weight to 0, and the DMARC check will continue to act as it currently does in the public build.

I hope this helps to clarify. 

Violations of my own DMARC policy

First of all, there are acceptable impersonators.    Assume you get a secure email  from a ProofPoint or IronPort customer, and your or another non-customer sends a reply.   These vendors will use the unmodified  non-client address as the From address, violating DMARC.  (The default is to send the sender a copy of the message.)   I have opened a ticket with the CIRT offices of both companies, and nothing has happened.   (I think they assume that they are important enough to get a pass.)

A US Government website that we use allows users to request document delivery by email.  It asks for both the sender email address and the recipient address, without restriction.   Our users use it to send documents to themselves.

Forwarded mail

Messages which are not DKIM-signed will fail DMARC if they are forwarded.   Naturally the sender should sign everything, but some are sloppy.

Messages which are forwarded through an Email list will often be tagged with additional content in the Subject, Body, or both.   This will of course invalidate DKIM signatures.   Just the same, the message may be acceptable to users who participate in those forums.

RFC 7960 is a formal discussion of the problem with unwanted FAIL, mostly focused on forwards.   

RFC 8617 defines the ARC protocol, which attempts to solve some of the problems with loss of credentials as a result of forwarding.

Exception Management

DKIM is not likely to be useful for exceptions, so my exceptions are based on the SMTP MailFrom address.

DMARC is based on a verified MailFrom address having an acceptable relationship to a From address.   The standardized relationships are "strict" (exact match) and "relaxed" (same organization), but the concept is easily extended.   My exceptions are of the form:

(MailFrom is trusted for a specific From address):

"When Mailfrom is verified and Mailfrom = <value> and From = <value> then treat the message as equivalent to DMARC PASS."

or

(MailFrom is trusted to impersonate but never impersonate maliciously):

"When Mailfrom is verified and Mailfrom = <value>,  then treat the message as equivalent to DMARC PASS."

SPF has even more problems, but the solution is similar:

When Sever is a specific value and verified, then treat specific or all MailFrom domains as equivalent to SPF PASS.    For servers, the Source IP is assumed to be true.   HELO or REVERSE DNS can be verified by forward-confirmed DNS.   Filtering on server domain is usually preferred.

Extending DMARC

As defined, DMARC is useless until the domain owner publishes a policy with a value other than None.   In practice, many messages can be given the equivalent of DMARC PASS without worrying about the policy.    The SPF and DKIM alignment tests only depend on your choice of alignment rules, and this is a decision that can be mode as a matter of local policy as a substitute or override for domain owner policy.   A high percentage of messages will produce DMARC-equivalent PASS, even without a policy.

This becomes important because some messages need to be whitelisted (allowed to bypass content filtering), and it is crazy to whitelist an address without ensuring that the address is not impersonated.    Senders that needs whitelisting are not perfectly correlated with vendors that publish DMARC p=reject, so we need a way to assess authentication on any message. 

Effectively, there are three types of sender authentication:

- Explicitly verified based on domain owner information published in DNS, using SPF and/or DMARC.

- Explicitly verified by local policy

- Implicitly treated as verified by allowing the message to be delivered to the user, on the assumption that malicious impersonation is a tiny portion of all mail.

Doug Foster