On Sat, 5 Jun 2004, Michael R. Brumm wrote:
The more I think about SRS vs. SUBMITTER, the more I like SRS.
-SRS is ONLY required by forwarders (not senders or receivers), and
extensions to SMTP are NOT needed.
-SUBMITTER is required by forwarders AND receivers, and an extension to SMTP
is needed. And, worst of all, bounces can be forged.
-RSP (Reverse Source Path) is ONLY required by forwarders, and extensions
to SMTP are NOT needed.
Ok, so now I'm spending time trying to figure out how to prevent SUBMITTER
(without munging the addresses ala SRS or SES) from allowing forged bounces
from being injected. Here's one idea: Pass SRS type information in ENVID.
An excellent idea. I would much rather see the RFCs modified to
require ENVID passed back on RCPT than adding SUBMITTER.
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
If the orig.com has to go to DATA phase to get the Original-Envelope-ID,
then I hate the scheme. But if ENVID were to appear on RCPT TO, then
that would make SES so much more attractive for preventing forged
bounces.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.