On 04/27/2014 10:58 AM, Paul Scott wrote:
What happens is that a user, say using Yahoo! Mail, sends an e-mail to someone whose domain I host (pretend it’s example.com <http://example.com>), and that someone wishes their e-mail forwarded automatically to, say, Gmail. That is, [email protected] <mailto:[email protected]> pens an e-mail to [email protected] <mailto:[email protected]> who wishes to pick up mail on Gmail. In this case, the Gmail server rejects the forwarded mail from example.com <http://example.com>, not on the basis of DKIM, but on the basis of Yahoo! mail DMARC policy. Straight away, this is a huge problem if one wishes the From: header to remain unchanged (a reasonable expectation). It means, as I understand it, that DMARC prevents such forwarding. I find this an unacceptable situation in a reasonable scenario.
It would help to see the actual failures with an actual message. DMARC's decision-making incorporates DKIM's result for the express purpose of supporting the forwarding scenario that you're describing, and it's known to work reliably in the currently deployed implementations at the large receivers. (If this sort of forwarding were not of interest to DMARC then there would have been no compelling reason to include DKIM in the first place, SPF would have been sufficient.)
Since the only solution to avoid the rejected mail seems to be modifying the original From: header — which I’ve reluctantly done -- to one that passes (or completely avoids) DMARC at the forwarded server, and applying a new Reply-To: header — assuming one didn't already exist, which you’d of course want to keep -- a totally new an unacceptable problem arises: If the original sender signed/encrypted the e-mail message, then modifying the From: header will cause their x.509 certificate to fail validation; the entity in the From: header does not match the certificate’s entity. This has nothing to do with DKIM, as some people seem to be suggesting.
This is where a concrete example would help in understanding the issue. The requirements for preserving an S/MIME signature and a DKIM signature are analogous (the forwarder must not alter the signed parts of the message: a single multipart section in the S/MIME case, the entire message body and several important headers in the DKIM case). So long as you're forwarding the message unaltered (modulo pre-pending trace fields and Authentication-Results: headers), both the S/MIME and DKIM signatures should still validate, in which case your end-users' crypto software will work as expected and the receiving organisation's DMARC implementation will work as expected.
I certainly understand the concept under which DMARC arose, but I have to say — unless I’m missing something — that the implementation is not very useful except in a very restricted scenario.
It does seems as though you are missing something, but without a concrete example to diagnose it's difficult to be certain what the problem is.
When mail services used by the general public adopt DMARC, then something as simple as forwarding mail intact becomes an impossibility.
That's definitely not true and is the reason for DMARC's use of DKIM. This case works reliably in current deployments.
If there is a reasonable solution that I’ve overlooked, I’d appreciate someone’s input. Thanks.
Happy to help, please supply a test message as-forwarded with headers intact and a copy of the error messages from the receiving system.
- Roland -- Roland Turner | Director, Labs TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693 Mobile: +65 96700022 | Skype: roland.turner [email protected] | http://www.trustsphere.com/
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
