Topic: DKIM signing not working? [SOLVED]

[DanB35]

Following the discussion at https://forums.contribs.org/index.php/topic,52341.0.html, I decided to try to set up DKIM on my server, but it doesn't seem to actually be signing my emails.  I'm not quite sure where to check further.

I generally followed the instructions at https://wiki.contribs.org/Email#DKIM_Setup to create the directory, create the keypair, copy it for each domain for which I send mail, chmod 700 (shouldn't it be 600?), extract the public key, create the template (and add a line setting the algorithm to RSA-SHA256, but I've tried without that line as well), and signal-event email-update.

Following my DNS host's instructions at https://fusion.easydns.com/index.php?/Knowledgebase/Article/View/185/7/spf-txt-and-dkim-records, I created two records: _domainkey.mydomain IN TXT t=y;o=~, and default._domainkey.mydomain IN TXT k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...  http://dkimcore.org/c/keycheck reports that there is a valid DKIM record for my domain.

The problem is that I'm not seeing any evidence that DKIM signing is actually happening.  When I send an email to a remote account, I don't see a DKIM-Signature: header, and the validator at check-auth@verifier.port25.com reports that the email isn't signed.  /var/log/qpsmtpd/current doesn't seem to log anything for outgoing mail.  Where should I look to try to track this down?

[DanB35]

My question regards general operation of the stock features of SME 9.1, as documented on the wiki at the link I gave.  Why was it moved to the General Discussion board?

[Stefano]

Sorry, my fault.. It should be in 9 contribs

[byte]

Have you checked the email's headers?  I've set this up the other day using those instructions and I can see the DKIM info in my email message headers.

[DanB35]

Yes, I've checked the headers of the sent messages.  From what I can find, I should see a DKIM-Signature: header (possibly among others), but I don't.

[byte]

Sorry, my fault.. It should be in 9 contribs

Surely, this should be in the main sme forum as this is not exactly a contrib but an enhanced feature of the main sme core.

[byte]

Yes, I've checked the headers of the sent messages.  From what I can find, I should see a DKIM-Signature: header (possibly among others), but I don't.

That's right, here is a little snippet of my headers...

dkim=pass (test mode) header.i=@smefixit.co.uk
Received: (qmail 4806 invoked by uid 453); 18 Mar 2016 12:59:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=smefixit.co.uk; h=received:from:subject:date:message-id; s=default; [............]

I used this site to check my SPF/DKIM...

https://www.mail-tester.com/spf-dkim-check

[DanB35]

I've set this up the other day using those instructions and I can see the DKIM info in my email message headers.

That at least suggests that the instructions are good--they aren't outdated, incorrect, or otherwise inapplicable to an SME 9 server.  That helps.  So, there must be something about my installation that's causing this to not work.  Still not sure how to track it down, but that's a good data point.

[byte]

That at least suggests that the instructions are good--they aren't outdated, incorrect, or otherwise inapplicable to an SME 9 server.  That helps.  So, there must be something about my installation that's causing this to not work.  Still not sure how to track it down, but that's a good data point.

I would go back to those instructions and just confirm each step is followed and configured as there maybe something simple missing hopefully

Also, check the /var/log/qpsmtpd/current log and see if the DKIM plugin is being loaded when sending an email.

[DanB35]

Well, don't I feel dumb...

I wrote in my original post that nothing was being logged to /var/log/qpsmtpd/current when I sent a message.  I didn't see anything at the time, but when I try now there definitely is stuff logged there (maybe I was inadvertently looking at the wrong file?).  That led me to permissions on the .private file; once I fixed them, it now works.  Lessons learned:

• You must have a copy of the dkim.private file for every domain, including your primary domain, for which you want to send DKIM-signed mail, as domain.tld.private.  The wiki page does say this, but I'd originally misread it as applying only to additional domains.
• The *.private files must be readable by the qpsmtpd user

The way I got here was by creating dkim.private, copying it to domain2.tld.private and domain3.tld.private, extracting the public key, and changing ownership on the dkimkeys directory to qpsmtpd:qpsmtpd.  Then, once I realized my error from the first bullet point, I made another copy of dkim.private to domain1.tld.private, and did not change ownership on that file, so it was owned by root:root with permissions of 600.

With that said, the wiki calls for permissions on that file to be 700.  Doesn't seem to me that the execute bit needs to be set.  Is there a reason for that?

[DanB35]

Surely, this should be in the main sme forum as this is not exactly a contrib but an enhanced feature of the main sme core.

Agree that this thread belongs where I originally put it.

[Stefano]

Surely, this should be in the main sme forum as this is not exactly a contrib but an enhanced feature of the main sme core.

There was a request to moderation team to move it

[byte]

There was a request to moderation team to move it

Doesn't mean it was the correct request to move it, I'm sure you could have had some input and suggest this was the wrong action rather.

[janet]

byte

Doesn't mean it was the correct request to move it, I'm sure you could have had some input and suggest this was the wrong action rather.

I think it is correct to move this thread to Contribs forum, as changes were made based on a Howto, so it is no longer a stock standard SME as per default installation setup or standard server manager configuration possibilities. For this definition Contrib = Howto.

[byte]

byte
I think it is correct to move this thread to Contribs forum, as changes were made based on a Howto, so it is no longer a stock standard SME as per default installation setup or standard server manager configuration possibilities. For this definition Contrib = Howto.

I still disagree, no contrib has been installed, the DKIM feature is already in the sme server core, you just needed to make a few changes to enable this feature that has been built in to the sme server core.  The entire https://wiki.contribs.org/Email has features already in the sme server core, even the wiki page description says "[...]the email subsystem used in SME Server [...].

This wiki page https://wiki.contribs.org/Category:Contrib is for contribs and no mention of DKIM is on this page.

[janet]

byte

You are applying the wrong definition to determine how this thread should be "filed".
Rather than using the definition "no contrib has been installed" & therefore concluding that this thread should be in the SME9.x forum, I suggest you read the forum headings.
SME Server 9.x
Discussion of the use of *ONLY* the components and features included on the SME Server 9.x CD

SME 9.x Contribs
Discussions related to development and use of addons for SME Server. Discuss user-contributed rpms, howto's and scripts here.

Note the Contribs forum category refers to howto's.

If you look at the bottom of this page (which is the wiki article referred to in this thread)
https://wiki.contribs.org/Email#DKIM_Setup
it is a Howto
& it details adding a custom template, so standard sme server settings are changed, so it is no longer a stock standard sme server as installed from the CD.

[byte]

byte

You are applying the wrong definition to determine how this thread should be "filed".

OK, you win, not sure why I really care about this 

[DanB35]

Creating a one-line custom template fragment is no more a "contrib" than is setting a config database entry from the CLI that isn't exposed in the server-manager.  And if following a "how-to" article means the thread belongs here, there'd be nothing left to go in the SME 9 forum.

There's a (strong, IMO) argument that this question is perfectly appropriate in the base SME 9 forum--all I'm doing is trying to turn on a feature that's already packaged with SME 9.  The argument for calling it a contrib, I guess, is that you have to use the shell to do it, because there isn't a button in the server-manager to turn this on.  Or, maybe, that the wiki told me how to do it?

So is that the dividing line?  Anything that requires that you use the CLI is automatically a contrib?  That doesn't leave much for the SME Server 9.x forum.

[janet]

DanB35

I think you are interpreting things wrongly also.
You keep using the word "contrib" as the criteria, but the SME 9.x Contribs forum category title is more wide ranging than this, as it includes Howto's as well as contribs & other scripts & mods etc.

Also the SME9.x forum excludes by definition any changes made to the base system, which includes custom templates. Things can go amazingly wrong if a custom template is written incorrectly & the base system cannot really be blamed.

It is pretty clear to me.
The definition of content & which Forum category it should go into, is defined by the Forum title
ie
SME Server 9.x
Discussion of the use of *ONLY* the components and features included on the SME Server 9.x CD

SME 9.x Contribs
Discussions related to development and use of addons for SME Server. Discuss user-contributed rpms, howto's and scripts here.

So is that the dividing line?  Anything that requires that you use the CLI is automatically a contrib?  That doesn't leave much for the SME Server 9.x forum.

No that is simplifying it too much.
If a feature can be changed using the standard settings or the standard accepted range of variables that are catered for by the sme server code, by using either the server manager, console menu, or command line, & using the standard templates (as installed), then yes it is a base sme9.x issue.
If that range of settings is modified to include variables that are not in the base install eg by using a custom template, then it becomes a sme9.x contribs forum issue.
Isn't that clear ?

I can see why there is interpretive variation here ie we are tweaking an existing plug in, but the above is how I read it in a strict sense ie we are tweaking an existing plug in, but out of the range of standard provided settings.