on Mon, Sep 22, 2003 at 10:48:59PM -0700, Robin Lynn Frank ([EMAIL PROTECTED]) wrote: > 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.
I take it we're not going to make much headway on this, but based on your inclusion of AOL, Earthlink, MSN, Hotmail, and Yahoo, you're excluding on the order of 40-50 million email accounts. You state you'll make exceptions, so I suppose it's more a roadblock than a wall. And frankly, the "make a prior arrangement" approach strikes me as more acceptable than the "challange all comers" model of TMDA/C-R. I'm not opposed, but I'm not adopting either. > > > > > 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. To what extent? This is really the crux of the issue -- I've had several go-rounds with C-R proponents who completely deny the existence of a false-positive problem. To the extent you're able to provide specifics, I'd be grateful. > > > 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. See Hamidi vs. Intel. You may not have much legal grounds for ordinary communications. Spam would be a different case. > > common carrier anti-discrimination statutes: > > > Our users are all officers, employees or agents of the firm 47USC202 > does not apply. Fair enough. > > 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. Funny. If I wasn't getting a few percent through, I'd be pretty certain we were locked down _way_ to tight. This presupposes that you do or don't want to talk to people. > > - 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. TMDA cannot guarantee you this. Unless you'd care to explain how an authorized sender is incapable of sending you spam. I can guarantee this with SpamAssassin as well -- it's got lots of nobs to frob. Set whitelisting levels appropriately, crank up the blacklist score, lower the spam tolerance, and you've wiped out all spam. Of course, this causes problems for someone who isn't pre-vetted. SA lets me talk to people I don't already know. Despite the spam. In realtime. I kind of like that. > > - 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. If it's redundant, why use it at all? And since you're blocking all attachments, you can't take advantage of GPG, PGP, or S/MIME signed or encrypted MIME-encoded mail? Pity. > TMDA is our last line of defense. It is there in case I screw up. You previously stated stats on misdirected challenges, all zeroed. How many challenges are you issuing, say, on a daily, weekly, or monthly basis? Given your setup, I'd suspect few indeed. > 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. WRT prior comments on offering TMDA support of third-party projects and their infrastructure, viz Debian, likewise. Peace. -- Karsten M. Self <[EMAIL PROTECTED]> http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Defeat EU Software Patents! http://swpat.ffii.org/
signature.asc
Description: Digital signature
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
