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 [email protected] | 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 [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
