This would be my preferred approach. Very similar to draft proposal I
was/am going to write.
Regarding sendmail, its problems are not related to email or dns RFCs, its
just security problems in the programming & design of the program.
On Tue, 1 Apr 2003, J C Lawrence wrote:
On Mon, 31 Mar 2003 21:30:53 -0500
Eric D Williams <eric(_at_)infobro(_dot_)com> wrote:
I too agree that encryption should not be considered a primary
solution for spam as it constitutes a prohibitive threshold before any
significant results could be realized.
An aspect I've been musing on is adding forward chained digital
signatures to Received: headers with the receiving system's DNS record
publishing the public key. Loosely:
A clear text version and a digital signature of the following data
are encoded into the Received: header:
-- the Message-ID
-- address of the MX generating the header as a string (this
allows later callback verification)
-- the timestamp of the time the Received: header is generated
-- the matching digital signature of the immediately prior
Received: header (allows back chaining and trust verification of
the transaction stream).
Key width could be fairly small. There are a few changes to RFC
2822 in there as well (like Message IDs are now mandatory).
It suffers the same threshold problems, but could creep out fairly
quickly given a few more security holes in sendmail.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg