At 01:25 AM 2/28/2005 +0100, Alex van den Bogaerdt wrote:
On Sun, Feb 27, 2005 at 10:59:05AM -0700, David MacQuigg wrote:
> Crocker's explanation of current email architecture doesn't deal
> specifically with questions of forgery, but it is clear from the above
> definition of the MailFrom identity, that this identity must be preserved
> by each Relay from Source to Destination. That's where I am seeing the
> vulnerability of SPF. Is it not possible for a Relay to insert whatever
> identity it wants the Recipient to think is the original MailFrom identity?
Please show where this explanation states that forwarders
are indeed relays and not, say, a user process.
Section 2.2 defines Relay as a very general term, including everything from
User Mediators ( Forwarders, Mailing Lists, etc. ) to Packet Switches.
Here is a figure showing all the Actors in an email system, including a
Spammer. If you can't read it because spaces are squeezed out in this
mailing list, see
http://www.ece.arizona.edu/~edatools/etc/Spam%20Flows.txt or the original
Fig. 3 in
<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt>http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt
from which I made this figure.
<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 +
+---------+ +---------+
2/27/05
</pre>
Hint: I'm referring to section 4.2
"... and closing or expanding the user communication loop, by
initiating replies and forwarding new messages."
A User-level process can serve as a Forwarder, but I think most Forwarders
today just copy the address in the incoming MAIL FROM command and pass it
on in their own MAIL FROM command.
New message -> new source to new destination -> new RFC8221 MailFrom
I'm interested to see if, and where, this document would allow
to retain MailFrom when RcptTo changes (apart from internal
rewriting of RcptTo perhaps)
I don't think it addresses this issue at all. The core of the problem is
not what some spec allows, but whether it is technically possible for a
Spammer to fake the Mail From address. If this is done at any point along
the chain of relays from Sender to Receiver, then the forgery is propagated
all the way to the Receiver, where it gets written into the Return-Path
header. Furthermore, an authentication check at the Receiver doesn't catch
it, unless the Spammer dumb enough to connect directly to his target. As
long as he is hidden behind at least one insecure Relay, he can pass on
whatever garbage he wants. He can even pretend to be a Relay. "Yep, we
authenticated our sender, and it was smithbarney.com. Here is our
authentication header. Trust it."
-- 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