Hi,
> In the case of report_safe 0, the clear_report_template option actually
> has no effective impact at all. That "report" will just not be added
> anyway.
Thanks for that clarification.
Regarding report_safe, the docs say it can only be applied to spam. Is that
correct?
> That'd be an Amavis specific issue. Using add_header all, SA does add
> that header to both ham and spam no matter what.
Yes, I thought report_safe had the ability to be controlled by add_header.
> > Is this still valid? 10_misc.cf apparently no longer exists, so I
> > wasn't able to follow through there.
>
> Wow. 10_misc.cf last appeared in 3.1.x, and is otherwise identical to
> 10_default_prefs.cf since 3.2. In particular with respect to that very
> doc snippet -- nothing at all changed in that paragraph, except that
> file name.
Yes, this was the first google hit - should have looked at the version more
closely.
> It's times like these I wonder whether I am the only one left grepping
> his way through files and directories, searching for $option. Or
> remembering the ancient magic of a <tab>, when looking for possibly
> matching (numbered!) files...
I had no idea 10_default_prefs would contain the example I was looking for,
so didn't even think to look there. I grepped for a few strings through all
the rules and didn't come up with anything specific enough to investigate
locally. Looking at it now, it's helpful, but 10_misc is nothing like
10_default_prefs so I moved on.
In any case, I figured out what I was trying to do. There's still some
piece I don't understand (and no one on the amavis list could help,
apparently), but I still managed to get it to work, with some modifications
to amavisd.
Amavis strictly controls what is displayed, and even using the new hash, it
doesn't appear to be enough.
Adding the following to amavisd.conf is supposed to enable this header to
be printed in all emails:
$allowed_added_header_fields { lc('X-Spam-Report') } = 1;
It doesn't. Something else is missing. Reading through the source, it wants
to use its own X-Spam-Report, and appears that no matter what, it doesn't
like the SA version. I created my own X-Spam-MyReport header:
add_header all MyReport _REPORT_
and modified the amavisd source directly:
--- amavisd.orig 2014-08-28 23:19:02.175243538 -0400
+++ /usr/sbin/amavisd.xspam 2014-08-28 23:18:14.356174516 -0400
@@ -1237,14 +1237,14 @@
Received DKIM-Signature Authentication-Results VBR-Info
X-Quarantine-ID X-Amavis-Alert X-Amavis-Hold X-Amavis-Modified
X-Amavis-PenPals X-Amavis-OS-Fingerprint X-Amavis-PolicyBank
- X-Spam-Status X-Spam-Level X-Spam-Flag X-Spam-Score
+ X-Spam-Status X-Spam-Level X-Spam-Flag X-Spam-Score X-Spam-MyReport
X-Spam-Report X-Spam-Checker-Version X-Spam-Tests
X-CRM114-Status X-CRM114-CacheID X-CRM114-Notice X-CRM114-Action
X-DSPAM-Result X-DSPAM-Class X-DSPAM-Signature X-DSPAM-Processed
X-DSPAM-Confidence X-DSPAM-Probability X-DSPAM-User X-DSPAM-Factors
X-Bogosity
);
- $allowed_added_header_fields{lc('X-Spam-Report')} = 0;
+ $allowed_added_header_fields{lc('X-Spam-MyReport')} = 1;
$allowed_added_header_fields{lc('X-Spam-Checker-Version')} = 0;
# $allowed_added_header_fields{lc(c(lc $X_HEADER_TAG))}=1;
#later:read_config
There is another hash $prefer_our_added_header_fields that explicitly lists
X-Spam-Report as one amavisd prefers to provide on its own. Creating
MyReport or removing X-Spam-Report from that hash fixes that.
It's 12:30am now, so hopefully this is clear.
Thanks,
Alex
