On Wed, Nov 11, 2015 at 04:17:49PM -0800, Rick Moen via luv-talk wrote:
Personally, I think DMARC is overscoped. It _could_ have been limited to just validating the SMTP IP aka validating the 'From ' envelope sender -- but instead its designers went overboard and decided to extend the initial DomainKeys functionality and crypto-sign internal SMTP headers, too. This is one of several reasons I've leaned in the past towards SPF: It does only the essential, hence creates less collateral damage.[1]
DMARC fundamentally broken if it uses the From: header instead of the envelope From address. With the sole exception of generating the envelope (including From_) and any missing required headers when a message is first sent (e.g. Message-Id, Date), from the POV of an MTA, headers are and should be nothing but irrelevant comments. And there is never **any** excuse for munging the Reply-To: header. Doing that is broken, and has been known to be broken for many years.
But both SPF and DMARC are increasingly relevant, and mailing lists that continue to flunk DMARC testing are going to have greater and greater delivery problems.
I guess i'm not telling you anything you don't already know, but SPF works because it doesn't care about headers. SPF checks compare the envelope From against the published SPF DNS record of the domain. if it comes from one of the servers allowed by the SPF record, then accept. otherwise reject (or accept and tag). That's all a mailing list needs. It re-sends the mail with its own envelope-from address (necessary for VERP as well as SPF), so the recipient server can check SPF to see if the sender is allowed to be sending from, e.g., luv.asn.au. The From: header inside the message is irrelevant, that's for end-user MUAs to handle. If the list admin is worried about subscriber forgery then the list server can check SPF on incoming messages. If list subscribers are worried about forgery of their addresses, then they (or their domain admins) can add SPF records to theri domains. SPF works, and it works better the more domains that use it. It was designed as a domain forgery prevention tool, and it works extremely well at doing just that...who knows better than the domain admins which servers are allowed to claim to be sending mail from that domain?
I get why Russell's solution is unappetising. Believe me, I am with you on that. But I'm still waiting to hear anyone suggest a credible alternative.
How about a domain-keys derivative that restricts itself to checking the envelope From address as it should? From: headers are comments, not addressing information. But that would probably be indistinguishable from SPF and therefore not give giant corporates like yahoo or google the control over all mail that they are working towards. craig ps: and this "Real Name via luv talk" appendage is ugly and wrong. I'll have to edit it out of every reply I send from now on - when I hit 'g' in mutt for a group-reply, I am *not* sending the message to "Rick Moen via luv-talk", I am sending the message to "luv-talk". If I want to reply to Rick Moen privately, I'll hit 'r' for private reply...except, I can't now because the list munges the From: header and my procmail has for many years partially undone the idiocy of Reply-To by renaming Reply-To headers to X-Old-Reply-To Speaking of mutt, this From: munging also breaks mutt's ability to detect list messages sent by me, and to highlight them by showing them in a different colour: color index cyan default '~P' # mail from myself -- craig sanders <cas@taz.net.au>