From: Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
...
And it is not subject to network standardization. ...
VS> I suspect that is more true than false, but more than half of the spam
VS> control systems now in at least real trial use (stopping millions of
VS> spam/day) involve aspects that could be subject to network standardization
...
I could try to guess, it would be far more helpful to hear how "single
ended" mechanisms, like receiver filters, offer an opportunity for an
interoperability (ie, networking) standard.
For the entries on my list:
- Postini
detours mail through special MTAs that filter. The link between
the specialized filter MTA and the Postini customer's real MTA
is (or ouught to be--I don't really know) already standardized
as SMTP-AUTH or SMTP-TLS.
- Brightmail
communicates samples of spam from spam traps to Brightmail's
control center (centers?) and filter parameters, expressions,
checksums, or whatever back to customers. The protocol that
carries the filter parameters sounds like a good IETF/IRTF
standardization candidate, except that Brightmail is proprietary.
(I know little about Brightmail, so this is a guess.)
- MAPS's RBL using BGP feed
used BGP which has already been and continues to be subject to
network standardization.
- DNS blacklists including MAPS's RBL+, SBL, and SPEWS
used DNS which has already been and continues to be subject to
network standardization. DNSSEC sounds like a good idea here.
It might be good if the IETF/IRTF would standardize the values
returned by DNS blacklists. There is currently an ad hoc and
inconsistent protocol using IP addresses in 127/8 to mean "this
sender is a bad spammer," "this sender might be bad," "this sender
was bad," and other things.
Then there is the possiblity of a protocol that fits the question
"should I accept a message from this IP address or sender" better
than DNS PTR RRs.
- Razor/Pyzor
communicates checksums of spam with what I think was originally
a purely ASCII protocol but is now somehow related to base64.
- DCC
communicates a total of several GBytes/day of checksums of spam
and target counts between thousands of mail filtering clients
and checksums clearinghouses with a UDP based protocol and among
clearinghouses all over the world over TCP. The binary UDP
based protocol can be viewed as a specialized RPC protocol and
has the usual authentication, retransmission, real time, and
other aspects of remote procedures. The TCP based protocol is
intended to communicate checksums of bulk mail to all of the
current more than 120 clearinghouses in the network within
seconds of discovery. It has typical authentication and other
needs. Both of those protocols could be subjects of the IRTF/IETF
if they did not already exist and if the guy responsible were
not so hopelessly not a team player.
VS> SpamAssassin can also be viewed as moving data around the net in support
VS> of its content filtering in the form of updates to the default scoring.
That fact that some software has contact with a network does mean that
it is a candidate for a networking standard. So please indicate what
mechanisms and/or formats you have in mind.
SpamAsassin assigns "scores" to dozens of features of a message. If
the score is high enough, the message is either rejected or set asside.
As common features in spam change, the set of scores that are most likely
to indicate evil change. SpamAssassin also uses regular expressions.
A naive and bad protocol would be to distribute control files or patches
to control files from spamassassin.org or an origanization's control
center. See http://www.spamassassin.org/doc/Mail_SpamAssassin_Conf.html
A better protocol might encode snippets of filter-expressions, default
scores, the identity of its source, and an authenticator, all more densely
than ASCII.
VS> - authentication
VS> - sender-pays (money, CPU cycles, or anything else)
VS> - challenge/response
Any spam-related mechanism that involves some sort of accounting or
management among independent, cooperating components offers reasonable
possibilities, too.
Yes.
I guess that I disagree with your statement that mere contact with the
network is not sufficent to justify IETF/IRTF consideration. Spam
always involves at least SMTP. There have been several proposals to
- modify SMTP delivery status notifications to avoid flooding innocent
mailboxes as a result of forged senders
- codify best current practices of filters to minimize sending DSNs
- improve DSNs so that people or computers could recognize spam filtering
- replace SMTP with something or other.
All of those could be considered or explicitly and officially rejected
by the IETF/IRTF.
There is plenty that the IETF/IRTF might do about spam. Based on the last
six weeks here and years of efforts elsewhere, I think the hard part isn't
the doing but ignoring noisy committee go-ers and other disruptions.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg