ietf-asrg
[Top] [All Lists]

Re: [Asrg] SICS

2004-12-22 13:23:52
(Responses to multiple messages included.)

"Walter Dnes" <waltdnes(_at_)waltdnes(_dot_)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(_dot_)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(_dot_)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(_dot_)com wrote:
On 22 Dec 2004, John Levine <asrg(_at_)johnlevine(_dot_)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(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


<Prev in Thread] Current Thread [Next in Thread>