It appears to me that DKIM can simply be implemented by writing a Mercury daemon, with the daemon parsing all the necessary fields, and adding the required headers to the outgoing message.
Unfortunately, all the are rather abstract, and do not show any example code, or pseudo-code at all, of a simple message, with an example public key, private key, and a verified message with all the required headers.
Thank you for your very detailed response. As far as I understand, it should primarily support PFS and choose that kind of ciphers with higher priority. Ciphers with a higher encryption should in general always be priorized. Older ciphers don't have to be banned, unless they are considered insecure (because of outdated/depricated) or flawed.
I did some online testing with a online smtp ssl checker: it showed PFS were not supported, but after enabling mercurys session logging I've seen that:
are often negotiated for encrypted communication. These are PFS ciphers. So the online testing doesn't seem to be reliable.
The person of the Data Protection Authority we are in contact with is an IT-Professional. I've heard from him that he had already contact with other mail server developers to help them out with all these issues. I've heard also that they have their own software for testing purposes. My suggestion: I will get in touch with him, show him this thread and ask him to get in direct contact with you. I think that would make more sense.
Just wanted to say thank you for adding SSL support to the MercuryE (Client SMTP) module. Since Gmail started displaying the notification about non-encrypted mail I was really happy to see version 4.80 added that feature, and made it simple to start encrypting. Keep up the good work.
P.S. I tried to send this by your contact form at: http://community.pmail.com/pmail/Feedback.aspx but it kept saying "Wrong code" despite me being pretty sure I was typing in the correct codes. I tried like 5 times, and the codes are pretty clear, so it seems like that form is broken.
On startup after the from v4.74 to v4.80 MercuryI failed to load throwing a "No such file or directory" error. I tracked the problem down to the path to the certificate in the MercuryI section of mercury.ini file. The previous certificate was named "imapcert" which v4.80 obviously did not like. I run in a second Mercury instance in which I run MercuryS so I copied its newly created certificate, then modified the path in the .ini. My suggestion is to consider whether it would be feasible to allow access to the module GUI after encountering an error like "No such file or directory".
One other suggestion is to provide the ability to create a certificate from outside of the modules so as not to be dependent on a module starting up in order to create a certificate.
Thanks for providing this Nenad. I've had a few instances of dubious messages coming through recently which this should help with. I haven't had experience with Policy Tasks but through some investigation, it looks like you need to escape the double quotes you added around the ~F argument.
I am testing version 4.74 and found that e-mails read from one client with the option "leave a copy of the messages in the server" active could not be read by anyone else because the option "offer..." overlaps the option "leave..." and Mercury serves the message only once.
The option should be off by default or, even better, be removed from options available.
Edited: should be in Mercury Suggestions... Sorry.
I was wondering if v5 and the new mailstore engine will support this. At the moment the "Expunge" command fails with "folder in use by other connection" if there is more than one active IMAP connection for that folder. Since we all use mobile phones, tablets... (especially with the crappy iPhone/iPad which does never close mail connections until you shut down the device), this functionality is mandatory in my opinion.
[quote user="jessicarabbit"]The ClamAV world seems in flux. ClamAV now seems to be Immunet.[/quote]
ClamAV is still ClamAV and they produce a Windows version of the product available . Immunet was a separate company who developed a 'cloud-based' Windows anti-virus product with ClamAV. The Immunet version is not suitable for use with Mercury.
[quote]In an effort to get ClamWall running, I ended up downloading ClamWin and pointed ClamWall to the bin directory. The Question then became "Is it working". I have not figured out how to tell.[/quote]
ClamWin from www.clamwin.com is a different product that does not contain the clamD module that Mercury needs.
[quote]One of the things I love about Mercury is what I call "Visibility". It is reasonably easy to tell what it is doing or not doing. Please extend this concept for what ever resource we are using to do anti-virus checking and display some form of verification, status, log entry, etc. that the virus checker is alive and processing the mail. This goes for the other add-ons as well.[/quote]
One thing you can do is examine the ClamWall log file regularly and look for error lines. There may be tools out there to automate that task as well.
Because logging in from Mercury/32 to NDS is not possible, this forum gives the advice to login to NDS prior to starting Mercury/32 with an account reduced to minimum necessary rights. Created such an account in first step with security equivalence to admin-account. Now started reducing the rights for that account. Ran in a little problem:
Due to policies set with NCONFIG all users get right to create mailfiles in all other users new mail directory. Obviously Mercury/32 needs more rights. If a mail arrives for a local user, it is placed in queuedirectory of Mercury as file of type QDF. Than the coremodul copies this file to new mail directory in users homedirectory (CREATE) and than tries to rename it to type CNM for Pegasus to recognize it. Therefore the right CREATE isn't enough ... the reduced account needs MODIFY (which amongst others includes renaming) too. But that may be a securityrisk (and I will have to change rights of every of my hundreds accounts by hand and do that with every new account).
So it would be nice if Mercury/32 copies the QDF as CNM to the new mail directory instead of copying QDF and renaming it to CNM afterwards!