|
RE: Email Forwarder's Protocol ( EFP )
2005-02-26 09:20:32
At 02:15 AM 2/26/2005 +0000, Mark wrote:
Dave wrote:
> We can then use the Received: headers for the bounce path instead of
> bouncing directly to the forged Return-Path:. If the mail is legit,
> sending it back along the bounce path will get it to the same
> place as the Return-Path. If its a forgery, the bounces will stop where
> they should, at the forger's domain, and not bother anyone at the
> forged Return-Path.
The "Return-Path:" header is no more, nor less, fake than a "Received:"
header. Sendmail, for instance, has the H_ACHECK flag set for
"Return-Path:". This flag tells sendmail that it should always check the
mailer flags to see if the header should be included. If the mailer does
not include the appropriate flag, then sendmail will delete the header
when it delivers the message. Accordingly, sendmail will also set
"Return-Path:" itself (if the P flags is defined), regardless of what
existing header you feed it. "Return-Path:", holding <$g>, is therefore
exactly as reliable as <$g> found in the latest "Received:" header. They
are both added in H lines.
Bottom-line, if you trust the "Received:" header of your connecting MTA,
then you can also equally trust its "Return-Path:" header, if present.
That's not what I'm seeing in my spam bucket. The Return-Path: is almost
always forged, while the topmost Received: header almost always contains
the correct IP of the previous hop. I say "almost always" because I
remember being surprised a few months ago by a spam that had the date
forged in the topmost Received line. I still don't know how they did
that. Probably a spammer within my local network.
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. That makes it inherently insecure. The Received From
information is obtained directly from the previous relay. { RFC 2821 sect.
4.4 - Trace Information } So if the previous relay is a trusted forwarder,
we should be able to rely on that information. 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, and send the bounce to the postmaster
at that domain.
What an Email Forwarder's Protocol should do is make that process
automatic. Instead of having to look up the IP in senderbase.org, we
should be able to just click a button and immediately bounce a spam back to
the responsible person at the previous relay.
I will try to post some sketches below, but in case that fails, here is a
link http://ece.arizona.edu/~edatools/etc/Spam%20Flows.txt
> So to make SPF work with forwarders, we don't need any new
> headers, just a few more words in an existing, widely accepted header,
> and an agreement on how forwarders should handle bounces.
An existing and widely accepted header is precisely a good reason not to
mess with it. :) Seriously, Received: headers should be left alone.
Agree. Nothing should be done which will disturb existing uses of that
header. What might be needed is some *additional* specification that will
allow that header to be used for authentication. Adding a few words like
"auth SPF1(PASS)" would not disturb existing uses in any way. And it would
not favor one authentication protocol over another.
This debate has dragged on too long. The SenderID folks are never going to
like Received-SPF. The SPF folks aren't going to like whatever SenderID
comes up with. If all parties can agree on just the essential non-partisan
words to add to a Received header, then everyone can do their own thing in
their own headers, and it won't matter to someone else who doesn't use that
protocol.
I remember the long debate over Ethernet vs. Token Ring. The big gorilla
came late to the party and wanted to embrace and extend what was already a
great protocol. They had some technical experts who made some
mind-boggling arguments that Ethernet was fundamentally
flawed. Theoretically, you could squeeze a few more % of bandwidth out of
a 10Mbps cable, and you could guarantee that no connection would ever
suffer an extremely long wait for its next packet. There were technical
fixes that would allow an Ethernet to avoid these rare problems ( I
proposed one ), but the big gorilla wouldn't listen. The debate dragged on
and the adoption of a sorely needed standard was seriously delayed.
I find the parallels to that situation two decades ago very amazing. To
not repeat the mistakes of the past, we need to avoid partisan debate over
unimportant details, and focus on the few fundamental items where a
standard is really necessary. I now believe that is possible to meet the
requirements I stated at the beginning of this thread with very little
additional standardization. Then all sides can say "The standard is
done. Start using it."
-- Dave
<code>
SpamFlows1 - modified Fig.3 from draft-crocker-email-arch-03
adding Spammer, DSN, Sender, Receiver, Forwarder, Return-Path
+------------+ +-----------+
| Originator | | Recipient |
+-----+------+ +-----------+
| ^
| Mail Handling Service |
/+=================================================+\
|| | | ||
|| | | ||
V Sender Return-Path Receiver |
+---------+ +--------+ +----+----+
| | | Notice |<------------+ |
| Source +...>| Handler| | Dest |
| | | |<---+ | |
+----+----+ +--------+ | +---------+
| |DSN ^
V | |
+---------+ +----+----+ +----+----+
| Relay +--> ..... -->| Relay +-->| Relay |
+---------+ +----+----+ +----+----+
^
|
+---------+ +---------+
| Spammer +--> ..... -->| Relay +
+---------+ +---------+
</code>
<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 *
************************************************************* *
</pre>
|
|