[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] SICS



(Responses to multiple messages included.)

"Walter Dnes" <waltdnes at waltdnes.org> wrote:
> On Tue, Dec 21, 2004 at 10:52:59AM +1000, Laird Breyer wrote

>> Would it be accurate to say that ASRG is interested in Z-mail
>> prevention solutions where Z-mail is a label for some set of messages,
>> and Z-mail can be taken to be spam? 
. . .
>  The thing that you may be missing is that "one size does not fit all".
> One man's spam is another man's ham.

More important, I think, is that having a single definition of spam
works against solutions.

Somebody has a system that works well against Type X spam, and wants
to improve it.  Arguing that it isn't good because it ignores Type Y
spam just wastes effort.

Then somebody else comes up with a system that works OK against Type Y
spam.  If they both spend their time arguing over whether "spam" means
"Type X" or "Type Y" that's time they're not spending improving (or
combining) their systems.

> Rather than a "spam-blocking" program labelling something as spam
> and blocking it, we should have an "unwanted-email-blocking
> program".  When the spammer's lawyer screams "It's not spam, it's
> ooga-booga.  Stop blocking my client's emails with your
> 'spam-blocking' program", we should respond that it's really an
> 'unwanted-email-blocking-program'.  And that our customer has
> indicated that he doesn't want your email.

That doesn't work: the spammer will get a shill to sign up with your
ISP and claim he _wants_ the spam.

Laird Breyer <laird at lbreyer.com> wrote:
> On Dec 21 2004, John Levine wrote:

> The charter does emphasise that the ASRG is looking for well
> specified problems, and makes it clear that a multitude of
> techniques to tackle them is desirable. As such, doesn't that
> encourage attempts to define spam?

No, that discourages them, because having one blessed definition works
against having multiple techniques each of which is most effective
against a different part of the problem.

> The original message you responded to suggested a possible
> definition, followed by a link to some protocol which takes
> that definition as a basis. I guess I don't see what prompted
> you to warn against attempting to define spam. Could you explain?  
>
>> My position is that any anti-spam project has to identify the flavor
>> of spam that the project is attempting to address, but I don't expect
>> projects all to address the same thing.
>
> I agree with that position.

But having one definition works against that.

gep2 at terabites.com wrote:

> Of course, as far as the recipient, THEIR decision about what is
> spam and what isn't, and what they want to receive and what they
> don't, is the ONLY opinion which matters in the final analysis.

Providing your goal is to market your services to them, yes.

> This is yet another reason why a fine-grained permissions-based
> approach, where the *recipient* can decide what E-mails they do and
> do not want to receive (based on who the sender is, and what the
> mail contains) is so decidedly the right way to pursue this problem.

It is _a_ right way.  It is not the only one.

>  Especially with threats of attorneys et al, there is NO feasible
> way for a spammer to try to sue a recipient who has chosen to refuse
> to accept, or read, the mail a spammer has tried to jam into the
> recipient's mailbox.

You might have noticed that spammers don't limit themselves to
"feasible" lawsuits.

gep2 at terabites.com wrote:
> On 22 Dec 2004, John Levine <asrg at johnlevine.com> wrote:

>>>This is yet another reason why a fine-grained permissions-based
>>>approach, where the *recipient* can decide what E-mails they do and
>>>do not want to receive (based on who the sender is, and what the mail
>>>contains) is so decidedly the right way to pursue this problem.
>
>>So long as you are willing to spend an unlimited amount of money on an
>>e-mail infrastructure that accepts and stores terabytes of spam,
>>almost all of which will be discarded unread, 
>
> You are presuming that (1) spamming will continue to be lucrative;

No, just that it will continue to be done.

> that (2) an approach such as I envision will reduce neither the
> numeric number of spam messages nor their average size;

or at least leave those numbers large.

> and (3) that spammers will continue to be able 
> to recruit zombie spambot armies to do their mailings for them.

That's certainly likely for the foreseeable future.

> First off, I believe that a fine-grained permissions list (with
> permissions based on who messages come from, along with what the
> nature of the contents of those messages are) and which by default
> will not allow either "large", HTML or attachments from untrusted
> senders, together will virtually eliminate E-mail as an effective
> vector for recruiting spambot zombie armies (it will in fact
> virtually eliminate the efficacy of sending worms and viruses in
> E-mail messages).

In order for it to eliminate zombies, it has to be implemented by
_everybody else_.  That's not going to happen.

> Secondly, making HTML-burdened E-mail acceptance CONTINGENT upon the
> sender being whitelisted by the recipient

You're assuming that you can tell whether or not the _recipient's_ MUA
will attempt to interpret a message as HTML.

> Third, making spam filtering more effective and harder to defeat or
> evade will dramatically reduce the payback to spammers, and the
> payback is what motivates spamming in the first place.

For some spammers, maybe.  Many others sell their services, and the
worldwide shortage of suckers is not expected soon.

>>and a fabuously complex
>>spam filter control panel that almost nobody will use, 
>
> Oh, that's TRULY rubbish.  While obviously it would be CONCEIVABLE
> to implement such a filter in a stupid and clumsy way, a reasonable
> implementation could make this VERY user-friendly (far more
> user-friendly, in fact, than typical "security permissions" for NTFS
> file systems).

Prove it.  Come up with a reasonable implementation that my mother can
handle.

>>ISPs tell me that when they have crummy filters that leak a lot of
>>spam, people are constantly asking to be able to tune the filters.
>
> The fact is that users who are able to simply and easily control
> THEIR OWN spam filtering, using techniques which are understandable
> and logical, are less likely to require as much ISP support.

As spammers learn to evade those controls, the ISP has to upgrade
them.

>>If you're in the United States, please consider them in relation to 47
>>USC 230 and section 8(c) of CAN SPAM.
>
> I don't think that's relevant to what we're talking about here (at
> least not what *I* am talking about).  I'm not talking about
> companies, individuals, or governments suing spammers, I'm talking
> about spammers (or those whose behavior might arguably look like
> spamming) suing (or threatening to sue) ISPs.

Did you read those?  They provide _immunity for ISPs_ for good-faith
spam filtering.

gep2 at terabites.com wrote:

>> The user has still made a clear decision - one to delegate their right
>> to accept/refuse to the ISP. As long as the ISP's contract makes this
>> clear, then I believe there's no difference in the 2 cases. 
>
> Sounds good, until the "spammer" can find a case (even just ONE)
> where the intended recipient actually WANTED the E-mail in question,
> and said user didn't feel they had in fact granted their ISP the
> 'right' to MIS-BLOCK mail that the user actually wanted.

Then the ISP show the contract the user agreed to, and the law
granting it immunity.

> Now, perhaps you can come up with a contract/TOS that has enough 
> waivers and disclaimers in it,

And every ISP already has; have you looked at any?  (I have, and they
all say the ISP can do what it wants.)

> but I still think that the "spammer"/"mailer" 
> will probably have adequate claim to bring it up in court, SOMEWHERE.

I don't care what the laws in Spamzania say.

>> The user can exercise choice by switching to an ISP which allows greater
>> control by its users (and as John has pointed out, probably charges a
>> premium to cover the costs of offering that control).
>
> I think you're being far, far too presumptuous about the
> practicality of switching to a different ISP.  Maybe you haven't
> been paying attention, but the ISP world has been consolidating (and
> especially if we're talking about broadband type services... okay,
> yes, dialup ISPs are more plentiful).

Mail Service Providers are growing.  They don't have to provide
Internet access; some people prefer buying unbundled services.

>  So if I didn't like Comcast's terms (and I don't, for example, like
> their policy of blocking port 25, which would enable me to send mail
> through my own domain provider's SMTP server) what, exactly, are my
> choices for switching to a different ISP?

$100/year for a Panix account with shell, mail, Usenet, etc.

$0/year and up for email accounts with Outblaze, gmail, Yahoo, . . .

> Meanwhile, even if one presumes that I'm therefore going to use
> Comcast for my connectivity, the fact that Comcast insists on
> blocking port 25 pretty well precludes me from signing up with a
> different and more-satisfactory "ISP", at least for outgoing
> SMTP-type mail service.

A decent one uses "SUBMIT".

Seth

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg