spf-discuss
[Top] [All Lists]

RE: A hole in planned phishing-prevention?

2004-06-17 09:17:35
From: Tony Finch
Sent: Monday, June 14, 2004 4:23 PM


On Mon, 14 Jun 2004, Seth Goodman wrote:


<...>

If the system works, the end result must be that the recipient
either has
good reason to trust the return-path or reject the message.
Here is where
my original proposal comes in.  Once the recipient trusts the
return-path, I
proposed to "unwrap" the signed return-path address (if signed) and make
sure that it either matches Sender:, if that exists, or From:,
if Sender:
does not exist.  This will verify the key fields visible to the
user and do
so at extremely low cost.

I think this is a useful idea, but it needs some elaboration. In
particular, remember that the usual way for a message to be re-sent by an
MUA involves adding Resent-*: headers and submitting the new message such
that its return path refers to the re-sender, not the original sender.
i.e. you need to use the PRA algorithm to work out which header to compare
with the de-signed return path. For original messages, compare with the
Sender: or From: and for re-sent messages compare with Resent-Sender: or
Resent-From:.

"Forwarding" resulting from a user hitting the forward button in their MUA
is not the same as forwarding by an MTA set up by a recipient on his own
behalf.  In the former, an end user sends a message from someone to a third
party who was not an original recipient.  The latter is merely a redirection
set up by a recipient for their own convenience.  Given that fact, it is
appropriate that a user manually "forwarding" a message to a third party
looks like a new message from that user.  What is not appropriate, IMHO, is
that the From: header remains unchanged.  I would consider this a forgery,
as the MUA displays the original sender, whose identity cannot be validated,
rather than the actual sender, whose identity can be validated.  For the
case you mention, validating the PRA with the return-path gives you
absolutely no confidence in From: nor Sender:, so I suggest it is not
particularly valuable.  In fact, it is probably misleading to the end-user
to call such a message verified.

If there are MUA's that work this way, obviously something has to be done,
either at our end or by the MUA vendor.  My MUA, M$ Outlook, though it has
many other annoying idiosyncrasies, does not do this.  It treats the
forwarded message as a new message sent by me, so the return-path and From:
are both my address.  A third party receiving such a message will see my
name and address in From:, which is appropriate.  The original From:, Date:,
To: and Subject: become part of the message text.  That is Outlook's
particular solution, but I happen to think it is rational.


Note that the requirement in the MARID draft that forwarding MTAs add a
Resent-From: header conflicts with these existing semantics (because the
return path remains the same rather than agreeing with the Resent-*:
headers) as well as requiring a lot of software to be changed (in which
respect it's as bad as SRS).

Keeping the return-path the same and adding a Resent-From: header makes
sense, as this is an actual forward, which the RFC's consider a redirection
rather than a redistribution of the message.  I think the behavior of the
MUA that you list above should be different, as it is potentially
misleading.  The behavior you describe from the MARID draft would still
allow enforcing MAIL FROM: == Sender: or MAIL FROM: == From:.

--

Seth Goodman