"Dave Crocker" asserted:
<snip>
RFC2821.MailFrom specifies a return (bounce, notification, ...) address,
not a source address.
It is "set by" the rfc2821.sender, but does not specify a source.
The difference is quite important.
And having the MailFrom specify some other address is not "forgery" as
folks often call it.
Sigh.
Indulge me which I take this in simple steps...
My understanding is the following:
RFC2821.MailFrom specifies the address of the entity who is to be held
responsible and accountable for inserting the message into the SMTP system.
That entity is responsible and accountable for:
a) The content
b) The list of RFC21 RcptTo recipients.
This is the entity to which DSNs of whatever nature are to be sent.
Now we all know that within today's RFC 'rules' anybody can insert a message
using any MailFrom they wish.
I, personally, define the action of inserting a message using a MailFrom entity
address _without the authority of that entity_ as forgery. It's the lack of
authority which is the key concept.
What SPF does is ask whether the inserting host (identified by its IP address)
is authorised by the MailFrom entity to insert messages on its behalf, i.e. to
insert messages having that MailFrom address.
Now consider a forwarder commissioned by a _recipient_ to forward her mail (e.g.
an alumni forwarding service).
Also assume that the original sender has no knowledge of that forwarder, and has
certainly never given it any explicit authorities.
The SMTP process delivers the original mail to the original recipient address'
mail box. As far as that address is concerned, the SMTP process has done its
job; the mail has been successfully delivered.
But now that mail box has a mechanism which takes the original content (I'm
chosing my words very carefully here) and initiates a new message-sending
process using a _new_ RcptTo address; the forwarding address. It initiates a new
SMTP sending request.
Suppose that the mechanism uses the _original_ MailFrom address.
What is happening is that an intermediary which has no authority from the
mailFrom entity is sending a message to a recipient address which is unknown to
the mailFrom entity. The mailFrom entity cannot be held accountable for sending
the message (<i>any</i> message - see below) to that new address.
The intermediary is committing forgery (or fraud, or lying or whatever euphamism
you wish to use). It is asking the SMTP system to transmit something to an
address, and falsely claiming the authority of the mailFrom entity for that
transmission.
The message content is irrelevant (contents are irrelevant to RFC2821).
Does anyone wish to argue that :
1) Anybody should be free to use a mailFrom address without the authority of the
entity which 'owns' (leases?) that address?
or
2) Any valid recipient is implicitly authorised by the original mailFrom sender
to send any message content it wishes to any third party citing the original
mailFrom (and if so argued, please explain the distinction from 1),
or
3) Any valid recipient is implicitly authorised by the original mailFrom sender
to resend the original, unaltered message content to any third party citing the
original mailFrom,
or
4) Any valid recipient is implicitly authorised by the original mailFrom sender
to send a message which includes parts of / extensions to the original message
content to any third party citing the original mailFrom.
I can't think of any other situations.
(1) is the 'legacy' internet practice.
I suspect (I've not checked this) that DomainKeys initially intended to permit
(3) but has found that too many situations turn into (4) - the agent in the
middle alters the RFC2822 headers or content in some way - so that the concept
of 'the same message' is impossible to define. I know that SES has discovered a
similar difficulty.
It seems to me that someone can only oppose the objectives of SPF, or accuse it
of 'breaking' forwarding, or deny the 'forgery' assertion, if they hold any of
(1) - (4) above to be true.
Chris Haynes