I have an issue which suggests hMailServer is incorrectly using the MAIL FROM address's domain to add a DKIM signature.

I have hMailServer set up as a smart host in front of our Exchange 2003 server specifically to perform DKIM signing of our outgoing mails. We have multiple domains hosted by our Exchange server, and use Ivasoft's ChooseFrom + SmartReply products to allow users to send emails out using any of their secondary addresses (e.g. me@secondary.com) as their 'From' address in addition to their primary address me@primary.com. What happens, then, is that Exchange places the correct me@secondary.com address in the message header 'From' field, but Exchange uses me@primary.com in the SMTP envelope MAIL FROM command.

I have set up all of our domains in hMailServer, and enabled/configured DKIM for each of them. the appropriate DNS TXT RRs are also set up for each domain.

What hMailServer then does is to use the domain from the SMTP envelope (i.e., primary.com) for DKIM signing rather than the domain from the From header (i.e. secondary.com), so there is a mismatch between the From address and DKIM signing domain.

By my understanding of DKIM, hmailServer *should* be using the domain of the 'From' address, and this is the real point of DKIM, is it not? As unauthorised senders don't have access to the private key of the 'From' address's domain, they can't properly sign their emails. If they are able to sign their emails with any old domain's DKIM keys, it kind of invalidates the whole thing.

Now, my understanding of DKIM may be wrong here, but otherwise it seems that hMailServer isn't adding the right signatures.

Surely it's the other way around. Anyone can forge a from header to be anything from anyone, You want DKIM to make sure it's signed from your server using an authorized account.

I'm no DKIM expert and I haven't had any issues with my setup but then I'm not using it in the same way you are. If you can show some RFC's for DKIM showing it should be using the from header instead of SMTP Envelope From then it will be looked into.

Also lets play devils advocate here for a second. Assume you are hosting lots of domains for lots of different people and one of these guys happens to find out about another domain that's hosted on hMail and thinks, I know, If i send my spam out through my server and set my from header to his domain, DKIM will be signed from his domain and he gets in trouble.

hMail would have to sign the DKIM because it would have to trust the from header and it has the private keys for that domain. So you have to fall back to using SMTP Envelope From as that HAS to be authorized with a password and is therefore a 100% trusted source.

RFC 5617 (for DKIM DSP) states the following:



Now, that makes it clear that the DKIM signer's domain must match the 'From' address domain (not the SMTP MAIL FROM domain). Yes, From addresses can be spoofed, and that's the point here - a spoof sender does not have access to the real domain's DKIM private key, and therefore cannot sign it as the authentic domain owner. He can easily sign it on behlf of a different domain but ADSP seeks to nullify that by requiring a matching signer's domain name.

Yes, there is an issue here, but its one of implementation rather than of specification. If hMailServer is implemented by an ISP then you want it to isolate senders' access to DKIM signing, to prevent a sender on one domain from spoofing another. In this case, signing according to the SMTP envelope makes sense. However, when hMailServer is implemented in a private MTA (e.g., a corporate mail server) hosting multiple domains you want it to sign according to the From address, as in my own situation.

hMailServer could cater for all the possible configurations by offering a per-domain option to sign according to MAIL FROM or 'From'.

Well those RFC's seem fairly clear you should submit a bug report http://www.hmailserver.com/devnet/?page=issuetracker and link to this post.