spf-discuss
[Top] [All Lists]

RE: A hole in planned phishing-prevention?

2004-06-14 11:09:36
On Mon, 14 Jun 2004, Seth Goodman wrote:

When you say destination addresses, I think of RCPT TO: addresses and the
same addresses in the To: header.  These have nothing to do with the
return-path address, From: or Sender:.  I certainly didn't suggest that the
destination address appear in Sender:.  BTW, when I wrote this, I fully
understood that the MAIL FROM: address was an SES-signed address, while
From: and Sender: are both plain unsigned addresses, but was too lazy to
state this outright.  If that was the source of the confusion, my apologies.

Yes, I thought you meant textually identical and that if the return path
is signed then the Sender: address must be identically signed.

I should explain what I mean by return addresses and destination addresses
more carefully, since it's subtle. This is a classification of addresses
according to where they may validly appear in a message's envelope, and is
a property of the address independent of any message. The current usual
case is that a valid address is valid anywhere, but it is becoming
increasingly common to reject bounces to addresses that are never used in
the return path, i.e. "destination addresses" are only valid in RCPT TO
commands that follow a non-empty MAIL FROM address. Similarly, VERP
techniques such as SES and SRS have introduced a class of addresses that
are only used in the return path of outgoing messages or the RCPT TO of a
bounce, i.e. "return addresses" are not valid after a non-empty MAIL FROM.

(I should probably call addresses that are restricted this way
"destination-only" and "return-only" addresses, and addresses that
might or might not be restricted "destination-valid" and "return-valid"
addresses.)

The subtlety comes when you consider the message header. Obviously you put
destination-valid addresses in the To: and CC: headers. You must also put
destination-valid addresses in the headers that the recipient may use to
send a reply, i.e. the Reply-To: and From: headers. Finally, the semantics
of the Sender: header imply that it contains the same kind of address as
the From: header, and in some circumstances it may also be used to address
replies -- RFC 822 says

        Sometimes, a recipient may actually wish to  communicate  with
        the  person  that  initiated  the  message  transfer.  In such
        cases, it is reasonable to use the "Sender" address.

Therefore a system that signs the envelope return paths of outgoing
messages should not also sign the Sender: header, and recipient systems
should not assume that the PRA is the same as the return path, and if
you're really keen on callout verification you should verify addresses in
the message header using the call-forward form not the call-back form.

It is perhaps OK to require that the de-signed return path is the same as
the PRA, but if that's what you mean, that is what you should say :-)

-- 
Tony Finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/