Re: Comcast blocking mail to its customers

[David Farber <dave () farber net>]

Begin forwarded message:

From: Tilghman Lesher <tilghman () mail jeffandtilghman com>
Date: October 15, 2008 7:32:17 PM EDT
To: johnl () iecc com
Cc: dave () farber net
Subject: Re: [IP] Re:      Comcast blocking mail to its customers

On Wednesday 15 October 2008 15:32:50 David Farber wrote:
> Begin forwarded message:
>
> From: John Levine <johnl () iecc com>
> Date: October 15, 2008 3:12:36 PM EDT
> To: dave () farber net
> Subject: Re: [IP] Re:      Comcast blocking mail to its customers
>
> > My view is that an appropriate AUP for email should be similar to
> > that of a common carrier or the USPS.  It's a critical service these
> > days.  Using robotic methods or wholesale IP shutoffs to dump
> > presumptive spam into the trash is not acceptable for such a
> > service.
>
> The mail stream that ISPs see is typically 95% spam these days.  That
> means 20 spams for every real message, so if they were to accept and
> store all the spam, that's more than an order of magnitude increase in
> the size and cost of their mail system, which would be passed through
> to the customers, most of whom don't want it.  And even if they did,
> how much confidence do you have that you could manually sort it
> correctly?  I've seen plausible studies that say that mechanical
> filters are if anything better than humans at sorting large mail
> streams, since mechanical filters' eyes don't glaze over.

I think you missed the part which I consider to be most important,  
that of
dumping presumptive spam into the trash.  The most correct method of
filtering is to do it at SMTP time and reject the email then, rather  
than
trying to either a) accept all email and bounce the stuff that is
undeliverable (this is arguably what is most wrong with some MTAs, such
as qmail, as it causes the secondary problem of backscatter) or b)  
accepting
all email and tossing the stuff that a mechanical filter thinks is spam
(which means that a sender may never be notified that their message was
falsely flagged as spam).

Rejecting at SMTP time guarantees that minimal backscatter bounces are
generated and when an email is rejected as a false positive, the  
sender has
immediate feedback of the problem and can work to address the issue.
It is really no more computationally expensive than current operations  
(which
have to scan all email anyway, so they might as well do it at SMTP  
time).  In
the case of a flood of email causing problems with scanning (the prime
argument against scanning at SMTP time, that it does not scale), that is
easily addressed within the mail protocol, simply by sending a 400-level
error, indicating a temporary issue, which good MTAs use as an  
indication to
try the delivery again later.  Oddly, a 400-level error stops many  
spam bots
in their tracks, which will never reattempt delivery of the same  
message upon
receiving the first error.

--
Tilghman




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com