On Fri, 2004-09-03 at 08:02, Daniel Senie wrote:
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.
Any process which authenticates the MTA, including CSV, would allow such
a method of tracing. With Sender-ID or SPF, those administering the
policy for the MTA remain anonymous. Unlike CSV, the Sender-ID or SPF
name is not safely used for doing reputation assertions. After a name
for an MTA is established, prescribing an association of the mailbox
domain to a set of MTAs can be done using a simple list of names. With
a name list, no subsequent lookups are required.
-Doug