In article <[email protected]> you write: >The paper has a simplistic model of email anti-abuse processing and this >distorts some of its analysis. At the least, the paper needs to >distinguish between theory and practice.
Yup. >> SPF implementations treat “([email protected]” as anempty MAIL FROM >> address, and thus forward the resultsof checking HELO to the DMARC >> component, because thestring in the parentheses can be parsed as a >> comment ac-cording to RFC 5322 [10]. Some DMARC >> implementations,however, may take it as a normal non-empty address, > >1. This issues goes away if SPF supplies DMARC the domain name, rather >than DMARC having to fetch it Their assumptions about DMARC validators may be true in some cases but not in general. In OpenDMARC which is pretty widely used, the caller tells the DMARC library what domain SPF checked, whether it was the mail_from or helo, and what the result was. >The paper asserts that AR is used as DMARC input. I suspect that is >rarely, if ever, true. Yes? No? I'd say never. To do DMARC rejects you have to do all of the validation in the SMTP daemon, which is before anything has a chance to create an A-R header. >The rfc5322.From: field is independent of MIME. MIME pertains only to >the body. The display name can be a MIME encoded word, but that has nothing to do with parsing the MIME parts in the body of the message. I'm still impressed at some of the really simple bugs they exploited, like NUL characters in header fields. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
