At 04:43 PM 2/27/2005 -0500, Stuart D. Gathman wrote:
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.
Maybe we can fix that problem by requiring Bounces to be explicitly
labeled. As long as they go back the path they came, we avoid the
"backscatter" problem. I'm assuming we can't change the handling of
DSNs. Therefore, Bounces cannot go to the DSN address ( unless it happens
to be the same as the Bounce address ).
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".
I probably should use a different term. Crocker's draft makes no
distinction between a "bounce" and a DSN. Maybe "Spam Report", but that
doesn't cover some other possible uses. How about RPA ( Reject needing
Postmaster's Attention ).
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.
Anything we can do to make things flow smoothly, especially during the
adoption period. How about
Return-Path: <BOUNCE>
These can be easily distinguished from normal emails and from DSNs. They
can also be easily ignored, although that may not be a good policy if the
bouncer ( now the sender ) is a trusted client. A bounce is basically a
request "Stop sending me these". A reputable forwarder will treat bounces
not as an annoyance, but as an excellent statistical sample of the spam
that is currently bothering their clients.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com