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