In addition to other comments: Section 3.1.2.3 is just wrong. EAI specifically does not allow for downgrading of messages in transit from UTF-8 headers to ASCII headers. The only place the header downgrade is allowed is when a non-EAI MUA picks up mail via POP or IMAP, but that would be long after any DMARC tests were applied. You were probably confused because the early experimental version of EAI did allow downgrades in transit, but they worked so poorly that we took them out of the standards track version.
One place it might happen is when mail is relayed through a mailing list, but that's really the same issue as any other modifications a mailing list makes to mail that passes through it. See RFC 6783. In section 3.2.1, there are certainly vanity domains (I have lots of them) but I think you're more referring to stable addresses from professional associations or alumni associations, e.g., I will always be u...@computer.org regardless of where I get my mail. Some rewording would likely help to clarify what you're talking about, and the fact that most of them do not offer MSAs but expect you to use the one provided by your current mail system. In 4.4.1.1 the main reason to recode is if a message arrives via an 8BITMIME channel and leaves via a 7 bit channel so it has to change from 8bit to quoted-printable or base64. Every curent MTA can handle 8BITMIME but there are still a fair number of dusty old ones. Section 4.4.1.3 is wrong for the same reason that 3.1.2.3 is wrong. If you send an EAI message, it'll either be delivered as EAI or bounce. There is some ambiguity about what a DKIM signature on an EAI message would look like (is the domain in d= a U-label or A-label) but they should not be a big deal to work out. In section 4.5.1, another mailing list workaround is to rewrite the From: address into another address with an aligned signature that forwards to the original address. LISTSERV does this by rewriting to some random looking address in the list's domain, I do it by appending a local domain such as DMARC.FAIL. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
