At 22:32 2002-09-18 -0400, Kevin Coyner wrote:
Spammers harvest this legitimate address from our site, and send spam to it
in the form as appended below.
Consider using ordinal-encoded mailto addresses. I call the process
"mailfuscation", and in about five years of using it, it's been very good
at keeping addresses from being found by spambots in the first place. If
you did that CONSISTENTLY, across your whole site, and changed the contact
address listed, you'd find a significant drop in spam since the new address
wouldn't be harvested as easily. There's always some manual spam - people
who harvest addresses by hand, but those are fairly rare, and tend not to
find their way into distributed address lists.
For an example of ordinal encoding, see my disclaimer and view the source
of the mailto link at the bottom.
with a recipe. The only common elements seem to be the To: address
(which I don't want to block as we do get legitimate mail at this
address) and the fact that the message body is always as below, which
seems to be pages of encoded html or a picture?
Well, do you have *ANY* reason to be accepting application attachments at
the contact address?
:0
* ^To:(_dot_)*camps(_at_)triathlonacademy\(_dot_)com
* B ?? ^Content-Type:[ ]*application/octet-stream;
spew.mbx
You might not want the ^To:, in the event that the messages are BCC'd to
you (a fair amount of spam does come that way, dunno about your case). If
the mail account is hosted in a separate user account, then this doesn't
pose a problem (or perhaps you have an X-Envelope-To: header which you can
use), since you won't then be clobbering potentially legitimate email
attachments.
Otherwise, given the small fragment, the above should deal with that type
of thing, presuming the Content-Type is consistently the same. You could
improve scan speed by checking for the Content-Type: in the header
(probably "multipart/mixed"), which you'd add after the address check but
before the B(ody) condition.
If you administer the server, might I suggest that you consider using DNSBL
rules in the MTA? That addresses a large portion of the spam right up
front AND avoids you taking the bandwidth hit for receiving the attachments
in the first place.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail