At 05:21 AM 2/24/2005 -0600, Dennis Olvany wrote:
If forwarders will need to rewrite the envelope sender on forwarded mail,
why don't they just use the local mailbox as the envelope sender. As long
as the return-path header is preserved, NDRs will be sent properly and
won't need to be routed back through the forwarder. I've received every
indication that the address specified in the return-path header is in fact
the address to which NDRs are sent. I must be missing something, because
the solution couldn't possibly be that simple.
There is a good diagram, with proposed standard terminology, showing all
the participants in an email exchange at
<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt>http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt
By NDR I think you mean a Delivery Status Notification ( DSN ) that goes
from the Mail Delivery Agent ( MDA ) to the Mail Submission Agent ( MSA
). The only other kind of notice is a Message Disposition Notification (
MDN ) going from the recipient's Mail User Agent ( MUA ) to the
originator's MUA. I have to keep Figure 5 in front of me to remember all
this. :>)
I'm assuming we treat MDN's as ordinary user-to-user communications, and
DSN's as "bounces" needing to go back the path they came. I can't find
this in any standard or protocol, I'm just guessing.
Now to answer the question, why can't a DSN go straight back to the
Return-Path as seen by the recipient? The problem is, all of these
addresses can be faked, including the Return-Path. A Spammer can compose
any message headers he wants, including headers supposedly derived from
"envelope" information, then inject that mess at a Relay along the way.
+------------+ +-----------+
| Originator | | Recipient |
+-----+------+ +-----------+
| ^
| Mail Handling Service |
/+=================================================+\
|| | | ||
|| | | ||
V |
+---------+ +--------+ +----+----+
| | | Notice |<------------+ |
| Source +...>| Handler| | Dest |
| | | |<---+ | |
+----+----+ +--------+ | +---------+
| |DSN ^ # added DSN
V | |
+---------+ +----+----+ +----+----+
| Relay +--> ..... -->| Relay +-->| Relay |
+---------+ +----+----+ +----+----+
^
|
+---------+ +---------+
| Spammer +--> ..... -->| Relay + # added Spammer
+---------+ +---------+
Fig. 3 from Dave Crocker's draft ( edits shown with # ).
Let's say a Spammer want's to target the Source in the above diagram. All
he has to do is fake the right Return-Path in the crap he injects at any
point after the Relay which handles the DSN. The only thing the Spammer
can't fake is the IP address on the last hop. So if the Receiver ( Dest )
uses that IP to authenticate the last Relay, he has a known valid address
for the bounce. Each Relay must do the same as the Receiver, and
authenticate the incoming IP. Then the bounce can be sent correctly
upstream. To short-circuit the process, as is done in the diagram above,
there must be a trusted chain of relays between the Source and the agent
which generates the bounce. The only way a Receiver can send a bounce
directly to the Source is if every Relay along the way is trusted not to
make a mistake or be spoofed.
It seems to me, the best way to handle bounces is to insist that they go
back the same path the came. That will give reputable Relay operators an
opportunity to correct their own problem, or continue the bounce
upstream. At some point, the bounce will arrive at the Irresponsible Relay
( or a Relay under the control of the Spammer ). Either way, the domain of
that Relay can be blocked, or at least downgraded.
I sent mail from a mailbox on MTA1 to a mailbox on MTA2 that was then
forwarded back to a different mailbox on MTA1. I've color-coded the
headers. At hop 3, why can't the forwarder just use dennis(_at_)deadghost(_dot_)com
as the envelope sender? Do MTAs ever enforce that the envelope sender
match the return-path header?...or change the return-path header?
MUA --> MTA1 --> MTA2 --> MTA1
MTA1 logs.
MUA headers.
MTA1 headers.
MTA2 headers.
[snip long example]
Very nice example of the chaos in current headers.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq at gain.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