[Top] [All Lists]

Comments (II) on draft-church-dns-mail-sender-02.txt

2002-08-26 21:38:10


Let me refine my comments on
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 

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 

- 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.


- The one who has got the STUB is able to spam the net. Therefore, 
  there should be a reasonable expire time of the STUB.


Rahmat M.  Samik-Ibrahim --  -- --
Wise men say:Can't Help Falling in Linux with GNU - LILO and GRUB