Hi !
Call me -- whatever :-) I took a look at SpamAssassin a while back, and (at
least at the time), it seemed to scan the mailbox file after the message(s)
were received. The program (again, at the time) was written in Perl.
This whole process seemed somewhat inefficient, and also allowed the spammer
to believe their messages were getting through.
I looked into blocking spam at the SMTP protocol level, and using the
sendmail milter api, wrote a blocker. What started out as a
hacked-together spam blocker (not filter) has become something which seems
to work very well. This one is written in C, and is quite efficient from
both a memory and CPU usage standpoint. It is a multi-threaded daemon, and
currently is running on a number of FreeBSD
machines, from 4.3 to the latest version.
The spam blocking process I used is pretty simple:
1) The forward and reverse name lookups for the connecting SMTP server must
exist and agree.
If this is not true, the message is rejected with a 550-5.7.0 reject
(with explanation). The spammer
knows the message failed.
2) The ip address of the server must not appear in any of the DNSBLs that
I'm using
If the address is on any of the lists, the message is rejected at the
protocol level, as above.
3) There is an option for blocking servers that are coming from a
"cust-199-190-54-2" (or various variants)
type of reverse lookup. This is very effective, but does yield a few
false positives.
4) The server's domain is checked against a couple of URIBLs
5) The sender domain is similarly checked
6) Optionally, SPF records can be checked
7) The subject is optionally checked for certain words and phrases.
8) The message body is checked (as it arrives) with an efficient scanner for
URLs. These are checked
against the URIBLs. Also, optionally, certain words and phrases can be
used to trigger a block.
Currently, I don't do this (the word/phrase blocks) as the other checks
seem to be more than sufficient.
Again, at each step, if anything triggers a block, the appropriate error is
immediately returned to the
connecting SMTP server, and the spammer knows the message did not get
through. In the event of a
false positive, there is no ambiguity as to whether the message arrived or
not. The sender knows
immediately.
All transactions, blocks, reasons, IP addresses, etc. are logged.
The blocker also maintains a number of lists such as local "whitelists",
blacklists, allowed hosts, local hosts,
allowed domains, and overrides for those who do not wish to have their
mailboxes free of spam, etc. Any
address to which a message is sent is automatically put on a whitelist.
Anyway, it seems to work nicely. On one particular site, I've blocked over
17 million messages since the
end of November '07.
The idea was to have something which worked at the protocol level to block
unwanted messages, and
which was very efficient.
The protocol level blocking is nice because the spammers remove you from
their lists, and eventually, the
amount of spam sent actually decreases. I've noticed this since running the
blocker, which has been
since about August, 2007. The amount of (spam) messages sent to us has
gradually decreased.
If anyone wants to test this, you're welcome to do so. Contacat me with
what you're running for
a platform, and I'll see if I can generate an executable for you.
Installation takes about 10 seconds -
add a couple of lines to sendmail.cf and to whatever you use to start
sendmail (you must start the spam
blocking daemon before sendmail starts), and you're done!
The program is highly reliable, and so far, I've never had a crash or hang!
I've only used it on FreeBSD
with sendmail, however I don't see any big issues with Linux or other Unix
variants using sendmail.
Sendmail version 8.14.2 or later is strongly recommended, as there are some
milter API bugs in earlier
versions.
Oh well, for what it's worth!
Regards,
Steve
[EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Yet-another-spam-blocker--tp15911630p15911630.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
