On Mon, 22 Jan 2007, Justin Mason wrote:
"David Nicol" writes:
On 1/22/07, Daniel Feenberg <feenberg(_at_)nber(_dot_)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.
I'll accept that as an improvement over "unsolicited commercial email".
Daniel Feenberg
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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg