Sorry, this one missed the list..
---------- Forwarded message ----------
From: Danny Angus <danny(_at_)apache(_dot_)org>
Date: Jan 22, 2007 2:47 PM
Subject: Re: [Asrg] Comments: draft-irtf-asrg-criteria-00.txt
To: Daniel Feenberg <feenberg(_at_)nber(_dot_)org>
Daniel wrote:
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.
I understand what you're saying, but there are two things I considered
relevant, the first is that two individuals might have vastly
different opinions on the desirability of any piece of mail.
The second one is that if any individual can express their desire not
to receive an identifiable class of mail for *any* reason, propagating
that criteria into the transport system has the potential for
reclaiming bandwith.
There are also the cases to consider of ISPs who ignore messages to abuse
- does that make the messages spam?
It makes it "unwanted" and therefore it need not be sent which would
potentially save resources.
I think we should stick with
"unsolicited commercial email" as a workable spam definition.
I'm happy to try to revise this from that perspective, but I'm not
sure how artificial it will look, the only definition which was
obviously implied by the rest of the analysis was "unwanted", it may
look a bit artificial if the definition is changed. I'll give it a go
and maybe present a couple of alternatives.
2.2.1 Why the prohibition on the use of non-SMTP protocols?
...
Or perhaps the section means only that the mail itself should
not use another protocol.
Yes more or less, I actually meant that the process of delivering or
not-delivering mail should not require any communication by the sender
using anything other than the technology required for email. We've
seen suggestions involve logging into web-sites to verify your right
to send etc.
Then it should say so. I hear so many complaints
about the overloading of DNS with other tasks, perhaps I am reading them
into this section. Would adding another keyword to the SMTP protocol be
allowed?
Absolutely.
...
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 so, that whole premis of 2.1 is that the cost of operating
should fall with the introduction of the technique. Experience
suggests that it would be preferable to abandon processing as soon as
possible, but I didn't want to make judgements about how best the cost
saving might be achieved, as to do so would be to pre-judge based on
an assumption.
I worry that the point of the draft is to outlaw all spam reduction
techniques other than individually created and controlled content
analysis.
Not at all, many existing techniques stack up quite well against this,
dnsbl's, DK, spf etc etc would all be partial techniques which could
affect an overall reduction.
I hope that there is scope for choice as to the application of
criteria and the point at which they are applied.
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.
Agreed, but in that case you are really delegating your right to make
the decision by outsourcing it like you might outsource any other
aspect.
Would the author list some common techniques are say if they meet these
standards, and if not, where they fail?
I will do, but I don't have as much time as I'd like so it may be a day or two.
Thanks for your comments.
d.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg