Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt

On Tue, 23 Jan 2007, Walter Dnes wrote:

> On Mon, Jan 22, 2007 at 06:51:26PM +0000, Justin Mason wrote
>
> > Defining spam as "email the user does not want" means that you cannot
> > safely filter spam, except with a user-trained classifier
> > (Bayesian-style probabilistic classification for example).
>  No, you're missing the point entirely, although it may be partially my
> fault for not making it clear enough.  Here's a Venn diagram.
>     ______
>    / ____ \
>   / /    \ \
>  | | spam | | <<== Unwanted email
>   \ \____/ /
>    \______/
>
>
>  "spam" is a slang word, which is often used to describe *A SUBSET OF*
> unwanted email.  Some legal jurisdictions have legislation that defines
> spam very narrowly.  If you insist on blocking "spam", you *WILL* end up
> spending a lot of time and money in court cases where...
>
>  1) the spammer insists that his spam is "not-spam" because of some
> technicality.  Expect to see lots of legal "is not spam; is so; is not;
> is so; is not" being billed at lawyers' regular rates.  And of course,
> you can rest assured that the politicians who enact legislation will
> make exemptions for solicitations for campaign contributions.  Any
> "spam-filters" that block any "not-spam" *WILL* get hit with
> cease-and-desist orders
>
>  2) saying that Joe Blow sends spam is equivalant to calling him a
> spammer.  Watch the defamation (libel/slander) lawsuits fly.
>
>  However, if you block "unwanted email" rather than "spam"...
>
>  1) spammer says "wahhh, wahhh, wahhh, my 'valuable information' is
> 'not-spam'" and you can enthusiastically agree.  The the customer still
> doesn't want it.  "Because I said so" should be sufficient reason.
>
>  2) By not labelling unwanted email as "spam", you're not labelling the
> sender as a spammer.  Spammers can still launch frivolous lawsuits, but
> at least don't give them legal ammo.
>
>  To summarize, *DON'T LET THE SPAMMERS PICK THE BATTLEFIELD AND SET THE
> RULES*, because they'll obviously stack the deck in their favour.  The
> best analogy is dealing with telemarketers, close cousins to email
> spammers.  The main rule is to *NEVER* give a reason for saying "No"
> other than saying "I don't want it; good-bye".  A competent (I dislike
> using the word "good") telemarketer will have been trained to refute
> just about every logical argument you can come up with to not buy their
> product.  These people are pros; this is their livlihood; they will
> argue circles around you.
>
>  Similarly, don't try to define "the S-word" in technical terms.  A
> bunch of geeks sitting at their keyboards are no match for a nit-picking
> lawyer who was the captain of his class debating team.  It's effectively
> a pro se defense against high-powered lawyers, and the results are very
> predictable.  Don't engage in a battle you can't win.  Go with...
>  - our customer says he doesn't want your emails.  No, we don't know
>    why he doesn't want your emails.
>  - the customer is always right; end of story.
>  Don't give the spammers' lawyers anything to attack.
>
> > It's too subjective, and would outlaw DNSBL usage, as far as I
> > can tell...
>  Not at all.  It does require separate rules for each customer.  The
> following is not a paid commercial, and I am not receiving in financial
> consideration for making these statements<g>...
>
>  - I am a customer of clss.net (Aurora Internet)
>
>  - they have a modified Qmail that generates 550 SMTP-stage rejects
>    (i.e. *NOT* a DSN) based on a customer-configurable control file in
>    the customer's home directory.  There are separate rule files for
>    sub-accounts.  E.g. I point my domain MX at their server.  abuse and
>    postmaster are basically unfiltered compared to this address.
>
>  - step 1 is to declare a whitelist of emails that I accept
>    unconditionally
>
>  - I don't want email from residential machines on dynamic IP addresses
>    sending direct-to-MX.  So I block based on dynamic IP DNSbls, regexp
>    filter against rDNS, and obviously block email from machines with no
>    rDNS whatsoever.
>
>  - I don't talk to myself.  I don't want email from people who lie in
>    their email, by including "waltdnes.org" in the HELO or return-path.
>    So I block those emails.
>
>  - I don't want email from certain /8's (RIPE, AFRINIC, LATNIC, and
>    most of APNIC (punch holes for Australia and New Zealand using
>    zz.countries.nerd.dk)), so I block those /8's.
>
>  - I don't want email from certain countries, so I block them, using
>    country-codes in rDNS and return-path
>
>  - I don't want email from addresses that are listed by Spamhaus,
>    because I said so.  Therefore I use Spamhaus' DNSbl.
>
>  - etc, etc.
>
>  Executive summary...
>
>  - blocking email, because it meets some technical criteria, is easier
>    on the technical side, but introduces legal problems
>
>  - blocking email, because the customer said so, may be harder
>    technically, but avoids legal problems
>
>  - any complications on the anti-spam side are outweighed by equivalant
>    complications on the spammers' end.  ISPs will have to enable end
>    users to configure their own rules, and everybody's filters and
>    whitelists will be slightly different.  Imagine how spammers will
>    feel knowing that each of several million targets for a spam-run has
>    a slightly different defense, that has to be overcome in order to
>    deliver the email.
>
> --
All I can say is, you are certainly welcome to block any mail you please, 
and no cooperation from other MTA operators is required, nor is any 
meeting of the IETF. The only purpose for the IETF involvement is to 
coordinate cooperative action. Since the IETF is voluntary, the action 
needs to be of benefit to all participants, and that greatly restricts the 
field of actions practical for widespread implementation. But it doesn't 
in any way restrict what you as an individual can do.
Since your method requires no cooperation from any other MTA operator, it 
doesn't require any endorsement from this group. That is fine - it doesn't 
make your method illegitimate or anything like that. But most users wish 
for a cooperative anti-spam technique, because they reasonably expect it 
will work better, and they reasonably expect many other MTA operators to 
cooperate with them. This has been true in the past - consider the many 
DNSBLs and other activities against spam. When we kept a list of spamming 
IP addresses sending to our MTA, we found after 2 weeks that only 1% of 
the IPs had send more than one message. Our subscription to Spamhaus kills 
about 65% of incoming messages. That is a victory for cooperation and it 
makes us think that more cooperation might be better.
It is true that cooperative actions attract lawsuits, but that is only 
because it isn't practical to sue an individual for refusing mail, but it 
is pratical to sue a corporation for blocking a large number of messages. 
If Spamhaus changes its name to Unwantedmailhaus, I don't expect that will 
affect its legal situation.
Daniel Feenberg


> Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org> In linux /sbin/init is Job #1
>
> _______________________________________________
> Asrg mailing list
> Asrg(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg