(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(_at_)exchange(_dot_)microsoft(_dot_)com> 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(_at_)nekodojo(_dot_)org>