On Sun, 27 Feb 2005, David MacQuigg wrote:
SMTP was designed at a time when addresses weren't forged in 80% of
email. We probably need to keep things as is for DSNs, ( unless somehow
they become a serious problem ). What I would suggest is stating some
different requirements for handling Bounces ( spam and backscatter
). Bounces should be considered a separate class from normal DSNs, and
follow a "Bounce-path", authenticated at each hop, back to the responsible
party. Defining a new Bounce-path will not break existing systems, because
bouncing spam to the Return-path has never been legitimate.
If "Bounces" were simply sent as DSNs, there would be no problem.
Any sender using SRS or SES or similar return path signing system
can trivially reject DSNs from forged email immediately after
SMTP MAIL FROM.
The problem is with the people who invented this "Bounces" thing
to do what a DSN is supposed to do - but aren't flagged as a DSN
and hence can't be reliably distinguished from normal email.
Actually, I've always heard the term "bounce" used as a colloquial
term for a DSN. This thread is the first time someone has tried
to define a "Bounce" as something that is not a "bounce".
The feature of a DSN that makes it friendly for reporting delivery
problems, is that it is flagged as such in a standard way in rfc2821
(as opposed to some header inside the email) - and hence
can be matched to outgoing emails either cryptographically or
via database, and forgeries rejected. All this without ever looking
inside the email.
--
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.