RE: User experience

[Greg Connor <gconnor@xxxxxxxxxxxx>]

(i lost the attribution for this:)
> > If we can't validate the domain of the From header, then we must
> > inform the user that we validated something else.
probably Pete Resnick:
> 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.
--Harry Katz <hkatz@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> HKATZ:  For the reasons I've stated above, you face the same requirement
> if you base the validation on MAIL FROM.


I would agree that 2822 Sender: and 2821 MAIL FROM: have the same problem: 
they are not always the same as 2822 From:

Harry points out that Outlook for example shows "From <Sender> on behalf of 
<From> "

I agree with Harry that 2822 From: is a *LARGE* part of anti-forgery 
efforts, or it should be, anyway.  I won't give it *only* status, or even 
*highest* status, but we will have failed to do our jobs if we don't 
provide a way to validate From: addresses.  A less-desirable but still 
semi-acceptable solution is to validate Sender: if present and From: if 
Sender is missing, and flag the user to notify him that Sender: was checked 
and From: wasn't.

Our work is primarily aimed at MTAs, and I don't want to place a dependency 
on MUA writers, to make them do something before our proposal can be called 
a success.  It's one of the *desired* outcomes, to give the MUA some data 
to display so that the user knows validation has happened.  But, I don't 
want to require it, nor even wait around for it.

Something I mentioned before... the MTA *does* have options if we want to 
notify the user of something, without depending on the MUA.  One of those 
options is to alter the From: address to add (unverified) to the pretty 
name... or to add (unverified) to the subject line, or to the top of the 
message's first text part.  Such a "brute force" mechanism for 
communicating to the end user is not the best way to get the message 
across, but for some cases it may be the only way available... plus it 
gives us something we can recommend to admins who have a large installed 
base of various MUAs.

Another point to ponder.  If we decide that there are cases where we want 
to validate Sender: and we CAN'T validate From: (such as something passed 
by a list)... would it also be useful to some folks to publish rules like 
"Always validate From: and do not use Sender: to override?"  This might 
give PayPal and friends a way to send messages from their "Role account" 
which should *never* go to a mailing list, and that particular From: 
address would always be checked, even if we default to checking Sender: 
most of the rest of the time.

My opinion is, if there are published rules for MAIL FROM: I will 
definitely use them, and if there are published rules for From:/Sender: I 
will definitely use them.  Both are important to me.

--
Greg Connor <gconnor@xxxxxxxxxxxx>