(Responses to multiple messages included.)
"Walter Dnes" <***@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 <***@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.
> 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
> On 22 Dec 2004, John Levine <***@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
>>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
>>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
>> 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".