>Please post more reviews... Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely wrong. Please delete it, since the problems it describes do not actually exist.
EAI does not, repeat NOT, downgrade messages in transit. If I send you an EAI message, either it'll be delivered as that EAI message, or it'll be bounced back. There's no reason that DMARC wouldn't work just the same as it does on normal mail, give or take some minor and easily resolved ambiguities about whether the domains in DKIM signatures are U-labels or A-labels. All of the downgrade stuff to which this section refers only happens in one rather arcane situation -- the MTA that received the mail does EAI but the user's MUA doesn't, and the user is trying to pick up the mail with POP or IMAP. Our choices boiled down to invent a new error code that says "you have new mail but you can't see it neener neener" or downgrade messages during POP or IMAP retrieval. Since the normal place to check DMARC is at delivery time, DMARC will have done its thing long before any possible downgrade, so the downgrade doesn't matter. People might try to forward downgraded messsages, but the issues there are the same as for any message that's smashed when it's forwarded, as described in 3.2.2. We invented the RFC6854 empty From: group syntax hack to enable simple EAI downgrades, but it applies to any mail, normal or EAI. My strong suggestion would be that if there's no address on the From: line, there is nothing for DMARC to do and no problem to solve. It's just like any other message with a return address for which the MTA has no reputation info. In 3.2.3, I've never seen list software do PGP encryption, but I have seen it do S/MIME decryption and re-encryption. You might want to change the example. In section 4.1.1.1, add: * Senders can use different domains for mail sent directly and mail sent in ways likely to have DMARC problems, the former with a DMARC policy and the latter without. Please also delete Section 4.1.2.3, since again the EAI problem it describes does not exist. In the first long paragraph in 4.1.3.3, at this point I don't know anyone adding .INVALID, but I know people rewriting the From: address to a different valid address that forwards to the real author. Some people do it the way I do, e.g. [email protected], or LISTSERV invents a pseudo-random address in the list's domain. Section 4.2.1 is hard to follow. Is it describing Doug's thing? In Sec 7, it's often considered tacky to acknowledge people listed as document authors. R's, John PS: I could swear we went around the EAI stuff in the last version of this draft. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
