On Sun, Feb 27, 2005 at 06:29:24PM -0700, David MacQuigg wrote:
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.
I don't see this.
If you are talking about 2.2.3 then you should also have seen:
"A Relay may add information to the envelope, such as with
trace information. However it does not modify existing
envelope information or the message content semantics."
It does not change envelope information. Therefore, if
"rfc2821.rcptto" changes, a new message was created.
Here is a figure showing all the Actors in an email system, including a
just list a link to the rfc if you want, don't copy these
pictures each time.
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
Excuse me?
You do know why we are here and what we are trying to do, right?
What do you think... if it weren't possible to fake mailfrom,
would spf have been born at all?
The issue I addressed was the supposed SPF forwarder problem.
There is no such problem. Once a message is no longer directed
to the original RFC2821.RcptTo, the message was delivered.
A relay (not a forwarder) acts on behalf of the original sender's
domain (and thus the SPF record can and should reflect this) or it
acts on behalf of the original recipient's domain (and SPF should
not be used at all for internal handling).
When the message is given to a forwarder, it is delivered.
To stay in terms of the crocker draft: the MTA on the
forwarder's domain is "Dest" and the process rewriting
the envelope, thereby changing the rfc8221.rcptto, and
submitting a message again is the "Recipient" and also
the "Originator" of a new message.
When the "Source" is faked to be the original rfc2821.mailfrom,
this is forgery, despite good intent.
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."
Insecure relays should not be included in your SPF record. If
they are in your record, you should fix the problem. If they
are not included, the recipient ("Dest") shouldn't trust any
information.
Alex