ietf-mxcomp
[Top] [All Lists]

RE: A proposal on identities

2004-04-20 10:29:19

On Monday, April 19, 2004 7:57 AM, wayne [wayne(_at_)midwestcs(_dot_)com] wrote


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. ;->

I would expect no less!  :-)



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.

Let's be clear about what we're doing in this WG.  We are attempting to
layer on top of RFC2821 and RFC2822 some additional semantics about what
constitutes acceptable email "behavior" in order to enable
authentication of MTAs.  By definition, the behavior we determine to be
acceptable will be a *proper subset* of whatever behavior is possible
today under the RFCs.   

So if messages get sent with Sender headers consisting of only a
localpart, sorry that's going to be unacceptable.

If someone Telnets into my MTA and sends me a message with no 2822 From
or Sender at all, as Hector Santos did last week, sorry that's going to
be unacceptable behavior too. (No offense, Hector!) 

We should strive to keep the set of acceptable behavior as large as
possible.  And we certainly have an obligation to give plenty of advance
notice that certain types of behavior are no longer acceptable.
However, if we get hung up on pathological cases like Sender headers
that contain localparts only, we're never going to get anywhere.  


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.

Unfortunately, the RFC is by no means clear on this point.  In fact it's
quite ambiguous.  

First the RFC states that Resent- headers SHOULD be added whenever a
user "reintroduces" a message into the transport system, without clearly
defining what "reintroduces" means or how it occurs.  Now presumably
under circumstances of some description, having seen a message delivered
into my inbox I can press a hypothetical 'reintroduce' button (if not,
then what are the headers for?). Having just received the message (so
the original recipient has seen final delivery), the reintroduction must
be headed for some other location; it must be a "forward" by *some*
definition of the word.

The RFC also talks about the "user" reintroducing the message without
specifying which piece of software is acting on the user's behalf.  The
key point is this: if it's OK (indeed recommended) to add these headers
when a human "reintroduces" a message into the transport stream, surely
it's OK for an automated agent to do that on a user's behalf.  

It boils down to the fact that the language quoted is not consistent: it
says use the headers, but not with "forwarding" (without defining the
term) yet clearly their only utility  is in conjunction with forwarding
by any reasonable definition of the word.

Lastly, the RFC states that Resent- headers are not "intended" for use
in some types of forwarding, but *does not* prescribe that they MUST NOT
be used in this way.  

Thus, we believe our proposed use of Resent- headers is indeed
permissible.  I would further suggest, given the threat posed to email
by the spam crisis, that this would be an "opportune moment" to broaden
the "intended" use of these fields. 


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.


:-<


As I hope I've made clear, I respectfully disagree.  :-)



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?

No, what I'm saying is that SRS MUST NOT be a requirement. 


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?

Does CAN mean MUST, SHOULD, or MAY?  In any case, if you move
envelope-from any higher in the list, that has the effect of making SRS
or VERP a MUST.  



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.)

And relying on the 2821 MAIL FROM is an even lower hurdle. (As mentioned
previously, we're eventually, somehow, going to have to inform users of
which header was validated.  Return-Path isn't visible to users either.)



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?

We could, if folks agree.  But there are lots of domains where users do
send mail to mailing lists (e.g. microsoft.com) so this may not be
practical for them.  I don't know where the majority fits here which is
why it's not currently the default.



-wayne





<Prev in Thread] Current Thread [Next in Thread>