On Tuesday 23 September 2003 12:46 am, Karsten M. Self wrote: <brevity not possible snip> > > 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? Fully, because if we found the content to be spam, we would add the address to be blocked at the MTA. > > 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. > I am sorry, but providing such information to someone whose primary purpose appears to be telling other people what to do, is not something I care to do. > > > > 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. > Tell me, since this is not the first time you have cited statute or case law, is your tactic to win by intimidation?
> > > common carrier anti-discrimination statutes: > > > > Our users are all officers, employees or agents of the firm 47USC202 > > does not apply. > > Fair enough. <more snip> > > 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. > > AWL is a great way to get spoofed whitelisted addresses as spam. If you've got spam to feed, you already have received it. That is incredibly inefficient. > > 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. > The consequences of such an act. > 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. I don't. We run a business, not a social club. Our sales are not done via the internet so meeting new people is a distraction. > > > > - 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. > We specifically accept gpg/pgp, pgp-mime. > > 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. > Since we have experienced big spikes in spam directed at us each time I have objected to attempts by people to dictate "rules" to others, I suspect there are party or parties unknown lurking on these lists, I will probably be too busy analyzing what they are trying to throw at us to reply. One parting thought. The fact that all direct/mass marketing organizations hate C/R is the biggest reason of all to recommend its use. -- Robin Lynn Frank | Director of Operations | Paradigm-Omega, LLC � 2003 Paradigm-Omega, LLC. All rights reserved. Unauthorized reproduction and/or dissemination is forbidden. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
