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 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
>
_______________________________________________
spamdyke-dev mailing list
spamdyke-dev@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-dev
