I'm replying to you on the development list because I think the jist of my e-mail is more development related than just basic response to your post...Hopefully that's ok.
Anyway, in regards to your "ToDO" list that you posted, my personal thoughts are that the recipient verification and the "TarPit" mode would be tops... A couple comments directly on those two items... With the recipient verification, I know not everyone is using VPopmail w/MySQL (Or whatever DB), but seems like it would be easy enough to implement an SQL check against a DB. Those that don't use DB's, wouldn't you just need to check a flat file, or?? I know JMS uses a cdb file that he pushes out to each server... Or are you trying to allow for people that use IMAP or other authentication methods too? I could see where it could get complicated trying to allow for all possible options... Maybe start with the easy ones and work from there? With the tarpit option... This would be invaluable. Most of my spam issues, and those of clients I service, are from bot nets making spam runs and "Bombing" the servers. I was trying to figure out a way to take graylisted e-mails, check them against some recipient verification method, and if the greylisted e-mail is not valid, then delete it, but also harvest the source IP address of the e-mail, and dump it to a DB that can be used by a "Honeypot" process. I know we talked about the "Honeypot" thing before, and you rightly pointed out that simply blacklisting "Bad" e-mail attempts would be a bad thing..(What if someone typoed an e-mail). But, from what I've seen, I may get that same "Bad" e-mail from several IP's, or get several "bad" e-mails form the same IP. I think having some process that tracked those bad e-mails, logged both the e-mail address and the IP's, possibly in separate tables, and then, at some configurable threshold, let's say 5 instances, the "Honeypot" process would dump the e-mail address, the IP, or both, to a blacklist. This would facilitate an automatically updated blacklist against spam bots, or similar attacks... Or, maybe what you have in mind is better! :-) My thought with this was, by managing the graylisting, by deleting non-valid recipients, you don't allow harvest attacks (By rejecting invalids), but you are constantly graylisting them. Plus, if it can be done efficiently, why not harvest the information from these repeated invalid e-mails, to create an RBL that's very "relevant" to a specific mail servers specific spam..?? Or..Maybe I'm smoking crack. Not sure. :-) Michael J. Colvin NorCal Internet Services www.norcalisp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:spamdyke-users- > [EMAIL PROTECTED] On Behalf Of Sam Clippinger > Sent: Tuesday, September 23, 2008 6:53 PM > To: spamdyke users > Subject: Re: [spamdyke-users] DKIM etc. > > Am I reading these two links incorrectly, or do they basically say that > no one is using DKIM? :) > > Generally speaking, I'm not opposed to implementing DKIM, SPF or any > other domain authentication method. My only concern has been whether > the investment of effort would be worth it. For quite a while now, I've > felt my time would be better spent adding features that would have a > bigger impact than DKIM/SPF/whatever, especially considering the limited > time I'm able to devote to spamdyke development. However, given the > number of phishing scams based on eBay and PayPal, using DKIM to reject > those scams looks pretty attractive. > > How do you envision DKIM support working in spamdyke? If the connection > were not blocked by another filter before the message data was sent, > spamdyke would need to buffer the message headers and check the DKIM > signature. If the signature failed the check, what happens? Should > spamdyke just send a rejection code and close the connection? (There > are a lot of poorly-written mail clients that don't handle this > situation gracefully.) Should it add a new header or change one of the > other headers (e.g. Subject) to report the DKIM failure? Should it try > to buffer the entire message and deliver it to someone else? Should it > accept and silently discard the message? Should all of those things be > possible (but configurable)? > > Perhaps a better question is this: How do other MTAs handle DKIM failures? > > I've also got some pretty big features (growing stale) on the TODO list > (among many minor changes). I'm currently working on recipient > validation (which has turned out to be nearly as convoluted and > confusing as I had feared), so I'll definitely finish that up. After > that, loosely in order of priority: > Limited support for examining message headers so some headers could > be logged (e.g. Subject). > Rewriting/adding headers when filters failed instead of rejecting > the message entirely. > Replacing/adding recipients unconditionally (e.g. monitoring > employee email or redirecting addresses) or when filters failed (e.g. > sending all spam to a specific mailbox). > Full database support, especially for the graylist filter, to make > life simpler for administrators of large sites. > Automatic whitelisting to allow replies from recipients of outbound > email. > Daemon proxy mode to replace tcpserver and make spamdyke usable by > non-qmail sites. > Windows Service mode to make spamdyke usable by Exchange > administrators. > Tarpit mode to trap botnet spammers the way LaBrea used to trap Code > Red attackers. > As you noted, DKIM doesn't (currently) make my list; where should it be > ranked? > > -- Sam Clippinger > > Eric Shubert wrote: > > Eric Shubert wrote: > > > >> Sam, > >> > >> I see in the TODO file for 4.0 that adding SPF/CSV/Sender > ID/DomainKeys/DKIM > >> checking is ranked as a todo-later item. I don't care so much about > >> CSV/SenderID/DomainKeys, but I'd like to see the others implemented > sooner > >> than later. > >> > >> In particular, DKIM signatures are reportedly (2/08) being implemented > at > >> PayPal and eBay, and I'd expect other (large) financial institutions to > be > >> implementing it soon as well. I think it'd be great to have spamdyke > >> rejecting invalid DKIM signatures. This isn't so much simply an anti- > spam > >> measure, but a solution to a very real security threat (identity > theft). > >> > >> SPF checking is presently available in qmail-toaster, so that's not a > high > >> priority for me. However, I think it's more appropriately done by > spamdyke > >> than (a patched) qmail, so I'd like to see you do this as well. > >> > >> As far as DomainKeys goes, the qmail-toaster implementation of this, at > >> least on the checking side, is somewhat broken, so it'd be nice to > have, but > >> I don't honestly think it's being used, as it's being pretty much > replaced > >> with DKIM. My guess is that CSV and SenderID are also not worth the > trouble > >> to implement. > >> > >> I hope that others will share their opinions on this as well. I could > be > >> wrong (again). ;) > >> > >> Thanks for the great work with spamdyke. > >> > >> > > > > FWIW, some surveys regarding mail authentication: > > http://www.sendmail.org/dkim/surveyFortune1000 > > http://www.sendmail.org/dkim/surveyUsBanking > > > > > _______________________________________________ > spamdyke-users mailing list > [EMAIL PROTECTED] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-dev mailing list spamdyke-dev@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
