From: Michael R. Brumm
Sent: Saturday, June 05, 2004 11:27 AM
<...>
ann(_at_)orig(_dot_)com
sends to: bob(_at_)alias(_dot_)com
MAIL FROM: <ann(_at_)orig(_dot_)com> ENVID=yf09+Cw
RCPT TO: <bob(_at_)alias(_dot_)com>
Actually, the recipient appears to be bob(_at_)pobox(_dot_)com, unless bob owns
alias.com and pobox.com provides the MX services for that domain.
bob(_at_)pobox(_dot_)com
forwards to: cob(_at_)third(_dot_)com
MAIL FROM: <ann(_at_)orig(_dot_)com>
SUBMITTER=<bob(_at_)pobox(_dot_)com> \
ENVID=yf09+Cw
RCPT TO: <cob(_at_)third(_dot_)com>
Ok, now let's say third.com needs to bounce this message, it
connects to orig.com:
EHLO third.com
MAIL FROM: <>
RCPT TO: <ann(_at_)orig(_dot_)com>
DATA (sends DSN with Original-Envelope-ID: yf09+Cw)
The MTA at orig.com can now use the "Original-Envelope-ID:" to
determine whether the bounce is valid. Ideally, the ENVID would
get passed back on the DSN's RCPT command, but alas it does not.
I suppose if we are adding SUBMITTER to MAIL FROM, we could add
ENVID parameter to RCPT, like this:
EHLO third.com
MAIL FROM: <>
RCPT TO: <ann(_at_)orig(_dot_)com> ENVID=yf09+Cw
NOTE: I am not advocating any of this, just throwing out the idea.
Well, this hasn't gotten rid of SUBMITTER, which was one of your goals. As
far as I can tell, all we have accomplished is putting the SES hash and
timestamp into another ESMTP parameter, ENVID. This parameter is not
available before DATA, so you have to accept the whole message before you
can reject. It also means that unless everyone adopts this _at the same
time_, you have the choice of rejecting valid DSN's from MTA's that don't
yet support ENVID or accepting bounce spam. According to RFC1891, all SMTP
servers plus ESMTP servers that don't support the ENVID extension MUST NOT
pass on that parameter when forwarding, so it can be lost. The only
advantage appears to be that the MAIL FROM: string is easier for a people to
read. This is an interesting idea, especially since it is standards based,
but it looks like we lose more than we gain.
Compare this to straight SES with the SUBMITTER address placed in reverse
source route format:
ann(_at_)orig(_dot_)com
sends to: bob(_at_)pobox(_dot_)com
MAIL FROM:<SES0=yf09=cw=ann(_at_)orig(_dot_)com>
RCPT TO:<bob(_at_)pobox(_dot_)com>
bob(_at_)pobox(_dot_)com
forwards to: cob(_at_)third(_dot_)com
MAIL FROM:<@pobox.com:SES0=yf09=cw=ann(_at_)orig(_dot_)com>
RCPT TO:<cob(_at_)third(_dot_)com>
third.com tries but can't deliver to cob
sends DSN to: ann(_at_)orig(_dot_)com
MAIL FROM: <>
RCPT TO:<SES0=yf09=cw=ann(_at_)orig(_dot_)com>
third.com then either rejects before DATA or accepts the DSN.
This relatively simple format is compliant with _all_ RFC's today and will
work with both SMTP and ESMTP servers. It eliminates the need for SRS and
permits SPF checks at each hop. PRA extraction helps to insure that the
current envelope sender agrees with the one inferred from the headers
(something good we got from CID). If we can succeed in producing code for
DNS servers that can validate the SES signature in response to an
appropriate query generated as a result of the exists macro in the SPF
record, this system permits end-to-end validation by the final recipient in
addition to the hop-by-hop validation of SPF. That's a lot of validation
for a simple MAIL FROM: format.
--
Seth Goodman