[unisog] .edu's who use SpamCop?
feenberg at nber.org
Wed Dec 17 12:39:58 GMT 2003
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
> 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.
More information about the unisog