With Amavisd we don’t have the disclaimer issue even if still body has been modified. Amavisd just added the header about it and not play with body hash.
DKIM accepted this so this mast be just milter implementation in order to proceed with sending message.
: There are some caveats you should be aware of before using MIMEDefang.
: MIMEDefang potentially alters e-mail messages. This breaks a “gentleman’s
: agreement” that mail transfer agents do not modify message bodies. This
: could cause problems, for example, with encrypted or signed messages.
I understand your concern but I think this is correct description because finally we are modifying.
This is old thread and amavisd/milter described but have some sens and a bit of code and config.
Looks like in OpenDKIM should be options to which headers are restricted to sign in and which one not.
It is thought for mailling list because the body is modified to add trailers to messages (eg: instructions on how to get off the list) but we go back to the same conclusion RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
You have mention this before and both agreed don’t sign content at all is not a way exactly from security point of view.
I read today this one also: ( I think you mention this as well )
this has no updates since two years, it is an important step with a database interaction and a web interface to add a specific disclaimer following the email address (probably by doing a regex on the From: field)
We should disable DKIM milter wherever alterMIME is enabled; instead, run opendkim-testmsg in disclaimer-send wrapper wherever both are enabled. It could be done with some logic in /etc/opendkim/SigningTable and disclaimer-send.
I’m experimenting a bug fix and it looks promising: my first test with gmail and another NethServer MTA are successful! @quality_team, @zimny do you want to check it out?
Will do and appreciate your involvement!!!
Like I always said this community should be an example even for commercial products.
But now is almost 11 o’clock in the morning so looks like Zimny is going bed
Promise to test agains google, apple and my uk government subcontractor
Fortunately I’m admin there and our test will not be threatened like a terrorist AlJasira atak
As we got multiple confirmations that the problem is solved the fix is going to be released: in this way – yes – the fix is permanent.
The altermime package comes from RHEL/CentOS repositories. As the alterMIME project is dead since years everything depends on RHEL choices. I expect they’ll go on with it at least for the 7 lifecycle.
Altermime sends SIGSEGV sometimes, and is a dead project. The reason to still work on it for mail2 is providing backward compatibility and a smooth upgrade path. As said by the docs, new implementations shouldn’t use it at all. They should go to a client-based solution instead, which one I don’t know (maybe windows users can centralize the setup with GPOs?).
Let’s ask the @webtop_team: any improvement to disclaimer by your side?