Professional Software Engineering:
I'm operating on the email addresses.
And I can't follow that approach.
Only a limited amount of spam isn't rejected (here) by DNSBL (incl.
geographical) or other SMTP-phase checks, like:
- No or no matching reverse (IP-nr --> name)
- Wrong HELO / EHLO
- No (proper) whois / ipwhois
- RFC-ignorance, like No postmaster, No abuse
- Bouncing when rejecting is required
- Bad / badly configured spam/virus filter software
- No existing MX / MX that doesn't accept mail
With this system, based partly on block-lists that one manages oneself,
a little white-listing is required.
http://www.rfc-ignorant.org/
http://www.rfc-ignorant.org/policy-postmaster.php
Some suckers from The Netherlands:
http://www.rfc-ignorant.org/tools/lookup.php?domain=casema.nl
http://www.rfc-ignorant.org/tools/lookup.php?domain=chello.nl
http://www.rfc-ignorant.org/tools/lookup.php?domain=hccnet.nl
http://www.rfc-ignorant.org/tools/lookup.php?domain=upc.nl
http://www.rfc-ignorant.org/tools/lookup.php?domain=verizon.net
http://www.rfc-ignorant.org/tools/lookup.php?domain=wanadoo.nl
Some other suckers:
http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com
http://www.rfc-ignorant.org/tools/lookup.php?domain=paypal.com
Examining just a small number of
recent messages, I see .es and .nl coming from korean IP space
With SMTP-rejecting off, I get a lot of messages with faked From:
addresses like that. But I only switch SMTP-rejecting off for testing
purposes. I SMTP-reject Korean IP-space. What kind of messages where
these ".es and .nl coming from korean IP space"?
I guess one could cross reference the sender TLD and the IP space the
message was relayed via
I see mainly harm in measuring the sender TLD.
Multi-RBL check:
http://rbls.org/
This is also a nice approach, but it requires filtering URLs from the
body:
http://www.surbl.org/
http://www.surbl.org/links.html
SMTP-rejecting at the end of the DATA is still better than (accepting
and) discarding.
Example of an anti-virus DNSBL:
http://virbl.bit.nl/faq.php
Stalling IP-nrs that are not in a cache with all the most recent
connecting IP-nrs, does also work well. Make newcomers wait for a few
seconds and give them a 4xx temporary error, and put their IP-nr in a
special temporary cache. If they don't come back withing a few hours,
forget about them. If they do come back, only then do all kind of
SMTP-checks possible, and add them to the IP-nr cache only if all OK.
Beware: aol and yahoo don't like 4xx, so again some whitelisting will be
necessary.
--
Grtz, Ruud
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail