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@xxxxxxxxxxxx").
>
>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@xxxxxxxxxxxxx" 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@xxxxxxxxxx" 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@xxxxxxxxxxxxx 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