Seth Goodman wrote:
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.
I think you meant "orig.com then either rejects ..."
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.
This looks convincing to me, and you didn't even have to use reverse
source routing in the FROM:. Sign me up! -- George Mitchell