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

[jm at jmason.org (Justin Mason)]

"David Nicol" writes:
>On 1/22/07, Daniel Feenberg <feenberg at nber.org> wrote:
>> Comments:
>
>Comments on comments:
>
>> 1.1.1 I would resist making the definition of spam so receipient
>> dependent. If every receipient gets to make his/her own definition, then
>> it tends to prevent cooperative solutions from looking satisfactory, and
>> the the purpose of the IETF is to facilitate cooperative solutions. For
>> example, if spam has no objective definition, then each user must maintain
>> their own DNSBL, or list of spamassassin regular expressions. I would have
>> thought the purpose of this group was to suggest ways for MTA operators to
>> cooperate to reduce spam - individual solutions don't require the IETF.
>> There are also the cases to consider of ISPs who ignore messages to abuse
>> - does that make the messages spam?  I think we should stick with
>> "unsolicited commercial email" as a workable spam definition.
>
>the upside of using a very general definition is that it necessitates
>a many-sizes-
>to-fit-everyone system of solutions.

For what it's worth, we in SpamAssassin use "unsolicited bulk email" as
our definition  -- religious spam, for example, is still spam in our book.

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).  It's too
subjective, and would outlaw DNSBL usage, as far as I can tell...

>> I hear so many complaints
>> about the overloading of DNS with other tasks
>
>in my opinion, DNS is perfect when you want a distributable cached database
>of information that does not change that often.  Name to number mappings
>fit this, of course, but so do a lot of other kinds of information.  I have seen
>suggestions dismissed as "requiring a trick DNS server" as if that requirement
>is some kind of unvaultable bar, which it is not.  In the event that other
>data sets get served over DNS infrastructure with some popularity, some system
>administrators may need to revise their capacity planning documents for
>faster upgrading of local dns caching hardware.  This is not a big deal either.
>In terms of (1) efficient network use and (2) in-place infrastructure,
>DNS is very good,
>and I see no reason not to use it when appropriate.
>
>
>> 2.3.1 is worthy of being singled out, however, since so many propsoed
>> solutions fail to allow strangers to communicate, and that is pretty much
>> the chief objection to the majority of proposed techniques.
>>
>> There is a surprising omissions - No mention of the superiority of
>> rejection during the SMTP processing over discarding or delivering to a
>> spam folder. Or did I miss it somewhere?
>
>I think that kind of detail is deliberately left out of the document which
>is designed to live at a high level immune from implementation details.
>
>> I worry that the point of the draft is to outlaw all spam reduction
>> techniques other than individually created and controlled content
>> analysis. At the very least users need to be able to cooperate or to
>> purchase anti-spam services from unrelated organizations, and without
>> common definitions and inexpensive communication of results, this will be
>> made unnecessarily difficult.
>
>I read the document as a call for better (distributed) interoperable reputation
>services, possibly violating Zooko's triangle; ergo the document passes the
>"everyone who looks at it sees something different" test for "work of art."
>
>> Would the author list some common techniques are [and] say if they meet
>> these standards, and if not, where they fail?
>>
>> Daniel Feenberg
>
>My growing suspicion is that the end result of this committee is going to
>be current practices enumeration and reccomendations, with a bottom line
>of "it isn't broken."
>
>David Nicol

--j.

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