On Sat, 2004-06-05 at 12:27, 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.
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.
ENVID specified in RFC 1891:
http://www.ietf.org/rfc/rfc1891.txt?number=1891
On forged bounces:
Requiring an ENVID to be included in order for you to accept a valid
bounce means that only MTA's that support DSN will be able to send you a
bounce, and, most upsettingly, quite a few don't, (such as Postfix.)
Quoting from a message from wayne(_at_)midwestcs(_dot_)com at
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200404/0317.html
|A very quick check seems to indicate that
|sendmail and MS-exchange have DSN, but postfix, qmail and exim
|don't. Daniel Burnstein, the author of qmail, seems to think that DSN
|is obsolete and that VERP is better.
On using ENVID as a substitute for SRS or SUBMITTER.
----------------------------------------------------
Some time ago I suggested using ORCPT to basically do what SUBMITTER is
now supposed to do. The downside of using ORCPT for that is that even
though it's just perfect for the job, for an MTA to advertise support
for ORCPT requires that they advertise support for all of DSN, and...not
everyone supports DSN.
I had thought that most MTA's did, but I was wrong. What's even worse
is that if you look at some of the mailings lists of the other MTA's,
some folks just don't like DSN and have no interests in implementing it.
ENVID has the exact same problem--you can't claim to support ENVID
unless you claim to support all of DSN, and lots of people don't support
it and actively don't want to support it.
We could push for an RFC to support ORCPT or ENVID outside of having to
support all of DSN, (which would be more difficult for ENVID than ORCPT
as it's tied into the rest of DSN much more so than ORCPT), but...then
that's about the same thing as pushing for an RFC for SUBMITTER. (Or
ORCPT-by-itself, heh. :-) )
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
Side note: The above syntax doesn't look correct--ENVID is only a
parameter to MAIL, not RCPT.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com