RE: (DEPLOY) In Support of Sender ID

["Scott Kitterman" <scott@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-mxcomp@xxxxxxxxxxxx
> [mailto:owner-ietf-mxcomp@xxxxxxxxxxxx]On Behalf Of Daniel Senie
> Sent: Friday, September 03, 2004 11:02 AM
> To: Meng Weng Wong; ietf-mxcomp@xxxxxxx
> 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@xxxxxxxxxxxx> 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