on Mon, Sep 22, 2003 at 06:55:27PM -0700, Robin Lynn Frank ([EMAIL PROTECTED]) wrote: > On Monday 22 September 2003 06:04 pm, Karsten M. Self wrote: > > on Mon, Sep 22, 2003 at 05:04:47PM -0700, Robin Lynn Frank > ([EMAIL PROTECTED]) wrote: > > > On Monday 22 September 2003 04:35 pm, Karsten M. Self wrote: > > > > As I have: > > > > > > > > http://kmself.home.netcom.com/Rants/challenge-response.html > > > > > > Remember that quote about, "lies, danm lies and statistics'? > > > > > > I checked that URL. You throw in a smattering of statistics and > > > pseudo-statistics and then make a whole boatload of assumptions. > > > > I quantify my results with spamassassin. Messages received, spam > > identified, ham identified as spam, ham identified as ham, spam > > identified as ham. > > > > While I don't have the data behind those particular statistics, I have a > > current corpus of mail and spam, and can derive values which will be > > markedly similar. I can also point to independently derived statistics > > pointing to grossly similar results. > > > > > You want quantified data? Try this: > > > > > > We have been using TMDA since version 0.33. > > > > In a stock configuration? Or with additional spam and virus filtering > > prepending TMDA C-R challenge issuing? The latter case mitigates most > > of my complaints against TMDA specifically, but not C-R as a whole. > > You didn't pay attention to my sig: Email acceptance policy: > http://paradigm-omega.com/email_policy.html
That would be a "No" then.
Interesting policies. They would be unacceptable to me from my ISP.
You're taking a huge false-positive hit.
> > > Percent of challenges to forged email addresses: 0.00
> >
> > What's your basis for this statement?
>
> Mail logs.
How do you assess that the sender was not forged?
> > > Percent of challenges to joe-job victims: 0.00
> >
> > Again, how do you assess this?
>
> Ditto.
Ditto.
> > > Percent of challenges to someone other than the initial sender: 0.00
> >
> > Again, how do you assess this?
>
> Ditto
Ditto.
> > You're missing a statistic: challenges not responded to. Since you've
> > already established that each of your challenges was issued to a
> > legitimate, non-spoofed address, It would seem that unanswered
> > challenges would tend to be legitimate mail for which the challenge
> > recipient elected not to comply with your system.
>
> Irrelavent. It is my right to determine what mail we accept. It is the
> sender's decision whether to accept our rules for accepting mail.
You cannot bind me to a contract without consideration.
Your users may disagree with your terms, however. And I may find them
misguided. I may even be able to find them a violation of federal
common carrier anti-discrimination statustes:
http://www4.law.cornell.edu/uscode/47/202.html
TITLE 47 > CHAPTER 5 > SUBCHAPTER II > Part I > Sec. 202.
Sec. 202. - Discriminations and preferences
> > > Now there is one thing you should ad to your web page. You should
> > > include information that you have no skills as a sysadmin. You might
> > > also want to add the assumption that you never will have.
> >
> > Do you really wish to libel me in public?
> >
> No sysadmin would put all their eggs in one basket.
The message you replied to specifically stated otherwise:
http://mla.libertine.org/tmda-users/2003-09/msg00233.html
I might add that I myself use a mix of whitelisting and spam
filtering (via SpamAssassin) to filter my own mail...
This is also discussed in more detail below, summarized that:
SpamAssassin itself is one-stop shopping for a large number of
specifically weighted, and configurable, spam assessment techniques. It
isn't single factor. It specifically is not single-factor in the sense
that TMDA C-R is, in relying on an assessment of trust for a forgeable
element of an email made on the part of an unknown, unauthenticated, and
untrusted third party.
> Sysadmins know that the most efficient way to control incoming mail is
> at the MTA level.
As I advocate:
http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03765.html
If possible, TMDA should be moved to SMTP-time filtering, so that
mail rejection occurs at SMTP time.
A portion of my mail *is* spamfiltered at the MTA. My primary user
account goes through Earthlink's POP3 server, taking this level of
control away from me. Earthlink's own spam filtering tools are a mix of
useless, opaque, and ineffective. So a large portion of my mail must be
filtered after POP fetch. And for a large portion of the Net, this will
likewise be the case.
> They also know that ancillary tools have a cost in system resources
> and must balance the cost in system resources with the results they
> provide.
Also considered:
http://z.iwethey.org/forums/render/content/show?contentid=117741
[AOL could provide Spamassassin filtering at] a price of $0.02 per
customer. Amortized over the life of the [system].
So: you have libeled me based on false representations of my statements
and practices.
I ask again if you with to libel me in public.
I am demanding an apology.
> That said, you asked if we used TMDA in stock configuration. The answer is
> no.
Thank you. Noted.
> Do you uses spamassassin in its stock configuration?
First: spamassasin in its stock configuration doesn't generate
thousands or hundreds of thousands of spam messages as TMDA _does_:
http://mla.libertine.org/tmda-users/2003-08/msg00085.html
http://mla.libertine.org/tmda-users/2003-08/msg00120.html
As I've made clear previously, C-R is broken by design in that it spams
in the name of spam reduction. SA doesn't have this fundamental flaw.
TMDA need not have it, but does.
That said, very nearly so.
Specifically, I've increased the BAYES_90 score and Microsoft executable
attachments score in the past week. I've added a cronjob to run every
fifteen minutes agains a 'spam-learn' folder where I toss false
positives. And the daemon remote tests are disabled. Other than that,
stock. And until about two months ago, it was fully stock. Literally
"apt-get install spamassassin" and walk away. As SA tags, but does not
directly filter mail, a rule in my filters was also required, but this
was independent of the SA configuration.
> If so yo must be getting spam sneaking throught at the 4.6 to 4.8
> level. Also, depending on which version of spamassassin you are
> using, you may be doing lookups against RBLs that no longer work or
> are under DDoS attacks and are therefor, unreliable.
There are several mitigating factors:
- As I said in my earlier post: I use a *mix* of methods. Including
procmail (which files messages according to rules, including SA
score), and a whitelist, in addition to pure SA. Prior to this, I
used a rather long and complex set of procmail recipies. I
abandoned this in favor of procmail for two simple reasons:
1. Spamassassin worked better. Caught more spam. Passed more ham.
2. Spamassassin is *far* easier to keep up to date. Breaking a
long set of procmail recipies is a PITA and we all know it.
- I run Debian GNU/Linux on my mailserver. This makes keeping
packages which change frequently (such as Spamassassin) updated
trivial.
- Spamassassin itself is adaptive even without updates.
Autowhitelisting happens automatically -- people with whom you
correspond on a regular basis are given a default score which tends
to ensure they aren't mislabled as spammers. With a very low
level of interaction required, SA's Bayesian classifier can be fed
spam or ham mail to increase efficiency of this classifier. I'm
finding the net performance to be quite good.
- As I've indicated, I maintain my own whitelist system, using shell
tools and procmail. To whitelist a message from a new user, I type
":wl-add" in mutt, and it's done. That's all the fuss. SA itself
includes, in addition to autowhitelisting, explicit white- and
black-listing capabilities. I've considered dropping my own
whitelist tools in favor of SA's simply to benefit from the group
development activity.
- I'm looking at clamav or a similar virus classifier. The proxy of
filtering against MSFT executable format attachments seems to cover
this need effectively.
- Finally, and you seem not to be aware of this: SpamAssassin is a
rich, multi-factor, content/context based tool. It uses a mix of
headers, IP lookups (if configured), Razor / known-spam registries,
content and message format rules, Bayesian classfiers, whitelists,
and blacklists, to assess the spamminess of a given piece of mail
_based_ _on_ _the_ _characteristics_ _of_ _that_ _specific_ _piece_
_of_ _mail_. It does so quickly, accurately, effectively, and with
a high degree of configurability if desired. It can be plugged
into MTAs or MUAs. It can filter inbound or outbound mail. It
works.
> You asked if we use any measures in addition to TMDA. Here is the list.
>
> Local access maps containing 39,000+ entries which include email
> addresses, domains, IP addresses, IP blocks, country TLDs and
> including 4700+ free email sources.
>
> Regexp and PCRE filtering of message headers, bodies and mime structures.
>
> Six RHSBLs and Six DNSBLs
>
> TMDA 0.84
>
> SpamAssassin 2.60rc6
>
> ClamAV
Thanks.
> Any further questions?
Sequence of application?
Peace.
--
Karsten M. Self <[EMAIL PROTECTED]> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
TWiki: documentation for the GNU millennium.
http://twiki.org/
signature.asc
Description: Digital signature
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
