ietf-mxcomp
[Top] [All Lists]

RE: User experience

2004-04-07 23:01:14
Comments below marked with HKATZ:

________________________________

From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org on behalf of Pete Resnick
Sent: Wed 4/7/2004 9:12 PM
To: John Gardiner Myers
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: User experience




On 4/7/04 at 7:00 PM -0700, John Gardiner Myers wrote:

Harry Katz wrote:

Most mailing list servers add a Sender header identifying the list
owner as the sender.  (This list we're on for example inserts
"Sender: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org").

Such addition of a Sender: header is not specified in the relevant
standard, RFC 2821 3.10.2.  RFC 2821 3.10 has strong requirements
against modifying the header.

I don't think the admonition in 3.10 about not changing the header is
completely realistic, especially in light of RFC 2369 and RFC 2919.
It is common practice now (and I think always has been) for lists to
change headers, though I agree with the admonition insofar as fields
like Date, Message-ID, and (as noted in 2821) especially From should
never be changed by list processors, and likely the destination
fields shouldn't be changed either.

I've always considered list processors to be receiving the message
and starting an entirely new sending event. (As 3.10.2 notes, a list
doesn't "forward" in the 3.4 sense of redirecting the mail to a new
address, leaving everything else identical.)

All that said, I don't know that changing the Sender is appropriate
anyway, at least according to the definitions in 822 and 2822. (E.g.:
If my secretary sends a message on behalf of me, or I have a
multi-address From line and me in the Sender, should that information
be lost just because I sent through a mailing list?) I'm almost
tempted to say that Resent-* fields should be used for that purpose.

HKATZ:  That is exactly what we've suggested in the Caller ID spec if a Sender 
header is already present. 

But now I think I've drifted sufficiently out of scope for the
discussion in this group!

But if it is the From: header the user is going to principally see,
then if you verify any other identity in preference to From:, then
you've just created a hole for attackers to exploit.

I agree, and this is the killer one for me. If, as a phisher, all I
have to do is create a dummy domain, put "badguy(_at_)dummy(_dot_)example" in
the Sender, make sure there is an appropriate DNS record saying "OK
to send from this IP address saying you're from dummy.example", and
put "support(_at_)paypal(_dot_)com" in From, I've bypassed your check and you've
done nothing to save the poor user from me.

HKATZ:  I would note that precisely the same thing is true if the spammer uses 
badguy(_at_)dummy(_dot_)example on the MAIL FROM.  In both cases there's a 
discrepancy between the domain that's validated and the domain that appears on 
the From line.  Sometimes that discrepancy is legitimate - as in the case of a 
mailing list - and often it's not.  MUAs are going to have to present both 
identies to the user.  Some already do this.  Outlook for example shows "From 
<Sender> on behalf of <From> "  I think there are other clients that do similar 
things.  .  

Now, as Harry said earlier:

If we can't validate the domain of the From header, then we must
inform the user that we validated something else.

I would agree with this, but as the above example points out, if
there is going to be an easy way for spammers/phishers to avoid the
 From check, MUAs are going to have to start displaying stuff to the
user other than just the From line. And if MUAs are going to have to
start doing that anyway (and I agree they must), I don't see any
*urgency* to focus our efforts at the From line of the message, as
Harry started this thread.

HKATZ:  For the reasons I've stated above, you face the same requirement if you 
base the validation on MAIL FROM.     


pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102



<Prev in Thread] Current Thread [Next in Thread>