Actually, the spamdyke-dev mailing list is intended for discussion of
beta versions of spamdyke. Discussions of upcoming features are
probably better left to the spamdyke-users list, since more people
subscribe to that one.
For my first attempt at recipient validation, I'm not even messing with
the effects of (the many) patches for altering qmail's and vpopmail's
behavior (e.g. MySQL support). At this point, I'm only trying to
validate addresses the way a "stock" qmail installation does. I've been
reading the documentation found in the man pages for "qmail-control",
"qmail-users", "qmail-send", "addresses", "envelopes" and "dot-qmail",
plus the file /var/qmail/doc/INSTALL.alias. They describe an (IMHO)
inexcusably convoluted process involving most of the files in
/var/qmail/control, the CDB file in /var/qmail/users, the /etc/passwd
file and who-knows-how-many .qmail files in various home directories.
As you say, it's mostly about reading flat files but, as always, the
devil's in the details. There's a _reason_ why packages like Plesk and
vpopmail are so popular -- doing it by hand is simply not realistic.
Interestingly, vpopmail uses qmail's built-in recipient mapping system
to route messages to domains and doesn't add any new black magic to
qmail's existing murky depths (AFAIK). I'm reasonably impressed with
what I've seen of it's design so far. I haven't investigated Plesk yet
to see how it works but I assume it's similar.
Anyway, DJB's documentation is only helpful as a rough guide and (in
what I assume is a prank on me) it's also WRONG (you may prefer a term
like "contradictory", "incomplete" or "badly written", but you may also
like to say "po-tah-toe" so we'll just agree to disagree).
Consequently, I'm spending even more time reverse-engineering qmail's
behavior by configuring various scenarios and sending messages to see
where they end up. Fortunately, I need to do a lot of this work anyway
so I can write test scripts for the validation code.
In summary, the code is about two-thirds complete. Then comes the
testing and documentation.
Regarding tarpitting, I think you may be misunderstanding my intent.
I'm thinking specifically of Tom Liston's "LaBrea" program for creating
what he called a "sticky honeypot". He used some simple methods of
altering the TCP connection to slow down (and stop) remote attackers who
were trying to spread the Code Red worm by "trapping" their connections
-- they were forever occupied trying to talk to his server and could not
escape. You can read about it but the code hasn't been updated since 2003:
http://labrea.sourceforge.net/
If I could implement something like this in spamdyke, it could seriously
slow down botnets. I understand it could also cause a lot of problems,
so it would need to be done very carefully. But as a former LaBrea
user, I can tell you that capturing and delaying infected machines is
very satisfying.
-- Sam Clippinger
Michael Colvin wrote:
> 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
