On Apr 26, 2014, at 2:30 PM, Paul Scott <[email protected]> wrote: > I run a number of web sites where users wish to have their e-mail address > with their own domain name. Some of these users (quite a few) do not read or > send mail through their web site or via their own domain server; rather they > wish their mail to be forwarded to a free mail account such as Yahoo! or > Gmail. > > Of course, the problems encountered with such a configuration have been > discussed on this list. And, I have independently arrived at a solution I now > see has been discussed: before forwarding incoming mail, munge the From: > header to match the forwarding server, and copy the sender’s e-mail address > to a Reply-To: header. Aside from being extremely ugly -- and problematic on > a perception level — it is also unworkable when the original sender’s e-mail > has been signed or encrypted. > > With signed or encrypted mail, the sender’s e-mail address no longer matches > their certificate so the validation fails. > > I don’t see any solution to this problem other than abandoning DMARC. > Unfortunately, a lot of organizations have adopted it, and the community > suffers as a result. Honestly, I don’t think DMARC was thought-out before it > was implemented. If I’m wrong, please set me straight and show me a solution.
No, you have it pretty much right. DMARC is a good solution for a narrow range of senders of email - those who have no real people sending email using their domain. But a couple of large freemail providers have decided to publish DMARC records to mitigate some of their internal security issues, pushing the operational costs of those on to everyone else. However, your abandoning DMARC won't fix the more serious problems you're seeing, as they mostly occur when someone who publishes an inappropriate DMARC p=reject message sends you email, and you forward that on to someone else who checks DMARC on inbound mail. Your checking or not checking DMARC doesn't affect your operational pain much. There have been a number of suggestions to mitigate it for mailing list operators, but I only know of one that meets both of the following: 1. Causes no harm to end users at email providers who have not published DMARC p=reject records. 2. Complies with the spirit of the published policies of those who are publishing DMARC p=reject (loosely, that their users are not allowed to use email addresses in their domain for mail sent by third parties) That is to set up your mail system such that if you receive an email that you are going to resend (via a forward, or via a mailing list) and that email is from a domain that is publishing DMARC p=reject records, and you cannot *guarantee* that any DKIM signature on the inbound email will not be invalidated by the time the email reaches it's final recipient, you should reject that email. A simpler, and only marginally less accurate, approach to that is to reject all mail to mailing lists or forwarders from any domain that publishes DMARC p=reject. As of today, blocking that mail from a small fixed group of domains that are known to both publish DMARC p=reject and to have users who send 1:1 email will be just as good, and easier to set up. In order to mitigate your support overheads, the rejection should probably explain to the sender of the email that their ISP has put restrictions on their use of the email address and does not permit them to send email to the recipient they're trying to contact, and suggest they contact their ISP to have those restrictions removed. Cheers, Steve _______________________________________________ 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)
