Warning, after SLES upgrade, DKIM not working

[ChasR]

After upgrading to the SLES version of SMG, I found that the opendkim service was not working. I have traced it back to the last entry in the opendkim.conf file which read SOCKET="inet:4932". This was correct on the Ubunto system, but on the sles system should be something like Socket inet:4932 or Socket inet:4932@localhost. The existing entry generates a configuration error on starting the service.

I have tried both options, which now start the opendkim service, but this service does not start on a boot and needs to be started manually, and it also does  not put the cert into the outgoing  email.

I have opened a service request with Micro Focus, and will report back on the outcome.

Regards

ChasR.

[suziew]

There haven't been any OS updates yet, that's why it's not showing any. The version of 7.0.0.59 will go up if you install using the latest ova, but it's not required that you do that for SMG. All of the OS updates are not required for this SMG appliance, like it is with others. Also, other systems (such as Filr) using the SLES appliance show their updates there, where SMG does not, since the updates are done through the SMG UI instead.

Thanks,
Suzie

[ChasR]

Sorry for the confusion. My entry yesterday was regarding the DKIM problem, not updating the packages.

[ChasR]

Hi Mark,

Can you do me a favor and try something else on the SMG. I have a second service request for another problem I have with the SLES implementation, and I would like to see if you also have the same issue.

If you go into the web login on the SMG and go into quarantine section. All the quarantined items are here, and if I release one from here, then the email will appear as expected. This works fine for me.

However, if I try to release an item from the emailed digest, it shows as being released in the web console quarantine section, but the email does not appear.

If I then reboot the SMG, all digests that have been released by this second method now appear.

Can you try this out and let me know your findings please.

Cheers

ChasR.

[suziew]

@ChasR  The issue with releasing from the digest is a known bug. The fix should be in the update that is coming out tomorrow. You don't need to reboot to get them to release, the quarantine service just needs to be restarted under Module Status.

If you'd like the fix before the update, go ahead and open a SR and put in there that you'd like the digest release fix from bug gwav-2852.

Thanks,

Suzie

[ChasR]

Still no more progress on the DKIM problem, but releasing the emails from the digest is a know problem, and support have now given me a fix for this. Here was their reply:

The issue with releasing from the digest is a known bug. The fix should be in the update that is coming out tomorrow. You don't need to reboot to get them to release, the quarantine service just needs to be restarted under Module Status.

If you'd like the fix before the update, go ahead and open a SR and put in there that you'd like the digest release fix from bug gwav-2852.

There was a problem with gwava-release.php file which I replaced and fixed the system.

Can someone tell me that when I try to run the GWAVA update, the version shown is 810, but the update version is 610, and I get a warning. Is the 610 the SLES update version, and should I go ahead and proceed with the update.

Cheers

ChasR

[ketter]

The latest SMG on SLES appliance revision is 61 (not 610).  If you are seeing a current revision of 810, that is a remnant from an Ubuntu to SLES migration.  This is just a cosmetic issue and you can/should go ahead and update to the latest revision.  61 is the current one, but as I understand it, there will be a newer revision available sometime today.

[suziew]

Yes, go ahead with the update. The rev 810 was migrated over from SMG on Ubuntu. Since it has a higher number than SMG on SLES's rev 61, it's giving that warning and can be ignored.

[ChasR]

Posted a service desk request in January for this problem with Micro Focus. Got to February when they accepted that it was their problem, and still waiting for an update regarding this even though I have contacted them recently on a number of occasions. I must say that the support feedback has been extremely poor in this case.

I am still using the Ubunto build until I get some confirmation that the problem is fixed and that the new version which I had migrated can be patched:- It would be poor form to have to go through the migration process again.

Will post any updates (if and when) I receive them from micro focus.

ChasR

[thomasweis]

we have had an SR open for many weeks. In the meantime the patch has been released and also a new.ova.
However, no update comes via the update channel, the processing of the SR consists of announcements which are not complied with.
We have Bussiness Maintenace 24X7 but we don't get a solution
It's a shame....

[ChasR]

Here is another update I have tried. There was an update shown in the web console to version 88. Ran this, worked OK, but still no DKIM in the emails.

Next, there has been a 18.2 SP1 release recently. Tried this, started OK, however, go a fatal error ands the installation aborted. Tried again, still the same problem. 

Will update my service request and see if I even even get a reply this time. Not topo impressed with the service up to now.

Just as well the UBUNTO works OK.

Cheers

ChasR.

[ketter]

The release notes for 88 don't say anything about DKIM.  I heard that moving from Cyren to BitDefender (release 81) took a bit of resources, but the dev team was going to make bug fixes the priority after that was out the door.  I'm a bit disappointed also that 88 didn't include the DKIM fix, but hopefully it is in the next release and that release comes soon.

[ChasR]

Here is an update for users who have migrated from the ubunto system. The latest upgrade (95) DKIM DOES NOT WORK without modifications to the opendkim.conf file. This only applies to people who have upgraded from a ubunto system. The mod is curtesy of the helpdesk support after a good few hours of testing last night (+ whisky).

It is necessary to add the following lines to the bottom of the opendkim.conf file:

UserID opendkim:opendkim

#SOCKET inet:4932@localhost

Canonicalization relaxed/relaxed
Mode sv
KeyTable refile:/etc/opendkim/key.table
SigningTable refile:/etc/opendkim/signing.table
InternalHosts refile:/etc/opendkim/trusted.hosts
ExternalIgnoreList refile:/etc/opendkim/trusted.hosts
SOCKET inet:4932@localhost

After adding that restart dkim by typing: service opendkim restart

Unfortunately, it is necessary to regenerate the signatures, and update the dns record. I tried a few things but have not got the original signatures to work, so a regeneration is in order.

Hope this clarifies the problem and gives a solution to those who still have problems.

Cheers

ChasR.