DMARC brainstorming

Discussion re sg development. You don't have to be a developer.

DMARC brainstorming

Postby josh » Thu May 04, 2017 10:19 pm

As you know, gmail's (and others') recent stricter enforcement of DMARC checking is causing non-delivery of messages from spamgourmet, and other places.

There are two DMARC issues that I have seen cause problems - there may be more.

1) DKIM failure -- the message is cryptographically signed to help detect changes that may have occurred to it in transit - certain message headers, including the "FROM:" and "SUBJECT:" lines are included in the signature. When we modify those headers, either with reply address masking to change the From: address or with our Subject tagline (for example: (word: msg 1 of 4)), we break the cryptographic integrity of the message and it fails the check.

workaround: currently the code disables the check by renaming the DKIM signature to be the "Original-DKIM" signature. Not proud of it, but it works to get the message delivered. The downside is that there's no checking - if another third party modified the message before it got to us (or after), the recipient might think it didn't happen because the message didn't fail a DKIM check (at least there won't be anything saying that the message has passed a DKIM check either). This seems unlikely to cause a real problem, but the scenario could become more important as time goes on.

2) SPF failure -- where reply address masking is *not* enabled, we don't change the From: address, and the user's email service checks that our IP address is permitted to send email that is apparently "From" the domain of the sender's email address. Often the result is 'none', 'neutral', or 'softfail' (and very rarely 'pass'), and these don't cause issues, but for some domains, the result is 'fail'. Gmail currently rejects these messages.

workaround: for now, I'm advising people to turn on reply address masking if they're having trouble - the From: address is replaced with one of our redirection addresses and the domain of the redirection address, ob.0sg.net, gives a 'pass' result with respect to our IP addresses. One downside here, of course, is that if the original sender would have failed SPF if the message had gone direct, once the redirection occurs that problem will go away - in fact, there will be a 'pass' result in context. Again, pretty esoteric, but as time goes on, could become more important.

I'm trying to figure out how to get ob.0sg.net to return 'neutral' for our IP addresses and 'fail' for everything else, but so far it doesn't look like you can do that with SPF - if anyone knows otherwise please let me know. Another possible option is to just clear the SPF records for the domain - that might be the best approach, although it could lead to additional delivery rejections.

There's a developing specification for 'ARC' "Authenticated Received Chain" protocol which will address these intermediary DMARC difficulties - I think it's still in draft, and there's no guarantee that the gmails of the world will do anything differently if presented with valid ARC records -- we will need to pay attention to this and evaluate the cost of an implementation in terms of server load against the possible but speculative benefit of better downstream delivery.

I'll post more soon.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: DMARC brainstorming

Postby milkbadger » Sun Nov 05, 2017 5:07 am

josh wrote:1) DKIM failure -- the message is cryptographically signed to help detect changes that may have occurred to it in transit - certain message headers, including the "FROM:" and "SUBJECT:" lines are included in the signature. When we modify those headers, either with reply address masking to change the From: address or with our Subject tagline (for example: (word: msg 1 of 4)), we break the cryptographic integrity of the message and it fails the check.

workaround: currently the code disables the check by renaming the DKIM signature to be the "Original-DKIM" signature.


This doesn't look to me like it would fix many delivery problems (and in cases where spamgourmet isn't changing headers, it will hurt). Removing the DKIM-Signature changes the message from having an invalid signature to being unsigned; it doesn't necessarily disable a check by the recipient. Whether the message gets delivered depends on how strict the original sender's DMARC policy is (do they require valid DKIM?) and whether the recipient's system is enforcing DMARC.

(There is a separate issue of whether spamgourmet itself should be enforcing DMARC by not forwarding messages that fail the sender's policy; I think that's not what you're talking about here.)

josh wrote:There's a developing specification for 'ARC' "Authenticated Received Chain" protocol which will address these intermediary DMARC difficulties - I think it's still in draft, and there's no guarantee that the gmails of the world will do anything differently if presented with valid ARC records -- we will need to pay attention to this and evaluate the cost of an implementation in terms of server load against the possible but speculative benefit of better downstream delivery.


Gmail has begun to roll out support for it (you can see ARC headers now in messages that they handle). I think adding ARC support to spamgourmet is likely to be the best way forward.
milkbadger
 
Posts: 18
Joined: Sat Feb 23, 2008 8:26 pm


Return to Developers

Who is online

Users browsing this forum: No registered users and 12 guests

cron