On Monday 22 September 2003 08:34 pm, Karsten M. Self wrote: <brevity snip> > > > 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.
No. > > > > > 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? > Analysis of the messages in the pending queue. > > > > Percent of challenges to joe-job victims: 0.00 > > > > > > Again, how do you assess this? > > > > Again, Ditto. > > Ditto. > > > > > Percent of challenges to someone other than the initial sender: 0.00 > > > > > > Again, how do you assess this? > > > > Ditto > > 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. > I can not be forced to accept your mail. If you somehow succeeeded in placing unwanted data within our network, we would consider it trespass at the very least. > 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: > Our users are all officers, employees or agents of the firm 47USC202 does not apply. > 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. I apologize. We have very different ideas of what a sysadmin's responsibilities are. > > > 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 I let more that one or two pieces of spam per 5000 emails get as far as spamassassin, I would consider that I had failed in configurin our MTAs properly. > > > 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. Wouldn't know. We compile from source. > > - 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. I've never said spamassassin was bad. It is a tool. TMDA is a tool. TMDA can accomplish one thing spamassassin can not...guarantee no spam gets to user mailboxes. > > - 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. I am running spamassassin 2.60 after having upgraded from 2.60rc6 I know what spamassassin can do. I also know what it can't do. > > > 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? MTA stuff first , then spamassassin, TMDA and clamav. Clamav is totally redundant since we 550 all attachments. TMDA is our last line of defense. It is there in case I screw up. I prefer maintaining our network to keep garbage out. I am really getting tired of people trying to force their version of right and wrong down my throat. -- Robin Lynn Frank | Director of Operations | Paradigm-Omega, LLC Email acceptance policy: http://paradigm-omega.com/email_policy.html Our current s$p%a&m-t*r#a^p: [EMAIL PROTECTED] _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
