DKeyEvent - DomainKeys and DKIM for MailEnable [v 0.4.8]

Discussion, support and announcements for third party applications that work with MailEnable.
Post Reply
someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

DKeyEvent - DomainKeys and DKIM for MailEnable [v 0.4.8]

Post by someone_else » Fri Aug 05, 2005 4:21 pm

DKeyEvent 0.4.8 has been released. It is available free of charge for private, non-profit, and educational use.


So what does it do?

DKeyEvent is a pickup event for MailEnable, that signs and authenticates messages according to DomainKeys and DKIM specifications. Besides being designed to prevent 'identity spoofing' - i.e. claiming that mail originates from a different domain - by hashing each message on transmission, it can check whether a message has been altered prior to delivery, and, should it be the case, restore the message to its original form.




Some things to note

- After installation, make sure you take a look at the documentation, as it contains important information on how to configure DKeyEvent, and how to publish public key entries in your domain's DNS. Without these, signed mail will fail authentication.

- If you are using a router or firewall, make sure that DKeyEvent is given outbound UDP access to remote port 53 (DNS).

- To test your DomainKeys/DKIM signatures, you can send an email to < dktest at exhalus.net > or < sa-test at sendmail.net >.



Anything else?

No, that's it. Download it, use it and help fight spam. Let me know if you have and problems with it, and if you like it, some feedback would be appreciated.
Last edited by someone_else on Tue Feb 12, 2008 3:32 pm, edited 29 times in total.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

ark2
Posts: 32
Joined: Thu Apr 14, 2005 6:40 am

Post by ark2 » Fri Aug 05, 2005 9:04 pm

I will test it on professional right away, will let you know if there are any problems.

Thanks!!!!!


ok test it by emailing: sa-test@sendmail.net

ok I updated my ipsec policy, so now a new result, previously the 53 udp was blocked

getting:
Authentication System: DomainKeys Identified Mail
Result: DKIM signature confirmed BAD
Description: Signature verification failed, message may have been tampered with or corrupted
Reporting host: sendmail.net
More information: http://mipassoc.org/mass/
Sendmail milter: http://www.sendmail.net/dkim-milter

Authentication System: Domain Keys
Result: DK signature confirmed BAD
Description: Signature verification failed, message may have been tampered with or corrupted
Reporting host: sendmail.net
More information: http://antispam.yahoo.com/domainkeys
Sendmail milter: http://www.sendmail.net/dk-milter

Authentication System: Sender ID
Result: SID data confirmed GOOD
Description: Sending host is authorized for sending domain
Reporting host: sendmail.net
More information: http://www.microsoft.com/senderid
Sendmail milter: http://www.sendmail.net/sid-milter

Authentication System: Sender Permitted From (SPF)
Result: SPF data confirmed GOOD
Description: Sending host is authorized for sending domain
Reporting host: sendmail.net
More information: http://spf.pobox.com/

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

a bug

Post by someone_else » Fri Aug 05, 2005 11:15 pm

*FiXED*
Last edited by someone_else on Sun Aug 07, 2005 11:47 am, edited 1 time in total.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

what can I say?

Post by someone_else » Sat Aug 06, 2005 3:30 pm

You know, the irony in all this is that the problem was not so much with the program, but with the specification.

The issue lies with the 'simple' canonicalization. I have come to learn that there are currently two conflicting implementations in effect: Yahoo on the one hand, and others like sendmail.net on the other, and frankly there's just no way to make peace with both of them. In other words, signing to the specification of one will invalidate the mail according to the other.

Thus, while a 'fix' is in fact ready, I chose not to release it just yet. I have addressed the problem on the DomainKeys developer list, and am currently waiting for some consensus on which algorithm should be considered 'official'. Once this is confirmed, I'll release a fix.

I'm sorry for all this, but there is really little that I can do about the current situation...
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

ark2
Posts: 32
Joined: Thu Apr 14, 2005 6:40 am

Post by ark2 » Sat Aug 06, 2005 4:13 pm

there should be option to have the testing switch in the TXT string...

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

...

Post by someone_else » Sat Aug 06, 2005 4:14 pm

I'm affraid I don't quite understand what you mean...
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

ark2
Posts: 32
Joined: Thu Apr 14, 2005 6:40 am

Post by ark2 » Sat Aug 06, 2005 4:18 pm

I got to this page: http://domainkeys.sourceforge.net/policycheck.html

where it states that there is a possibility of setting a testing status for the domain, if it is possible to set it in the TXT record, you should add that option to your application

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

t=y

Post by someone_else » Sat Aug 06, 2005 4:28 pm

This is already implemented, but it has little (if indeed any) impact in the current matter.

You'll note that on the 'Domain' tab of the Setup application, there is a checkbox that says 'This server is testing DomainKeys', and which is checked by default. This is, in fact, what you are refering to.

However, this is a domain policy, which comes into effect on a failed signature authentication. Basically, if a signature is deemed invalid, the authenticator will check the domain policy, and based on whether 'testing' is enabled, it will decide what to do with the message (testing means that a failed message should be treated no different than unsigned mail). What this means is that if you mark your domain a being in testing, mail from you that fails verification should not find its way to the trashcan automatically. However, this has no impact on the authentication procedure; that is, an invalid message will still fail verification, regardless of the testing status.

Still, it's generally a good idea to keep the testing switch enabled until you are certain that your mail will verify. This is precisely the reason why this setting is enabled by default.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

forgot my hat

Post by someone_else » Sat Aug 06, 2005 4:30 pm

Oh, and by the way, thanks for the interest, and for helping test DKeyEvent.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

ark2
Posts: 32
Joined: Thu Apr 14, 2005 6:40 am

Post by ark2 » Sat Aug 06, 2005 4:42 pm

I'm very sorry, I overlooked it!

more questions:

I understand that the key never changes as long as selector doesn't change? I mean it's always generated the same....

also, what I would like even more, and I'm sure a lot of people using mailenable, would prefer as well would be an activex component or a .dll that would allow this generating from within asp script... any chance of that happening?

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

private-public key pair

Post by someone_else » Sat Aug 06, 2005 4:56 pm

I understand that the key never changes as long as selector doesn't change? I mean it's always generated the same....
Depends on which key you are talking about. There are in fact two keys - one private, and one public. The private key is used for signing and is generated when you create your selector (in the 'MTA' menu). The public key is used for authenticating messages and is derrived from the private key (this is generated by using the 'Domain' menu). Now as long as the private key is not changed, the public key will always be the same.

What you need to know, security-wise is this: the private key is important. Do not share it, and restrict access to it as much as possible. This is used to sign messages, so if anyone else were to obtain your private key, they could claim they were you, and thus the whole DomainKeys bussiness would be worthless. You'll note that DKeyEvent stores private keys in a dedicated folder - this allows you to set NTFS permissions that possibly dissalow access by users.

The public key is just that - public. It goes in your DNS, so everyone can see it. You shouldn't be worried about it.



P.S. I meant to include some security information in the documentation, but I didn't have the time. I'll try and mention all this in a future release.




also, what I would like even more, and I'm sure a lot of people using mailenable, would prefer as well would be an activex component or a .dll that would allow this generating from within asp script... any chance of that happening?
Probably not. The way I see it, COM objects should only be used for simple actions that are not resource intensive. This is because they run in the same memory space as MailEnable, and any problem they might have is automatically inherited by MailEnable (and you don't want that). Also, DKeyEvent relies on openSSL for encryption/decryption routines, so it really isn't possible to make DKeyEvent a self-contained object.

If you really want to call DKeyEvent from ASP, I suppose there's nothing to stop you from invoking it as a shell command (just like MailEnable does).
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

version 0.1.1

Post by someone_else » Sun Aug 07, 2005 11:40 am

Well, here it is: version 0.1.1.

I fixed the canonicalization issues, such as they were, and everything should be fine now. It seems that Yahoo servers are running an older version of the official DomainKeys implementation, which has a bug regarding 'simple' canonicalization. What this means, is that until such time as they decide to fix it, messages using 'simple' canonicalization will be listed by Yahoo as having been tampered with. Again, the messages are fine, but the algorithm Yahoo uses is flawed.

Anyway, you'll note that the default canonicalization setting in DKeyEvent is 'nofws'. This is recommended because it allows for insignificant alterations of a message without failing verification, and it is therefore the setting most servers use.


Again, feedback is appreciated.
Last edited by someone_else on Sun Dec 04, 2005 2:05 pm, edited 1 time in total.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

devildog
Posts: 45
Joined: Thu Jun 23, 2005 7:33 pm

Post by devildog » Thu Aug 11, 2005 4:21 am

how much of a CPU/memory hog is domainkeys?
ive downloaded it...will install to test when i have better internet access...
i just need to know is hashing/checking the emails a CPU intensive process?

i have ASSP runing which gets the email even before mailenable gets it (smtp proxy)
assp adds a header to all emails and the word "[SPAM]" to spams....
so if i use domain keys, will all emails fail the hash check??

just wondering...

someone_else
Posts: 302
Joined: Tue Jul 19, 2005 1:12 pm
Location: 404

on resource management, and extra headers

Post by someone_else » Thu Aug 11, 2005 4:47 am

devildog wrote:how much of a CPU/memory hog is domainkeys?...
i just need to know is hashing/checking the emails a CPU intensive process?
Yes, hashing (both for checking and signing) is a CPU intensive process. Now, of course, it all depends on the user base your server will be catering to; for a small to medium user base, you should have no problem with it - a large user base, however, with many concurrent messages, might see a significant impact on resources (CPU mostly, as the memory print is pretty small).

This is precisely why I have implemented a 'maximum filesize' option for both authenticating and signing; this way, you can limit the process to messages under a specified size. This is important because simple messages, even in large quantities should not cause a significant impact on resources - it is large messages (with attachments) that strain the CPU. Thus, if resources are a problem, you can limit DKeyEvent to working with small messages only, and thus keep resource use under control.



i have ASSP runing which gets the email even before mailenable gets it (smtp proxy) assp adds a header to all emails and the word "[SPAM]" to spams.... so if i use domain keys, will all emails fail the hash check??
It depends on two things: the signature of the message, and the way ASSP appends the header.

1. If incoming messages contain a 'h=' (header list) tag in the signature, then additional headers will not affect the message, which should verify correctly. ((the default when signing in DKeyEvent is to add a header list, and this is precisely the reason why))

2. If the signature does not contain a header list, then it depends on the exact placement of the ASSP header. As per the DomainKeys specification, when verifying a message with no header list, DKeyEvent uses only the headers below the DomainKeys signature. Thus, if the ASSP entry was added at the very top of the header (as is the general recommendation) then the message will verify correctly. If, however, the header entry is added at the bottom of the header, or if the original header is rearranged, then the authentication will most likely fail.


If you have any more questions, don't hesitate to ask. The documentation included in DKeyEvent is by no means sufficient, and I realize that not everyone has the time to read the DomainKeys RFC, so I'll try to clarify what I can.
MailEnable plugins:
DKeyEvent - DomainKeys/DKIM
MESpamC - SpamAssassin integration

devildog
Posts: 45
Joined: Thu Jun 23, 2005 7:33 pm

Post by devildog » Thu Aug 11, 2005 4:56 am

mail headder of a message marked spam...

Code: Select all

Received: from ([127.0.0.1]) for <xxx@xxx.com> with MailEnable Catch-All Filter; Wed, 03 Aug 2005 11:07:18 +0800
Received: from ([127.0.0.1]) with MailEnable ESMTP; Wed, 03 Aug 2005 11:07:17 +0800
Received: from 209.87.181.114 ([209.87.181.114] helo=dc1swweb01.swreg.digitalriver.com) by offshore-spam-buster ;  3 Aug 05 03:07:16 -0000
Received: from dc1swweb01.swreg.digitalriver.com (localhost [127.0.0.1])
	by dc1swweb01.swreg.digitalriver.com (8.12.11/8.12.11) with ESMTP id j7331qvr011983;
	Wed, 3 Aug 2005 04:01:52 +0100
Received: (from www@localhost)
	by dc1swweb01.swreg.digitalriver.com (8.12.11/8.12.11/Submit) id j7331qB9011981;
	Wed, 3 Aug 2005 04:01:52 +0100
Date: Wed, 3 Aug 2005 04:01:52 +0100
Message-Id: <,xxxxxxxx@dc1swweb01.swreg.digitalriver.com>
From: info@swreg.org (info@swreg.org via SWREG Sales)
To: xxx@xxx.com
Cc: xxx@xxx.com
Reply-To: info@swreg.org
Subject: [SPAM] Order confirmation xxxx
X-Assp-Spam-Prob: 1.00000
X-Assp-Spam: YES

the last 3 lines are added/modified by assp...
[/b]

Post Reply