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 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 _______________________________________________ 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
