From: Benjamin Geer <ben(_at_)socialtools(_dot_)net>
...
Again, I realize that the DCC is far from perfect. That is one rason
why I've talked about it far less than other things here, and less
than other people have talked about their favorite mechanisms.
So let's talk about it. Could you summarize the problems of DCC (I know one
or two have been mentioned here already)? Perhaps this group could give
some thought to whether those problems could have technical solutions.
The main problem with the DCC and similar filters is obvious and has
been mentioned here. It is fundamentally unfixable, and so I'd rather
not talk about it in public.
Tactics like the DCC should be assumed to be effective only against
"mainsleaze" or spam from the Fortune 50,000. The current flood of
drugs, loansharking, and other frauds will eventually be controlled
by legislation that makes it a serious crime to not pay the "universal
mail access infrastructure free" of $0.001 to $0.10 per target.
Corporate spammers like Topica, DoubleClick, Microsoft, and Dell will
be happy to pay and reluctant to appear to be old style evil spammers
by being creative in their filter avoidance.
This list has not heard from the industry leaders in spam defenses
including Brightmail and Postini. Even SpamAssassin and the so called
Bayesian filtering people hasn't had much to say. I think most if
not all of them are (or were?) represented here. Consider why they've
had little or nothing to say. Their filters are all at least somewhat
effective, but could doubtless be improved.
I've noticed distinct, albeit superficial changes in spam in my traps
after remarks made here, so talking about limitations in existing
filters could be costly. Committees are rarely effective in attacking
straight technical issues even when the participants understand the
technical issues. Some ASRG contributors don't (or didn't) know the
difference between an SMTP error status and a DSN. Many contributors
with better technical understanding seem to be limited in the spam
they see to a few dozen/day. Thus, talk here about existing filters
risks a high cost for the fliters but small likelihood of benefit.
This group should concentrate on its charter, including defining the
problem, defining what unsolicited mail has implicit concent, and
writing BCPs about filters (e.g. filtering "SHOULD" be done during
the SMTP transaction and their SMTP messages "SHOULD" include clues
to help with false positives).
A BCP that says that MUAs "SHOULD NOT" generate HTML by default or at
least unless the sending user selects some formating is another good
thing that a group like this could produce, but evidently won't.
("SHOULD" and "SHOULD NOT" in the special sense of an RFC.)
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg