[unisog] .edu's who use SpamCop?

Hunt,Keith A keith at uakron.edu
Wed Dec 17 19:39:15 GMT 2003


> -----Original Message-----
> From: Daniel Feenberg [mailto:feenberg at nber.org] 
> Sent: Wednesday, December 17, 2003 7:40 AM
> To: Paul Russell
> Cc: unisog at sans.org
> Subject: Re: [unisog] .edu's who use SpamCop?
> 
> 
> 
> On Tue, 16 Dec 2003, Paul Russell wrote:
> 
> > Our central mail servers are configured to check the 
> SpamCop and ORDB 
> > network blacklists, and reject messages from hosts listed on either 
> > list. In the past 60 days, approximately 7.2 million 
> messages were presented to our mail servers.
> > Approximately 3.3 million of those messages were rejected 
> at the SMTP 
> > level due to network blacklist entries. The SpamCop blacklist is 
> > checked first, and the vast majority of the rejects were due to a 
> > listing on the SpamCop blacklist. In the same time period, 
> we received 
> > less than 10 complaints regarding legitimate messages which were 
> > rejected by our mail servers due to network blacklist entries.
> > 
> > We have sendmail configured with FEATURE('delay_checks'), so we can 
> > whitelist any host, domain, sender, or recipient, and we currently 
> > have approximately 90 host, domain, or sender entries on 
> our local whitelist.
> > 
> > We run MIMEDefang, SpamAssassin, and anti-virus software on the 
> > central mail servers. All messages accepted by the mail servers are 
> > scanned for viruses, and messages identified as mass-mail 
> virus carrier messages are discarded.
> > 
> 
> 
> Note that the default implementation of RBL checking in 
> Sendmail and at least some other MTAs REJECTS suspected spam 
> during the SMTP transaction, rather than DISCARDING or 
> BOUNCING it. This is highly desirable for the case of a false 
> positive, since the sender receives a clear message from his 
> MTA notifying him that the message did not go through. If the 
> spam decision is deferred to local delivery time then 
> suspected spam must be discarded, since 99% of suspected spam 
> messages will have a forged from address. You don't want to 
> bounce a DSN to that address, as it may bother an innocent 
> third party. If you merely discard the suspected spam, then 
> the occasonal false positive may become a serious problem, 
> resulting in possible bad feelings or lost opportunities for 
> your users.
> 
> Virtually all content-inspection systems for spam control 
> operate at local delivery time, and will have this defect. An 
> exception is CAN-IT. At the moment we are using the MAPS RBL, 
> which generates nearly zero false positives, but is 
> excessively lenient, in my opinion. It does charge, which we 
> feel is an advantage. The free RBLs do tend to give in to the 
> anger and frustration of the operator from time to time. I 
> don't blame them, however, their work does benefit us all by 
> keeping ISPs alert.
> 
> Sendmail also has a "Spamfriend" feature which allows you to 
> designate certain mailboxes as exempt from RBL checking. We 
> use it on the postmaster and abuse mailboxes, but it can also 
> be used to defuse objections from users with friends at 
> unsavory ISPs. This requires the delay-checks option
> - otherwise the rejection occurs before sendmail even knows 
> who the message is intended for.
> 
> Delivery to a special spam folder is often suggested as an 
> alternative to discarding it. If the user has to scan the 
> spam folder regularly, the procedure doesn't achieve 
> anything, however.
> 

I respectfully disagree.  The user does not *have* to scan the spam
folder.  If she is convinced of your absolute accuracy in classifying
spam, why would she bother?  And I would guess you would assume that
case since you have decided not to deliver mail addressed to her.  On
the other hand, you have left no option for the user who might want to
make that decision for himself.


> 
> Daniel Feenberg
> 
> 
> 
> 


Keith Hunt  330.972.7968  keith at uakron.edu
Internet & Server Systems
The University of Akron 

   



More information about the unisog mailing list