Discussion:
[Mimedefang] remove_redundant_html > delete_header?
Michael Fox
2017-09-22 03:50:38 UTC
Permalink
I’m new to the list so be gentle!

I’m using Postfix with the following milters/filters in this order:
* pre-queue milters:  opendkim, mimedefang  (I plan to add opendmarc after
opendkim)
* post-queue content filter:  amavisd-new (with spamassassin, clamd)

I have an old client that doesn’t understand HTML.  So, I’m using
remove_redundant_html_parts().  And that works great.  But by changing the
message, the DKIM-Signature is no longer going to match.  Since OpenDKIM
runs before MIMEDefang, it is still able to validate the signature.  So far,
so good.

But amavis/spamassassin runs after mimedefang.   So I’m wondering if I
should take further action so that spamassassin doesn’t see a mismatched
signature.
Specifically:
If remove_redundant_html_parts() returns true (it removed HTML parts), then
should I also delete the ‘DKIM-Signature’ header?
And, if I remove the DKIM-Signature header, should I also remove the
“Authentication-Results:” header?
In other words, what’s the best method for keeping all of the players happy?

Any thoughts/wisdom would be helpful.
Thanks,
Michael





_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list ***@lists.roaringpenguin.com
http://lists.r
Joseph Brennan
2017-09-22 13:14:38 UTC
Permalink
You're doing things I don't do, so I can't be specific but as generalizations...

Most of us have Mimedefang run the Spamassassin checks, and so we
don't run the separate Spamassassin daemon.

If you have Mimedefang change the message in any way, you should
remove the DKIM headers.

Since you are checking DKIM with a separate milter, you can configure
Spamassassin not to check it.


Joe Brennan
Columbia University
I’m new to the list so be gentle!
* pre-queue milters: opendkim, mimedefang (I plan to add opendmarc after
opendkim)
* post-queue content filter: amavisd-new (with spamassassin, clamd)
I have an old client that doesn’t understand HTML. So, I’m using
remove_redundant_html_parts(). And that works great. But by changing the
message, the DKIM-Signature is no longer going to match. Since OpenDKIM
runs before MIMEDefang, it is still able to validate the signature. So far,
so good.
But amavis/spamassassin runs after mimedefang. So I’m wondering if I
should take further action so that spamassassin doesn’t see a mismatched
signature.
If remove_redundant_html_parts() returns true (it removed HTML parts), then
should I also delete the ‘DKIM-Signature’ header?
And, if I remove the DKIM-Signature header, should I also remove the
“Authentication-Results:” header?
In other words, what’s the best method for keeping all of the players happy?
Any thoughts/wisdom would be helpful.
Thanks,
Michael
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list ***@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinf
Michael Fox
2017-09-22 16:42:44 UTC
Permalink
Post by Joseph Brennan
If you have Mimedefang change the message in any way, you should
remove the DKIM headers.
OK. Thanks.
Post by Joseph Brennan
Since you are checking DKIM with a separate milter, you can configure
Spamassassin not to check it.
Yeah, I was hoping for a way to not throw away the DKIM check as a contributing factor to the spam score. But it seems the only way to do that would be to run SpamAssassin from MIMEDefang.

Michael




_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list ***@lists.roaringpenguin.com
http://lists.roaringpenguin.

Loading...