You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alex <my...@gmail.com> on 2014/08/27 23:07:34 UTC
Spam info headers
Hi all,
I'm using spamassassin-3.4 with amavisd-2.9.1. I think there's a chance
this is more of an amavisd question, but I think it's related enough to
post here.
I've set up a local URI DNSBL and I believe there are some FPs that I'd
like to identify. I've currently set up amavisd to set $sa_tag_level_deflt
at a value low enough that it always produces the X-Spam-Status header on
every email.
It will show "LOC_URIBL=1" in the status, but is it possible to have it
somehow report/show the domain that caused the rule to fire, in the same
way that it can be done with spamassassin directly on the command-line
using -t?
Thanks,
Alex
Re: Spam info headers
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2014-08-29 at 00:30 -0400, Alex wrote:
> Regarding report_safe, the docs say it can only be applied to spam. Is
> that correct?
Yes, it only applies to spam. It defines whether classified spam will be
attached to a newly generated reporting message, or only modified by
adding some X-Spam headers.
Ham will never get wrapped in another message by SA...
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spam info headers
Posted by Alex <my...@gmail.com>.
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
Re: Spam info headers
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2014-08-27 at 21:37 -0400, Alex wrote:
> On Wed, Aug 27, 2014 at 6:18 PM, Karsten Bräckelmann <gu...@rudersport.de> wrote:
> > The URIs [1] are automatically added to the uridnsbl rule's description
> > for _REPORT_ and _SUMMARY_ template tags. The latter is identical to the
> > additional summary at the end with the -t option, the first one is
> > suitable for headers.
> >
> > add_header spam Report _REPORT_
> >
> > That Report header is set by default with report_safe 0 (stock SA, not
> > Amavis).
>
> I now recall having added a few custom headers in the past, and it was
> indeed necessary to instruct amavis to display them. I did a little
> more digging around, and learned how I was doing it previously was
> replaced with the following, in amavisd.conf:
>
> $allowed_added_header_fields{lc('X-Spam-Report')} = 1;
>
> So I've modified my local.cf with the following:
>
> report_safe 0
> clear_report_template
That's actually a historic, unfortunate naming.
Despite it's name, the report option (see 10_default_prefs.cf) sets the
template used with report_safe 1 or 2, which by default shows a brief
description, (attached spam) content preview and _SUMMARY_.
It does not have any impact on the X-Spam-Report header added with
report_safe 0 by default or the _REPORT_ template tag.
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.
> add_header all Report _REPORT_
>
> Despite specifying "all", it's only displayed in quarantined messages.
> I need it to be displayed on non-spam messages, and "all" messages
> would be most desirable.
That'd be an Amavis specific issue. Using add_header all, SA does add
that header to both ham and spam no matter what. In particular,
quarantining is outside the scope of SA, and if that makes a difference
whether a certain header appears or not, that's also outside the scope
of SA.
> There's also this in the SA conf docs:
>
> report ...some text for a report...
> Set the report template which is attached to spam mail
> messages. See the 10_misc.cf configuration file in
> /usr/share/spamassassin for an example.
> 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.
You want to update your docs bookmarks.
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...
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spam info headers
Posted by Alex <my...@gmail.com>.
Hi,
On Wed, Aug 27, 2014 at 6:18 PM, Karsten Bräckelmann <gu...@rudersport.de>
wrote:
>
> On Wed, 2014-08-27 at 17:07 -0400, Alex wrote:
> > I've set up a local URI DNSBL and I believe there are some FPs that
> > I'd like to identify. I've currently set up amavisd to set
> > $sa_tag_level_deflt at a value low enough that it always produces the
> > X-Spam-Status header on every email.
> >
> > It will show "LOC_URIBL=1" in the status, but is it possible to have
> > it somehow report/show the domain that caused the rule to fire, in the
> > same way that it can be done with spamassassin directly on the
> > command-line using -t?
>
> The URIs [1] are automatically added to the uridnsbl rule's description
> for _REPORT_ and _SUMMARY_ template tags. The latter is identical to the
> additional summary at the end with the -t option, the first one is
> suitable for headers.
>
> add_header spam Report _REPORT_
>
> That Report header is set by default with report_safe 0 (stock SA, not
> Amavis).
I now recall having added a few custom headers in the past, and it was
indeed necessary to instruct amavis to display them. I did a little more
digging around, and learned how I was doing it previously was replaced with
the following, in amavisd.conf:
$allowed_added_header_fields{lc('X-Spam-Report')} = 1;
So I've modified my local.cf with the following:
report_safe 0
clear_report_template
add_header all Report _REPORT_
Despite specifying "all", it's only displayed in quarantined messages. I
need it to be displayed on non-spam messages, and "all" messages would be
most desirable.
There's also this in the SA conf docs:
report ...some text for a report...
Set the report template which is attached to spam mail messages.
See the 10_misc.cf configuration file in
/usr/share/spamassassin for an example.
If you change this, try to keep it under 78 columns. Each report
line appends to the existing template,
so use clear_report_template to restart.
Is this still valid? 10_misc.cf apparently no longer exists, so I wasn't
able to follow through there.
Thanks,
Alex
Re: Spam info headers
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2014-08-27 at 17:07 -0400, Alex wrote:
> I've set up a local URI DNSBL and I believe there are some FPs that
> I'd like to identify. I've currently set up amavisd to set
> $sa_tag_level_deflt at a value low enough that it always produces the
> X-Spam-Status header on every email.
>
> It will show "LOC_URIBL=1" in the status, but is it possible to have
> it somehow report/show the domain that caused the rule to fire, in the
> same way that it can be done with spamassassin directly on the
> command-line using -t?
The URIs [1] are automatically added to the uridnsbl rule's description
for _REPORT_ and _SUMMARY_ template tags. The latter is identical to the
additional summary at the end with the -t option, the first one is
suitable for headers.
add_header spam Report _REPORT_
That Report header is set by default with report_safe 0 (stock SA, not
Amavis).
[1] Actually lists a single one only, if multiple URIs are hit. That's a
comment documented TODO item.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spam info headers
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 27.08.14 17:07, Alex wrote:
>I've set up a local URI DNSBL and I believe there are some FPs that I'd
>like to identify. I've currently set up amavisd to set $sa_tag_level_deflt
>at a value low enough that it always produces the X-Spam-Status header on
>every email.
you can work around this by configuring
add_header all Report _REPORT_
so the X-Spam-Report is added to every message, not just spam...
not sure if this works with amavis, It seems that amavis only adds
x-spam-report only when mail is spam, configurable with "tag2 level".
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody