ietf-mxcomp
[Top] [All Lists]

RE: (DEPLOY) In Support of Sender ID

2004-09-03 19:25:30

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Daniel 
Senie
Sent: Friday, September 03, 2004 11:02 AM
To: Meng Weng Wong; ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: (DEPLOY) In Support of Sender ID

At 02:42 AM 9/3/2004, Meng Weng Wong wrote:

On Fri, Sep 03, 2004 at 06:25:21AM +0100, Graham Murray wrote:
|
| Rand Wacker <rand(_at_)sendmail(_dot_)com> writes:
|
| > As I said before, there is a large majority of mail that
goes from large
| > commercial sites (or consumer ISPs) merely one hop to another large
| > commercial ISP, so the From: header will be successfully
authenticated.
|
| In the case of sending from a large ISP (and that includes commercial
| sites who outsource email) that is not true. Unless the ISP does
| additional checking then Sender-ID (and SPF) still allows a customer
| of the ISP to forge the mail as coming from any other customer of that
| ISP.

My read of most ISPs is that they are willing to move in
this direction if it proves necessary.  Many ISPs are
beginning to roll out (mandatory) SMTP AUTH.  With that in
place, halting cross-customer forgery becomes a much more
likely proposition.

To be a little more accurate, SMTP AUTH does not prevent customers of an
ISP or hosting company spoofing one another, but it does provide an audit
trail, so the person doing the spoofing can easily be identified from log
entries.

The real point (which I think Meng was trying to make) is that if we use
whatever this WG produces (assuming something useful is produced) a
mechanism that gets us back to the originating ISP, abuse at that
level can
and should be handled by that ISP. It may be beyond the scope of
this WG to
solve the internal abuse issues within an ISP.

Currently Sender-ID only gets us back to the ISP if the PRA is an address in
the ISP's domain.  In the case of a single hop, non-forwarded message from
the ISP, if from: is a different domain than the ISP's, PRA will resolve to
the from: domain and not the ISP: domain.  While the from: domain could
report any complaints to the ISP, by the time the matter was resolved, the
from: domain might already be blacklisted (assuming domain name based
blacklists again become popular).

I think it would be much better to insist that in this case the ISP domain
be the PRA by adding an appropriate 2822 header as I suggested earlier:

http://www.imc.org/ietf-mxcomp/mail-archive/msg04034.html

This gets us directly back to the originating ISP and also place the risk of
blacklisting where it belongs.  Since it would be the ISP's reputation that
would be at stake, they would also be more likely to be motivated to limit
cross-customer forgery in the first place.

Scott Kitterman