On 1/18/07, David Nicol <davidnicol(_at_)gmail(_dot_)com> wrote:
okay you got it.
Before looking at it:
One hopes that the criteria therein will be a superset of the issues
enumerated on the "how to tell if you are an anti-spam kook" page
After looking at it:
right off (1.1.1), we're at
That's a fair point. I don't think the difference is hugely
significant. But I'm not convinced that "bulk" is really a necessary
constraint. OTOH I know we've had this discussion before and I have
*no* intention of starting it again, god forbid, so I'm prepared to
remove "spam" as the headline and replace it with Unwanted Mail
throughout the document, of which "unsolicited bulk mail" is certainly
part. This also addresses Walter's point about the S word being
pejorative but "i said so" being the recipients right.
Why Unwanted Mail? Because I think that the value of any solution is
in the removal
of mail which which we know will be unwanted *before* it reaches its
destination, the sooner the better to the point where preventing it
from being sent at all is the ultimate. The trick (or implementation
detail, left as an exercise for the reader...) is to identify it as
unwanted before it gets there. Whether or not it is solicited, bulk or
one off, doesn't really change the economics in which resources can
surely be put to better use than than the transportation or processing
of mail which isn't going to be read.
(2.3.7) on multi-hop transport
seems most debatable; specifically, a model of origniating administrative
domain, all-to-all, receiving administrative domain seems more realistic
Whilst I think you're right I shied away from designing any kind of
solution, or from making any random assumption about what anyone might
want to actually do (If only I could work out how to get someone to
pay me to do that!) in the interests of impartiality.
I also wanted to weed out proposals that don't permit even local hops.
(2.3.5) avoid centralized solutions
this, also a SHOULD NOT, seems like it would be difficult. Centralization
of things like reputation server registration seems inescapable, just like
central administration of top-level DNS.
I wanted to make this a MUST NOT, but I thought that I was probably
being too harsh. I think there are problems that can come with
centralised resources or central control and want to discourage people
from specifying them without clear justification. That and because it
will discourage people who think they can set themselves up as the
operator to gain influence or money.
(2.3.3) Don't re-invent identity and trust models
this section could be made stronger by listing the invented ones
that are not to be re-invented. I am not aware of a working multi-faceted
reputation server infrastructure, for instance, beyond the profusion of RBLs.
Yeah, reading that section through again now I'm sober ;-) it seems a
bit harsh, "don't re-invent" implies that you can invent something,
because you can't re-invent something which hasn't been invented at
all, but the text seems to claim that everything we'll ever need has
already been invented. It's not my place to say so. Perhaps listing
the inventions which needn't be re-invented would add clarity. It
might also reveal my ignorance, so feel free to list stuff.
All in all, after reading the document, it seems to me a nice draft
would be coupled well with a BCP document enumerating existing
solutions that answer various parts, or an index of BCPs, or even have
links to the BCPs embedded in it.
I refined it by evaluating current practices & products, and past
proposals (good and bad) against the conditions and fiddled it to fit
my subjective opinion of them, and what I understood to be the
consensus of this list. So I think this would be a possibility, and
not too controversial either. OTOH It would risk becoming out of date
very quickly if the people responsible for products which were listed
as wholly or partially non-compliant decided that compliance was
important for them, so someone would have to take ownership of either
maintaining a list or publishing a regular summary of current good
Towards a centralized IP-based reputation service:
If the end result becomes some kind of TOS enforcement standard; that would
Cool certainly but perhaps some way off yet.
Asrg mailing list