At 03:09 PM 2/28/2005 -0500, you wrote:
On Mon, 28 Feb 2005, David MacQuigg wrote:
> In the example I gave the DSN would go to the Return-Path ( amazon.com
> ). A Bounce ( spam reject ) would go to the previous Forwarder (
pobox.com
If the previous Forwarder wants the DSNs, they just rewrite the
Return-Path - using SRS for instance. So what do "Bounces" buy us?
We can't expect Forwarders to re-write the Return-Path, because that would
disturb the current use of that header for non-spam email. Here is the
explanation in Crocker's Email Architecture:
from p.22 of
<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt>http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt
Ultimately the simple basis for
deciding what address needs to be in the RFC2821.MailFrom is to
determine what address needs to be informed about
transmission-level problems (and, possibly, successes.)
Rather than change DSN routing for everyone, we should change the routing
on only the messages that are new and increasingly troublesome, spam
Bounces. I would include in that category challenges from spam
filters. If it's not really spam, the Bounce-Path will get to the same
place as the Return-Path. If it is spam, we don't bother the Return-Path
with more spam.
I see a fundamental difference between DSNs and spam Bounces. DSNs should
go to the original Sender, at his designated Return-Path. Spam Bounces
should go as far back the Spam Path as possible.
I really think a picture is worth a lot of words here. Can you see in this
figure how the Bounces go a different path than the DSNs? This may not
come out in the mail list archive, but you can find the original at
http://www.ece.arizona.edu/~edatools/etc/Spam%20Flows.txt
<pre>
+------------+ +-----------+
| Originator | | Recipient |
+-----+------+ +-----------+
| ^
| |
| |
V Sender Return-Path Receiver |
+---------+ +--------+ +----+----+
| | | Notice |<------------+ |
| Sender +...>| Handler| DSN | Receiver|
| | | |<---+ | |
+----+----+ +--------+ | +---------+
| | ^
V | |
+---------+ +----+----+ +----+----+
|Forwarder+--> ..... -->|Forwarder+-->|Forwarder|
+---------+ +----+----+ +----+----+
^
<-- Bounce <-- |
+---------+ +---------+
| Spammer +--> ..... -->|Forwarder+
+---------+ +---------+
</pre>
-- 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 *
************************************************************* *