At 06:25 PM 2/26/2005 +0000, Mark wrote:
Dave wrote:
>
RFC 2821 formally defines Return-Path as follows:
Return-Path-line = "Return-Path:" FWS Reverse-path <CRLF>
It is associated with the MAIL FROM entity:
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a Return-Path line at the beginning of the mail
data. (...) The Return-Path line preserves the information in the
<reverse-path> from the MAIL command.
> As I understand it, the Return-Path is set by the original
> sender of a message, and is supposed to be preserved by all relays
> along the path to the final recipient.
If the Return-Path were always the original address of the sender, then it
would effectively be the same as the RFC 2822 From: entity. Return-Path,
as said, is associated with the envelope-from; and, as such, can change;
RFC 2821 even anticipates such changes:
I may not have been clear. The Return-Path is provided by the Source of a
message, specifying the address at which it wishes to receive Delivery
Status Notices. That address need not be its own address. { for
terminology, see Fig. 3 in draft-crocker-email-arch-03 modified at
http://www.ece.arizona.edu/~edatools/etc/Spam%20Flows.txt and copied below
as SpamFlows1 }
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
the message sender. When mailing lists are involved, this
arrangement is common and useful as a means of directing errors to
the list maintainer rather than the message originator.
And this, of course, is why it is so important people use the reverse-path
on bounces. Consequently, when people do SRS, especially forwarders, you
should expect to see, and use, the SRS0[01] signed address in the
Return-Path (or whatever other header holds the true reverse-path,
associated with the MAIL FROM entity).
The validity of the Return-Path depends on a fragile chain of trust all the
way back to the Source. If even one Relay is compromised, the Return-Path
may be forged.
We need to make a distinction between "Bounces" and DSNs. The DSN is a
simple message, not likely to disturb even a recipient at a forged
address. Spammers won't find much value in deliberately generating DSNs to
forged addresses, although there might be a problem if there continues to
be a lot of "backscatter" from the huge flow of spam.
A Bounce to a forged Return-Path is a more serious problem. These would be
mostly rejects or challenges from spam filters, possibly angry notes from
recipients of spam. These need to go back along the same path as they
came, *not* to a Return-Path that is most likely forged. They probably
also need a person to look at the Bounce at each step before pressing the
"send it back" button. This review policy could vary at each hop along the
true "return path".
> At the very least, we should be able to
> rely on the IP address of the topmost header. From that
> IP, we can find the owner's domain,
Can we? You can get a PTR from it; but there may be many A records which
resolve to that IP address. If you were to attempt this, which is
ill-advised, your best bet would probably be to try and match HELO (also
usually part of the Received: header) against the IP address, and use that
for domain if it matches.
I'm assuming that an authentication regime is in place, and we determine
the domain name via an authentication protocol. If the sender doesn't
authenticate, we probably don't want to send a Bounce, just mark it as
likely spam. If it is spam, send it straight to a domain-rating
service. They will track down the responsible domain.
> and send the bounce to
> the postmaster at that domain.
Let's don't, and say we did. ;) Heck, let's not even say we did. For one,
as said, because you may be sending to the wrong domain; and, for two, and
probably even more pressing, you really should be using the indicated
reverse-path. I cannot stress the importance of this enough.
I think we are in agreement on the necessity to not send Bounces to the
wrong domain. The key question is whether we can trust the Return-Path
after it has been through so many Relays.
-- Dave
<pre>
SpamFlows1 - Actors. Modified Fig.3 from draft-crocker-email-arch-03
adding Spammer, DSN, Sender, Receiver, Forwarder, Return-Path, Bounce
+------------+ +-----------+
| Originator | | Recipient |
+-----+------+ +-----------+
| ^
| Mail Handling Service |
/+=================================================+\
|| | | ||
|| | | ||
V Sender Return-Path Receiver |
+---------+ +--------+ +----+----+
| | | Notice |<------------+ |
| Source +...>| Handler| | Dest |
| | | |<---+ | |
+----+----+ +--------+ | +---------+
| |DSN ^
V Forwarder | |
+---------+ +----+----+ +----+----+
| Relay +--> ..... -->| Relay +-->| Relay |
+---------+ +----+----+ +----+----+
<-- Bounce <-- ^
|
+---------+ +---------+
| Spammer +--> ..... -->| Relay +
+---------+ +---------+
</pre>
************************************************************* *
* 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 *
************************************************************* *