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
