Hello:
Let me refine my comments on
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt
I cc: this to ietf-smtp and apology if it is a wrong place to send.
I wrote:
1. it is not so clear; on how to implement a mailing list exploder; which
is neither (cmiiw) "3.3. Relays on the receiving end" nor
"3.4. Relays on the sending end".
2. same as #1, for the standard ".forward" procedure.
3. same as #1, for the "bounce" option of a mail reader (example pine or
mutt);
How about to verify the integrity of the email (checksum) to a server that
is pointed by the "MS" RR. I.e. not only to make sure that the headers
haven't been modified by anyone in the middle; but also as a confirmation
from the original sender (through MS RR).
Example, sending an email from sender(_at_)FQDN1 (MTA1) to receiver(_at_)FQDN2
(MTA2):
- MTA1 at FQDN1 generates a STUB.
- A STUB consists of: the signed checksum of -- the email body; plus some
crucial email headers (eg. "From:", "Subject:", "Message-ID:", "Date:",
etc); plus its expire time. The whole STUB should be reasonable small
(say: 128-1024 bits?) so it could be processed by an ordinary CPU.
- When MTA1 sends the "MAIL FROM" stanza, it also includes the email STUB
- While still sending "250 OK", the receiver (MTA2) should query the
MS RR of FQDN1 to verify authentication of the STUB;
- MTA2 verifies the integrity of the email.
At the end, MTA2 should notify MTA1 if the message is accepted or rejected.
Drawback:
- The one who has got the STUB is able to spam the net. Therefore,
there should be a reasonable expire time of the STUB.
regards,
--
Rahmat M. Samik-Ibrahim -- vLSM.org -- http://rms46.vLSM.org --
Wise men say:Can't Help Falling in Linux with GNU - LILO and GRUB