>Is this a practical idea? Short answer: no. It's been around long enough to be a Well Known Bad Idea.
A large mail system can easily send a million messages a day. Ask your local DNS operator how they feel about adding a million records to a DNS zone every day and expiring them after a week, and the answer, once the choking and panicky laughter dies down will be No. Or ask your mail system people how they feel about keeping a database of message IDs that have to be queryable in real time starting the moment the message is sent, and their answer will be the same. (High volume update of real time databases is a very hard problem. That's the main reason IBM still sells multi- million dollar mainframes, and that Larry Ellison is worth $43 billion.) If you just check the Message-ID, bad guys can trivially defeat your scheme by attaching your message ID and any other headers you try to check to a spam message body. So you have to check that the Message-ID is attached to the right message, and to do that you have to do what DKIM does, so you might as well use DKIM. One of the reasons DKIM is practical is that public key signatures allow recipients to do the signature verification of many messages using a single easily cached key. Again, you can imagine lots of variations on this, but they all end up either being equivalent to DKIM or maybe to S/MIME or DANE. R's, John _______________________________________________ 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)
