[spamdyke-users] Spamtrap-like setup
Hi all, I'm managing a couple of mail servers, on which I have installed Spamdyke with qmail. Everything works great, but I want to further reduce SPAM I receive. So I thought, why not implement my own spamtrap? I want to create some e-mail addresses, that will not be used for communication, which I will hide into some of my websites. What I want is this: whenever a message is delivered to one of these addresses, the sender should be automatically added to the blacklist_senders file (or something similar to the same effect). Any suggestions? Thank you in advance -- Best regards, Eleftherios Chamakiotis Please consider the environment before printing this email. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamtrap-like setup
Dossy Shiobara wrote: Could use a .qmail file for each of those spamtrap addresses which passes the message off to a script which plucks out the sender's IP address (from the appropriate Received: header) and appends it to your ip-blacklist-file. Because spammers may send mail from legitimate hosts (rather than botnets) you may need to whitelist some IP ranges so that you don't inadvertently blacklist Gmail or Hotmail (in which case, things will suddenly get very quiet in your mailbox). I'd recommend AGAINST using the sender email address as it could result in a denial of service if someone simply forges a legitimate email address as the sender address. Pretty much any automated blacklisting is fraught with problems, for exactly this reason. Rather than auto-blacklisting, you might use the presence of one of your spamtrap addresses among the recipients of a message as evidence that the message is spam. Spammers often 'batch' messages, so that their message is sent to several addresses at the same domain in a single transaction. If one of the targeted addresses is only known to spammers, you can dump the whole message. I suggested this as a feature of Spamdyke a while back and Sam said that he might consider adding it in future. I don't know if there's any interim way of implementing this strategy using other tools. Angus On 6/22/11 9:33 AM, Eleftherios Chamakiotis wrote: What I want is this: whenever a message is delivered to one of these addresses, the sender should be automatically added to the blacklist_senders file (or something similar to the same effect). -- Dossy Shiobara | He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on. (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamtrap-like setup
Angus, Indeed, the support for spamtrap addresses in Spamdyke could be interesting - my design for such a feature would be a variation on the recipient blacklist. A list of spamtrap-entry addresses, if seen as an RCPT TO, will cause the message to be rejected at the DATA step. It is NOT wise to reject the individual RCPT TO, which I understand is how the current recipient-blacklist works -- spammers could just use that feedback to clean their lists. Instead, silently accept the spamtrapped RCPT TO, but reject the whole message attempt once the SMTP client tries to enter the DATA phase of the exchange. The spamtrap handling can't be implemented like another form of blacklist because Spamdyke currently tests whitelists before blacklists, but this spamtrap handling would have to be done separately from the filtering entirely. Otherwise, a whitelisted sender (Gmail, etc.) would defeat the spamtrap. The idea is basically, If the message includes any spamtrap recipient, no matter what other filters exist, refuse to accept the message. Thoughts? I could probably work up a patch against the latest Spamdyke, since I'm getting quite familiar with the code ... On 6/22/11 10:47 AM, Angus McIntyre wrote: I'd recommend AGAINST using the sender email address as it could result in a denial of service if someone simply forges a legitimate email address as the sender address. Pretty much any automated blacklisting is fraught with problems, for exactly this reason. Rather than auto-blacklisting, you might use the presence of one of your spamtrap addresses among the recipients of a message as evidence that the message is spam. Spammers often 'batch' messages, so that their message is sent to several addresses at the same domain in a single transaction. If one of the targeted addresses is only known to spammers, you can dump the whole message. I suggested this as a feature of Spamdyke a while back and Sam said that he might consider adding it in future. I don't know if there's any interim way of implementing this strategy using other tools. -- Dossy Shiobara | He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on. (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamtrap-like setup
Using something like this would be great, if all of the users used webmail or IMAP on their clients... Unfortunately, most of mine either use POP3 or I'm simply filtering their e-mail, so there's not really any folders to search through... I've often toyed with the spamtrap honeypot idea, using it to feed a private DNS based rbl... I've also thought of doing a whitelist (I guess you could call it a RWL :-) )... I don't, however, trust my users to submit Spam and use that as a basis for determining what is/isn't spam. My thought was to use a commonly spammed account that isn't valid on my domain, like webmaster, or admin, etc. Anyone sending e-mail to those addresses, on my domain, is spamming. Anything coming to those addresses should be blocked, even if it's only for a period of time... If I look at the spam runs that I occasionally get, most are random addresses that I don't think you would see much benefit from something like this. However, I do occasionally get a run where people are using *REALLY* old e-mail addresses that haven't been active in years. Those are spammers. Catching them early in their run would prevent valid users from getting their spam... As was suggested, perhaps SpamDyke isn't the best place to Create the blacklist, but using a .qmail file would be...And then utilize SpamDyke's existing features to query the RBL... Mike -Original Message- From: spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf Of Sam Clippinger Sent: Wednesday, June 22, 2011 9:12 AM To: spamdyke users Subject: Re: [spamdyke-users] Spamtrap-like setup From a technical standpoint, it shouldn't be too hard to implement. When triggered, the spamtrap filter would just set the CHILD_QUIT flag in smtp_filter(), which would cause middleman() to close its connection to qmail (so no more commands would be sent to the real mail server). Each filter is implemented in its own function and contains the logic to honor the whitelists/authentication -- it would be simple to omit this code for a spamtrap filter. I'm not sure how much actual spam this kind of thing would stop, however. It would rely on the incoming spam being sent in a batch, which doesn't always happen, and with a spamtrap address included, which could be unlikely if you have a lot of users on your server or if you're using the max-recipients filter. But more importantly, it would rely on the spammers scraping your website and starting to send spam to your spamtrap addresses, which could take quite some time to happen. On my own server, I get a lot more spam sent to random/guessed addresses in my domains than to actual addresses that are published online. Overall, I'm not sure I see the difference between running this kind of filter and just using a public blacklist like SORBS (which uses spamtraps to create the blacklist). I actually have a script running on my server that does basically this kind of auto-blacklisting (no, not the one we discussed a couple weeks ago but another one). It works like this: it goes through all of my users' mailboxes and parses the mail headers for recent messages to find the IP addresses of the remote sending server. It breaks those into three lists: IPs from messages found in Junk folders, IPs from messages delivered to spamtraps and IPs from messages in any other folder (Trash folders are ignored). If an address occurs 3 or more times in a Junk folder OR once in a spamtrap mailbox, it's blacklisted. If it occurs even once anywhere else, it is removed from the blacklist. My users are pretty good about clicking Junk on their spam, so this script essentially crowdsources the blacklisting logic. On my server, which admittedly hosts a relatively small number of users, it typically keeps about 30 IPs on the blacklist at any given time. I like this setup because it runs offline at a low priority. Because it looks at received email, it doesn't matter if the messages were delivered in batch/encrypted/whatever. Modifying the script to only look at the spamtrap mailboxes would be trivial. -- Sam Clippinger On Jun 22, 2011, at 10:27 AM, Dossy Shiobara wrote: Angus, Indeed, the support for spamtrap addresses in Spamdyke could be interesting - my design for such a feature would be a variation on the recipient blacklist. A list of spamtrap-entry addresses, if seen as an RCPT TO, will cause the message to be rejected at the DATA step. It is NOT wise to reject the individual RCPT TO, which I understand is how the current recipient-blacklist works -- spammers could just use that feedback to clean their lists. Instead, silently accept the spamtrapped RCPT TO, but reject the whole message attempt once the SMTP client tries to enter the DATA phase of the exchange. The spamtrap handling can't be implemented like another form of blacklist because Spamdyke currently tests whitelists before blacklists, but this spamtrap handling would have to
