RFC 5322 states that every email SHOULD have a unique Message-ID. In practice, unless a user has authenticated (in which case, we add the Message-ID, per RFC 5322), every legitimate message arriving via SMTP will have a Message-ID. Right?
It seems the only thing lacking for a 99.99% reliable authentication solution is a mechanism for the receiving MTA to ask the purported DMARC enabled sending MTA, "did Message-ID [big.long.unique.id.here] originate from you?" In all the edge cases I can think of where DKIM and/or SPF validation fail, this approach would still work. The sending MTA could implement the Message-ID validation service in a number of ways: as an SMTP protocol extension, a TCP/UDP service, or a special DNS zone. With a special validation service, additional information about the attempt could be captured, in lieu of aggregate reporting. My first inclination is to delegate a special DNS zone to my mail servers and publish Message-ID's in the DNS. Each Message-ID is a DNS name that automatically expires in a week. I have a sufficiently large namespace that false positives aren't a concern. The address portion of the DNS record could be a hash of the To and From headers, deterring Message-ID replay attacks. Is this a practical idea? Matt _______________________________________________ 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)
