Date: Mon, 23 Mar 1998 08:38:10 -0800 (PST) From: "Eric J. Schwertfeger" <ejs@bfd.com> To: freebsd-chat@FreeBSD.ORG Cc: Ollivier Robert <roberto@keltia.freenix.fr> Subject: Some useful procmail UCE filters Message-ID: <Pine.BSF.3.96.980323083216.5665A-100000@harlie.bfd.com> In-Reply-To: <19980322205417.A21974@keltia.freenix.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
I know not everyone is interested in filtering UCE, but I have received a few requests for my rules. Included are the rules I use that aren't also included in the junkfilter set of procmail rules. First, lets start with disclaimers: These rules will not reduce the amount of bandwidth UCE takes up coming into your system. For that, look at the sendmail patches to deny certain domains, though they are not as precise. Furthermore, I don't believe in /dev/null'ing email, except in cases where there is a 100% certainty that the mail is spam, and these rules aren't there yet. Also, these rules do catch normal spam that goes through unusual channels. For example, some of the people here, for reasons unknown, set up their machine to send their address as something@hotmail.com. These filters will consider those addresses spam, and the only way to get around it is by providing a list of exceptions. Second, I strongly encourage using these rules in conjunction with junkfilter, which you can find at http://mph124b.rh.psu.edu/~gsutter/junkfilter/ I stopped using junkfilter because the license requires you to install a seperate copy of junkfilter for each user, and I admin a site of 50 users who wouldn't recognize a regexp if it introduced itself to them, but the rules found there are much more general than these. Third, these are procmail rules, so you will need to adapt them to your setup, and install procmail if not already done. Finally (for the disclaimers), things change, and these rules need to be kept up to date. If you /dev/null the mail, then sooner or later, something's going to change, say the name of a mailing list changes, or some such, and you'll start loosing mail. I take no responsibility for lost mail, or mail that triggers the filters that is important enough that the delay in finding it causes problems. O.K., now for the rules themselves. This first rule catches better than 50% of the spam that comes to me directly. it does this by catching email that arrives at your mail server without a Message-ID: header, whereupon sendmail puts its own Message-ID on it. It doesn't catch spam sent throught the lists, though you could probably adapt it to do so by looking for Message-IDs coming from the list server, but without from addresses that look like they have anything to do with the list server. :0 * ^Message-ID:[ ]*(<.*@horst\.bfd\.com>) * !^Received.*(localhost|[@\.]bfd\.com).*by horst\.bfd\.com * !^From.*MAILER-DAEMON * !^X-Mailer: TFS Gateway { SPAMMER="our Message-ID on non-locally generated message" LOG="[$SPAMMER]" } In this case, horst.bfd.com is our mail server, and all email that gets sent out by us has a domain of bfd.com In the reverse of this, which doesn't catch much spam, but is here anyway, :0E * ^From:.*horst\.bfd\.com * !^Message-ID: <.*@horst\.bfd\.com> { SPAMMER="our local address on non-locally generated message" LOG="[$SPAMMER]" } This is saying that if it has a local address, but doesn't have a local Message-ID, then something is fishy. This is also less reliable than the above rule. This rule catches quite a bit of spam sent to the list. It does this by checking the To: and CC: field for the name of the list. This will call anything spam that got BCC'ed to the list, which is most often spam, and occasionally is a spat that I'd rather not get involved with. This rule gets modified every time someone finds a new address for the list and starts using it. it also seems to have a problem for some unknown reason if the list is the second (or possibly later) address on the CC: line. :0 * ^Sender: owner-freebsd-.+@FreeBSD\.ORG * ! ^(to|cc):.*[ <\'\",](freebsd-)?(afs|alpha|announce|bugs|chat|current|\ doc|emulation|fs|isp|hackers|hardware|isdn|java|jobs|mobile|multimedia|\ platforms|ports|questions|scsi|security|smp|sparc|stable|gnats-submit)\ @(hub\.|freefall\.)?freebsd\.org { SPAMMER="via FreeBSD list but not to FreeBSD list" LOG="[$SPAMMER]" } Now here's how I detect bogus spam with forged hotmail from addresses. As you can tell, I have two exceptions to these rules, and add other exceptions when I'm in a good mood. :0 * ^From:.*@hotmail\.com * !^Message-Id:.*hotmail\.com> * !^From:.*(nisbar1|kokorota)@hotmail\.com { SPAMMER="my forged hotmail/Message-Id" LOG="[$SPAMMER]" } :0 * ^From:.*@hotmail\.com * !^Received:.*(from|by) [^ ]*hotmail\.com * !^From:.*(nisbar1|kokorota)@hotmail\.com { SPAMMER="my forged hotmail/Received" LOG="[$SPAMMER]" } the next three rules catch a lot of the spam injected from uu.net, netcom.com and aol.com (the aol.com rule is very general, because the AOL mail relays strip this domain from the message, so that address should never turn up in an email). :0 * ^Received:.*((hotmail|juno|bigfoot|rocketmail|netcom).com|\ (usa|earthlink|netcom).net).*uu.net { SPAMMER="bigfoot/hotmail/juno/rocketmail/usa/earthlink/netcom via uu.net" LOG="[$SPAMMER]" } :0 * ^Received:.*((hotmail|juno|bigfoot|rocketmail).com|\ (usa|earthlink|uu).net).*netcom\.(com|net|ca) { SPAMMER="bigfoot/hotmail/juno/rocketmail/usa/earthlink/uunet via netcom.(com|net|ca)" LOG="[$SPAMMER]" } :0 * ^Received:.*\([^ ]+\.ipt\.aol\.com { SPAMMER="via aol.com dialup but not passed through aol mailservers" LOG="[$SPAMMER]" } Then along comes one of my niftier rules. This basically detects forged Received: headers that some spammers inject into the email so that they can forge an AOL email address and simple spam filters will accept that the email really did come from AOL. This rule can be duplicated for other frequently forged email domains, though I don't recommend simply modifying this one rule to match multiple domains. :0 * ^Received:.* by [^ ]+\.aol\.com * !^Received:.*aol.com.*^Received:.* by [^ ]+\.aol\.com { SPAMMER="forged AOL Received line" LOG="[$SPAMMER]" } The next set of rules catches some forged headers where the spammers are just too lazy to make sure their forged headers match the address they're forging. :0 * ^Received:.*[^a-z0-9]hotmail\.com * !From:.*[^a-z0-9]hotmail\.com { SPAMMER="via hotmail.com but not from @hotmail.com" LOG="[$SPAMMER]" } :0 * ^Received:.*[^a-z0-9]msn\.com * !From:.*[^a-z0-9]msn\.com { SPAMMER="via msn.com but not from @msn.com" LOG="[$SPAMMER]" } :0 * ^Received:.*[^a-z0-9]juno\.com * !From:.*[^a-z0-9]juno\.com { SPAMMER="via juno.com but not from @juno.com" LOG="[$SPAMMER]" } Finally, for those people that are webmasters, you'll love this one. I don't use any of my webmaster@ addresses for sending any email, so if someone is sending to it, they'd better not be BCCing webmaster :0 * ^Received:.*for <webmaster@ * !^(to|cc):.*[ <\'\",]webmaster@ { SPAMMER="bcc'ing webmaster" LOG="[$SPAMMER]" } These rules, in conjunction with junk.filter or something similar, has been catching well over 95% of the junk mail I receive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980323083216.5665A-100000>