In <9156B81DAA29204989AD43E88688FAABF7EDF8(_at_)df-lassie(_dot_)dogfood> "Harry
Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
OK, that's it.
Fire at will! :-)
Well, nice dodge, but since I haven't see anyone named "will" on the
list, I'll fire at you anyway. ;->
2. If #1 fails then it tells us there's a high likelihood the mail
has traveled >1 hop. In that case, select as the purported
responsible domain (PRD) the first non-empty identity from this list:
Resent-Sender, Resent-From, Sender, RFC2821.MAIL FROM. Perform the
spoof check. If it passes we're good, otherwise, it's spoofed, or [...]
As I mentioned previously, I looked through my inbox and found that
there are people using the Sender: header right now and are doing so
in ways that it will not pass validation. (e.g. the mailbox is just
the local part or has an unqualified domain name.)
When such messages get forwarded or sent to a mailing list, these
messages will fail. It isn't just that the Sender: header isn't
always added as required, but also that it is added when it is not
required in ways that cause problems.
So, from a practical point of view, I don't think we can depend on the
Resent-* headers, nor the Sender: header.
I also think that email forwarders using/changing the resent-* and/or
Sender: headers is not at all consistent with the description of these
headers in RFC2822.
The Resent-* headers are described as:
: 3.6.6. Resent fields
:
: Resent fields SHOULD be added to any message that is reintroduced by
: a user into the transport system. [...]
I don't think an email forwarder is a user that is causing the email
to be reintroduced into the transport system.
Actually, RFC2822 goes on to say:
: Note: Reintroducing a message into the transport system and using
: resent fields is a different operation from "forwarding".
: "Forwarding" has two meanings: One sense [is by an MUA action]
: On the other hand, forwarding is also
: used to mean when a mail transport program gets a message and
: forwards it on to a different destination for final delivery. Resent
: header fields are not intended for use with either type of
: forwarding.
So, it seems pretty clear to me that email forwarders should not add
Resent-* headers.
I've recently discussed the use of the Sender: header in a reply to
PHB, but basically I don't think RFC2822 says that email forwarders
can touch it either.
So, out of the above list of identities, the only one that can be used
for email forwarders is the RFC2821 MAIL FROM. And, since you can't
tell if the MTA sending you email is an email forwarder, you can't use
these identities for any email.
:-<
Q2: Why not put RFC2821 MAIL FROM as the first identity in step 2?
A: Because that would *force* adoption of SRS.
[...] Or in RFC lingo, SRS can be a MAY, but
not a MUST.
If I understand you correctly, the above means that you think that the
envelope-from MUST not be validated. Is this correct?
If this working group decided that the envelope-from CAN be validated,
wouldn't this allow us to move the envelope-from to the beginning of
the list?
Q3: Spammers can still insert headers pointing to their own throwaway
domains that will enable them to pass the spoof check, right?
A: True, but senders can place the directOnly flag on their EPD to
indicate that a further validation against the recipient's safe list
ought to be performed.
I have real concerns about this. This seems like a very low hurtle
for spammers/phishers to jump through in order to hide their tracks
and continue using anyone's domain in the From: address. (As
mentioned previously, the Resent-* headers are generally not displayed
to the users.)
If the directOnly flag can't be trusted to work, would any of the
major phishing target domains use it? Who would use it? Why not
eliminate it?
If the "safe list" means the directOnly flag *can* be trusted to work
and not create lots of false rejections, why wouldn't most people want
to use it? Why not make it the default?
-wayne