Re: Spam info headers

[Alex]

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 , 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.orig2014-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: no subject tagging in case of "X-Spam-Status: Yes"

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote:
> look at the attached zp-archive [...]

Since I already had a closer look at the contents including your local
cf, and I am here to offer help and didn't mean no harm, some comments
regarding the SA config.


> # resolves a bug with milter always triggering a wrong informational header
> score UNPARSEABLE_RELAY 0

See the RH bug you filed and its upstream report. Do you still need
that? This would be the first instance of continued triggering of that
test I ever encountered.


> # disable most builtin DNSBL/DNSWL to not collide with webinterface settings
> score __RCVD_IN_SORBS 0
> score __RCVD_IN_ZEN 0
> score __RCVD_IN_DNSWL 0

Rules starting with double-underline are non-scoring sub-rules.
Assigning a zero score doesn't disable them like it does with regular
rules. In the case of RBL sub-rules like the above, it does not prevent
DNS queries. It is better to

  meta __FOO 0

overwrite the sub-rule, rather than set a score that doesn't exist.


> # unconditional sender whitelists
> whitelist_from *@apache.org
> whitelist_from *@bipa.co.at
> whitelist_from *@centos.org
> whitelist_from *@dovecot.org
  [...]

Unconditional whitelisting generally is a bad idea and might appear in
forged addresses.

If possible, it is strongly suggested to use whitelist_from_auth, or at
least whitelist_from_rcvd (which requires *_networks be set correctly).


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 02:15 +0200, Reindl Harald wrote:
> look at the attached zp-archive and both messages
> produced with the same content before you pretend
> others lying damned - to make it easier i even
> added a config-diff

But no message diff. ;)

> and now what?
> 
> maybe you should accept that even new users are
> no idiots and know what they are talking about

Please accept my apologies. It appears something else is going on here,
and you in fact did not lie.

I'd like to add, though, that I do *not* assume new users to be idiots.
Plus, I generally spend quite some time on helping others fixing their
problems, including new users, as you certainly have noticed.


Now, moving forward: I've had a look at the message diffs. Quite
interesting, and I honestly want to figure out what's happening.

First of all, minus all those different datetime strings, IDs and
ordering, the real differences are

  -Subject: [SPAM] Test^M
  -X-Spam-Flag: Yes^M

  +Subject: Test^M

So it appears that only the sample with add_header spam Flag has the
Subject re-written.

However, there's something else going on. When re-writing the Subject
header, SA adds an X-Spam-Prev-Subject header with the original. Which
is clearly missing.

Thus, something else has a severe impact on which headers are added or
modified. In *both* cases, there is at least one SA generated header
missing and/or SA modified header not preserved.

Definitely involved: Postfix, spamass-milter, SA. And probably some
other tool rewriting the message / reflowing headers, as per some
previous posts (and the X-Spam-Report header majorly inconvenienced by
re-flowing headers).

Regarding SA and the features in question: There is no different
behavior between calling the plain spamassassin script and using
spamc/d. There is absolutely nothing in SA itself that could explain the
discrepancy in Subject rewriting, nor the missing X-Spam-Prev-Subject
header.

My best bet would be on the SA invoking glue, not accepting or
overwriting headers as received by SA. Which tool that actually is, I
don't know. But I'd be interested to hear about it, if you find out.


(The additional empty line between message headers and body in the case
without X-Spam-Flag header most likely is just copy-n-paste body. Or
possibly another artifact of some tool munging messages.)


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: no subject tagging in case of "X-Spam-Status: Yes"

[David B Funk]

On Fri, 29 Aug 2014, Reindl Harald wrote:



Am 25.08.2014 um 11:37 schrieb Reindl Harald:

header contains "X-Spam-Status: Yes, score=7.5 required=5.0"
but the subject does not get [SPAM] tagging with the config
below - not sure what i am missing

spamassassin-3.4.0-7.fc20.x86_64
spamass-milter-0.3.2-11.fc20.x86_64

spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- -s 
1048576
perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10 
--min-spare=5 --max-spare=15
__

"/var/lib/spamass-milter/spamassassin/user_prefs" is empty
"/etc/mail/spamassassin/local.cf" is configured below


[snip..]

report_safe 0
skip_rbl_checks 1

clear_headers
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_
rewrite_header Subject [SPAM]


besides the permissions problem after the nightly "sa-update" the reason
was simply "clear_headers" without "add_header spam Flag _YESNO" which
is entirely unexpected behavior

why does the software changing the subject based on a decision made
by itself need a header written by itself as base for the next decision
to change the subject?


One thing to keep in mind here, you're using a milter and it does things 
differently than when spamassassin is used as a filter.


With a milter it gets a copy of the incoming message, passes it on to SA,
it gets the results back from SA and then it makes decisions about how to
change the original message which is still in your MTA. So the milter makes
explicit calls into the MTA saying 'add this header' or 'replace  that header
with this other data'. So it's up to your milter to decide what changes it
makes to the resultant message, it could -totally- ignore what SA has done
and produce its own outout.

Bottom line, you need to look at the code of the milter to see what headers
get added/changed in the resulting message output, the SA configs don't have
complete control.

--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: writing own rbl rules

[Reindl Harald]

Am 29.08.2014 um 02:29 schrieb Karsten Bräckelmann:
> On Fri, 2014-08-29 at 01:59 +0200, Reindl Harald wrote:
> You can easily run RBL tests against IPs from within the local network
> and treat them like any other sending SMTP client, by  (a) excluding
> them from the appropriate *_networks settings, and  (b) define the RBL
> test accordingly. If you want to query for the last-external, it has to
> be the last external relay according to the configuration

and the *how* was the only question
*how* to define the rule to not care about last-external





signature.asc
Description: OpenPGP digital signature

Re: writing own rbl rules

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 01:59 +0200, Reindl Harald wrote:
> Am 29.08.2014 um 01:51 schrieb Karsten Bräckelmann:
> > On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote:

> > > the question was just "how can i enforce RBL tests inside the own LAN"
> > 
> > RBL tests cannot be enforced. Internal and trusted networks settings
> > need to be configured correctly to match the RBL test's scope, in your
> > case last-external.
> > 
> > If there are trusted relays found in the Received headers, and the first
> > trusted one's connecting relay is external (not in the internal_networks
> > set), then an RBL test for last-external will be run.
> > 
> > This is entirely unrelated to "own LAN" or "network range"
> 
> that may all be true for blacklists and default RBL rules
> 
> it is no longer true in case of 4 internal WHITELISTS which you
> want to use to LOWER scores to reduce false positives while
> otherwise bayes may hit - such traffic can also come from
> the internal network

There is absolutely no difference between black and whitelists. With the
only, obvious exception of the rule's score.

So, yes, it still is true in the case of (internal) whitelists.


Besides that, you are (still) confusing SA *_networks settings with the
local network topology. They are loosely related, but don't have to
match.

You can easily run RBL tests against IPs from within the local network
and treat them like any other sending SMTP client, by  (a) excluding
them from the appropriate *_networks settings, and  (b) define the RBL
test accordingly. If you want to query for the last-external, it has to
be the last external relay according to the configuration.

BTW, unless the set of IPs to whitelist is permanently changing, it is
much easier to write a negative score rule based on the X-Spam-Relays-*
pseudo-headers. This also has the benefit of being highly flexible, not
depend on trust borders and allow to maintain internal_networks matching
the LAN topology.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Reindl Harald]

Am 29.08.2014 um 02:15 schrieb Reindl Harald:
> Am 29.08.2014 um 02:01 schrieb Karsten Bräckelmann:
>> On Fri, 2014-08-29 at 01:23 +0200, Reindl Harald wrote:
 Besides, your own reply to my first post to this thread on Mon also
 shows this claim to be false. The output of the command I asked you to
 run clearly shows clear_headers in your config being in effect and a
 rewritten Subject
>>>
>>> i verfied that 20 times in my environment
>>>
>>> removing the line "add_header spam Flag _YESNO_" and no tagging
>>> maybe the combination of spamass-milter and SA but it's fact
>>
>> So far I attributed most of your arguing to being stubborn and
>> opinionated. Not any longer.
>>
>> Now you're outright lying
> 
> look at the attached zp-archive and both messages
> produced with the same content before you pretend
> others lying damned - to make it easier i even
> added a config-diff
> 
> * current config with the header
> * frommailer with the SA machine as destination
> * spam content
> * click send
> * fine [SPAM] in the subject
> * remove "add_header spam Flag _YESNO_" from the config
> * reload SA
> * press send again in the webform
> * no [SPAM] in the subject
> 
> and now what?
> 
> maybe you should accept that even new users are
> no idiots and know what they are talking about

and here you have the damend logs even containing the original subject
of postfix's header_checks - so don't call others names before you
have a matching test setup and can *prove* what you claim

Aug 29 02:08:24 mail-gw postfix/smtpd[23354]: connect from 
testserver.rhsoft.net[84.113.92.77]
Aug 29 02:08:24 mail-gw postfix/smtpd[23354]: 3hkh3X2YJNz1w: 
client=testserver.rhsoft.net[84.113.92.77]
Aug 29 02:08:24 mail-gw postfix/cleanup[24041]: 3hkh3X2YJNz1w: info: header 
Subject: Test from
testserver.rhsoft.net[84.113.92.77]; from= 
to= proto=ESMTP
helo=
Aug 29 02:08:24 mail-gw postfix/cleanup[24041]: 3hkh3X2YJNz1w:
message-id=<5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net>
Aug 29 02:08:24 mail-gw spamd[21151]: spamd: processing message
<5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net> for 
sa-milt:189
Aug 29 02:08:25 mail-gw spamd[21151]: spamd: identified spam (5.1/5.0) for 
sa-milt:189 in 1.0 seconds, 4784 bytes.
Aug 29 02:08:25 mail-gw spamd[21151]: spamd: result: Y 5 -
ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,CUST_DNSBL_2,CUST_DNSBL_5,CUST_DNSWL_7,DEAR_SOMETHING,LOTS_OF_MONEY,RP_MATCHES_RCVD,T_MONEY_PERCENT,URG_BIZ
scantime=1.0,size=4784,user=sa-milt,uid=189,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=32286,mid=<5d0902b99004e92eccfc834833cfbdf9a2e51f251409270...@testserver.rhsoft.net>,bayes=1.00,autolearn=disabled
Aug 29 02:08:25 mail-gw postfix/qmgr[22472]: 3hkh3X2YJNz1w: 
from=, size=4597,
nrcpt=1 (queue active)
Aug 29 02:08:25 mail-gw postfix/smtpd[23354]: disconnect from 
testserver.rhsoft.net[84.113.92.77]
Aug 29 02:08:25 mail-gw postfix/smtp[23363]: 3hkh3X2YJNz1w: 
to=,
relay=mail.thelounge.net[10.0.0.15]:10027, delay=1.2, delays=1.1/0/0.04/0.02, 
dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as 3hkh3Y3RF0z23)
Aug 29 02:08:25 mail-gw postfix/qmgr[22472]: 3hkh3X2YJNz1w: removed
Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max connection rate 
1/1800s for (smtpd:168.100.1.4) at
Aug 29 01:58:38
Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max connection count 
1 for (smtpd:168.100.1.4) at Aug 29
01:58:38
Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max recipient rate 
1/1800s for (smtpd:168.100.1.4) at Aug
29 01:58:38
Aug 29 02:08:38 mail-gw postfix/anvil[23356]: statistics: max cache size 3 at 
Aug 29 02:08:24
Aug 29 02:09:40 mail-gw spamd[21068]: spamd: server hit by SIGHUP, restarting
Aug 29 02:09:40 mail-gw spamd[21068]: spamd: server socket closed, type 
IO::Socket::IP
Aug 29 02:09:42 mail-gw spamd[21068]: spamd: server started on IO::Socket::IP 
[127.0.0.1]:10027 (running version 3.4.0)
Aug 29 02:09:42 mail-gw spamd[21068]: spamd: server pid: 21068
Aug 29 02:09:44 mail-gw postfix/postscreen[22610]: CONNECT from 
[84.113.92.77]:64250 to [10.0.0.19]:25
Aug 29 02:09:44 mail-gw postfix/postscreen[22610]: PASS OLD [84.113.92.77]:64250
Aug 29 02:09:44 mail-gw postfix/smtpd[23354]: connect from 
testserver.rhsoft.net[84.113.92.77]
Aug 29 02:09:44 mail-gw postfix/smtpd[23354]: 3hkh540hvnz1w: 
client=testserver.rhsoft.net[84.113.92.77]
Aug 29 02:09:44 mail-gw postfix/cleanup[24086]: 3hkh540hvnz1w: info: header 
Subject: Test from
testserver.rhsoft.net[84.113.92.77]; from= 
to= proto=ESMTP
helo=
Aug 29 02:09:44 mail-gw postfix/cleanup[24086]: 3hkh540hvnz1w:
message-id=
Aug 29 02:09:44 mail-gw spamd[24069]: spamd: processing message
 for 
sa-milt:189
Aug 29 02:09:44 mail-gw spamd[24069]: spamd: identified spam (5.1/5.0) for 
sa-milt:189 in 0.3 seconds, 4784 bytes.
Aug 29 02:09:44 mail-gw spamd[24069]: spamd: result: Y 5 -
ADVANCE_FEE_4_NEW,ADVANCE_F

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 01:23 +0200, Reindl Harald wrote:
> Am 29.08.2014 um 01:20 schrieb Karsten Bräckelmann:
> > On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote:
> > > besides the permissions problem after the nightly "sa-update" the reason
> > > was simply "clear_headers" without "add_header spam Flag _YESNO" which
> > > is entirely unexpected behavior
> > 
> > No, that is not the cause.
> > 
> > $ echo -e "Subject: Foo\n" | ./spamassassin | grep Subject
> > Subject: [SPAM] Foo
> > X-Spam-Prev-Subject: Foo
> > 
> > $ cat rules/99_DEVEL.cf
> > required_score -999# regardless of score, classify spam
> ># to enforce header rewriting
> > clear_headers
> > rewrite_header Subject [SPAM]
> > 
> > Besides, your own reply to my first post to this thread on Mon also
> > shows this claim to be false. The output of the command I asked you to
> > run clearly shows clear_headers in your config being in effect and a
> > rewritten Subject
> 
> i verfied that 20 times in my environment
> 
> removing the line "add_header spam Flag _YESNO_" and no tagging
> maybe the combination of spamass-milter and SA but it's fact

So far I attributed most of your arguing to being stubborn and
opinionated. Not any longer.

Now you're outright lying.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: writing own rbl rules

[Reindl Harald]

Am 29.08.2014 um 01:51 schrieb Karsten Bräckelmann:
> On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote:
>> the question was just "how can i enforce RBL tests inside the own LAN"
> 
>> the question was just "how can i enforce RBL tests inside the own LAN"
> 
>> the question was just "how can i enforce RBL tests inside the own LAN"
> 
> RBL tests cannot be enforced. Internal and trusted networks settings
> need to be configured correctly to match the RBL test's scope, in your
> case last-external.
> 
> If there are trusted relays found in the Received headers, and the first
> trusted one's connecting relay is external (not in the internal_networks
> set), then an RBL test for last-external will be run.
> 
> This is entirely unrelated to "own LAN" or "network range"

that may all be true for blacklists and default RBL rules

it is no longer true in case of 4 internal WHITELISTS which you
want to use to LOWER scores to reduce false positives while
otherwise bayes may hit - such traffic can also come from
the internal network

in case of having postscreen and scoring in front of SA it
is even a valid usecase to *completly* skip SA's using of
blacklists and have 4 different DNSWL in the internal
network with different trust-levels and hence different
negative scores

frankly it is somehow pervert that you can send a specific
mailbody from outside and get a DNSWL negative score
leading to accpet the message correctly and send the
exactly same message from the own LAN and get it
rejected by bayse filters

that's also a lot of more trustable then sender whitelisting






signature.asc
Description: OpenPGP digital signature

Re: writing own rbl rules

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote:
> the question was just "how can i enforce RBL tests inside the own LAN"

> the question was just "how can i enforce RBL tests inside the own LAN"

> the question was just "how can i enforce RBL tests inside the own LAN"

RBL tests cannot be enforced. Internal and trusted networks settings
need to be configured correctly to match the RBL test's scope, in your
case last-external.

If there are trusted relays found in the Received headers, and the first
trusted one's connecting relay is external (not in the internal_networks
set), then an RBL test for last-external will be run.

This is entirely unrelated to "own LAN" or "network range".


> >>> Received headers before that simply CANNOT be trusted. There is no way
> >>> to guarantee the host they claim to have received the message from is
> >>> legit
> >>
> >> in case running postfix with SA as milter *there are no* Received
> >> headers *before* because there is nobody before
> > 
> > There almost always is at least one Received header before, the sender's
> > outgoing SMTP server
> 
> *no no no and no again*
> 
> there is no Received header before because a botnet zombie don't use
> a outgoing SMTP server

I said "almost always", with direct-to-MX delivery being the obvious
exception. Possible with botnet spam, yes, but too easy to detect. Thus,
botnet zombies frequently forge Received headers.

(Besides, in your environment SA won't see much botnet spam anyway.
Spamhaus PBL as first level of defense in your Postfix configuration
will reject most of them. But that's not the point here.)


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Certain types of spam seem to get through SA

[Martin Gregorie]

On Thu, 2014-08-28 at 17:42 -0500, Robert A. Ober wrote:
> If you find a solution without my having to write more rules I would 
> appreciate you letting the list know.
> 
This may not be what you want to know, but.

Some time back I was subscribed to a mailing list that was linked to a
web forum which attracted a lot of spam and whose owners were adverse to
any form of spam filtering apart from banning spammers after the fact.
Since I wanted to see the hammy list material I couldn't easily filter
on headers and so was forced to develop another way to separate spam
from ham. My prime weapon was a sales  blurb detector. This is basically
two rules that recognise product names and selling phrases combined by a
meta-rule that requires both rules to fire before it generates a hit.
The two base rules are both vast lists of alternate patterns. The
benefit of going this way is that now, quite a long time later, this
rule is still surprisingly effective in tagging UCE as spam. Better yet,
the lists now require quite infrequent updating, probably because there
is a limit to the types of product that get offered via UCE and an even
more limited set of phrases that are used to push it.

The drawbacks of this approach are twofold:
1) it takes a while for the rules to become big enough to be really
   effective
2) editing a large alternate list is really hard, largely because the
   regex is restricted to a single line. 

There's no easy fix for (1), but I did build a solution for (2) - an
awk-based script that converts a set of easily-edited rule definition
files into a .cf file containing a number of SA rules, each built from a
rule definition file. If this tool looks interesting to you, you can
find it here:

http://www.libelle-systems.com/free/portmanteau/portmanteau.tgz

This file is a compressed source archive that includes documentation for
the tool and the definition file format.


Martin

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Reindl Harald]

Am 29.08.2014 um 01:20 schrieb Karsten Bräckelmann:
> On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote:
>> besides the permissions problem after the nightly "sa-update" the reason
>> was simply "clear_headers" without "add_header spam Flag _YESNO" which
>> is entirely unexpected behavior
> 
> No, that is not the cause.
> 
> $ echo -e "Subject: Foo\n" | ./spamassassin | grep Subject
> Subject: [SPAM] Foo
> X-Spam-Prev-Subject: Foo
> 
> $ cat rules/99_DEVEL.cf
> required_score -999# regardless of score, classify spam
># to enforce header rewriting
> clear_headers
> rewrite_header Subject [SPAM]
> 
> Besides, your own reply to my first post to this thread on Mon also
> shows this claim to be false. The output of the command I asked you to
> run clearly shows clear_headers in your config being in effect and a
> rewritten Subject

i verfied that 20 times in my environment

removing the line "add_header spam Flag _YESNO_" and no tagging
maybe the combination of spamass-milter and SA but it's fact



signature.asc
Description: OpenPGP digital signature

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 00:30 +0200, Reindl Harald wrote:
> besides the permissions problem after the nightly "sa-update" the reason
> was simply "clear_headers" without "add_header spam Flag _YESNO" which
> is entirely unexpected behavior

No, that is not the cause.

$ echo -e "Subject: Foo\n" | ./spamassassin | grep Subject
Subject: [SPAM] Foo
X-Spam-Prev-Subject: Foo

$ cat rules/99_DEVEL.cf
required_score -999# regardless of score, classify spam
   # to enforce header rewriting
clear_headers
rewrite_header Subject [SPAM]


Besides, your own reply to my first post to this thread on Mon also
shows this claim to be false. The output of the command I asked you to
run clearly shows clear_headers in your config being in effect and a
rewritten Subject.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: writing own rbl rules

[Reindl Harald]

Am 29.08.2014 um 00:57 schrieb Karsten Bräckelmann:
>> the simple answer to my question would have been "no, in no case SA does
>> any RBL check if the client is from the same network range and there is
>> no way to change that temporary even for development" [...]
>
> That would have been simpler indeed, but that also would have been wrong

no, it would have been correct for the statet environment instead
"if you don't follow CLI debugging good luck" while CLI debugging
did not make any sense in the context

>> if there is no hop before and hence no received headers before
>> there is still a known IP - the one and only and in that case
>> the currently connection client - there is no reason not fire
>> a DNSBL/DNSWL against that IP
> 
> SA is not the SMTP server, it has no knowledge of the connection's
> remote IP. SA depends on the Received headers added by the internal
> network's SMTP server (or its milter) to get that information.

and that is the IP of the physical connecting client

the question was just "how can i enforce RBL tests inside the own LAN"

>>> Besides: SA is not an SMTP. It does not add the Received header. And it
>>> absolutely has to inspect headers, whether you like that or not. That is
>>> how SA determines exactly that last, trustworthy, "physical" IP. And for
>>> that, trusted and internal networks need be correct, so by extension
>>> external networks also are correct.
>>
>> and the machine SA is running on receiving the message adds that
>> header which is in case of direct testing the one and only and
>> so trustable
> 
> Your configuration stated that machine is not trustable.

*because* it did not work as it was trustable as the complete subnet
*after* that i tried to "untrust" the complete own subnet

it still did not work

the question was just "how can i enforce RBL tests inside the own LAN"

>>> In particular, your MX, your first internal relay, absolutely MUST be
>>> trusted by SA. That is the SMTP relay identifying the sending host,
>>> complete with IP and rDNS.
>>
>> again: the machine running SA *is the MX*
> 
> Correct (even though it is irrelevant whether it is or not). So don't
> configure SA to not trust that machine, and include at the very least
> that IP in your trusted_networks.
> 
> Your configuration stated that machine is not trustable.

*after* it did also not work as it was trustable

the question was just "how can i enforce RBL tests inside the own LAN"

>>> Received headers before that simply CANNOT be trusted. There is no way
>>> to guarantee the host they claim to have received the message from is
>>> legit
>>
>> in case running postfix with SA as milter *there are no* Received
>> headers *before* because there is nobody before
> 
> There almost always is at least one Received header before, the sender's
> outgoing SMTP server

*no no no and no again*

there is no Received header before because a botnet zombie don't use
a outgoing SMTP server



signature.asc
Description: OpenPGP digital signature

Re: writing own rbl rules

[Karsten Bräckelmann]

On Fri, 2014-08-29 at 00:22 +0200, Reindl Harald wrote:
> the simple answer to my question would have been "no, in no case SA does
> any RBL check if the client is from the same network range and there is
> no way to change that temporary even for development" [...]

That would have been simpler indeed, but that also would have been
wrong.


> if there is no hop before and hence no received headers before
> there is still a known IP - the one and only and in that case
> the currently connection client - there is no reason not fire
> a DNSBL/DNSWL against that IP

SA is not the SMTP server, it has no knowledge of the connection's
remote IP. SA depends on the Received headers added by the internal
network's SMTP server (or its milter) to get that information.


> > Besides: SA is not an SMTP. It does not add the Received header. And it
> > absolutely has to inspect headers, whether you like that or not. That is
> > how SA determines exactly that last, trustworthy, "physical" IP. And for
> > that, trusted and internal networks need be correct, so by extension
> > external networks also are correct.
> 
> and the machine SA is running on receiving the message adds that
> header which is in case of direct testing the one and only and
> so trustable

Your configuration stated that machine is not trustable.

> > In particular, your MX, your first internal relay, absolutely MUST be
> > trusted by SA. That is the SMTP relay identifying the sending host,
> > complete with IP and rDNS.
> 
> again: the machine running SA *is the MX*

Correct (even though it is irrelevant whether it is or not). So don't
configure SA to not trust that machine, and include at the very least
that IP in your trusted_networks.

Your configuration stated that machine is not trustable.


> > Received headers before that simply CANNOT be trusted. There is no way
> > to guarantee the host they claim to have received the message from is
> > legit
> 
> in case running postfix with SA as milter *there are no* Received
> headers *before* because there is nobody before

There almost always is at least one Received header before, the sender's
outgoing SMTP server.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Certain types of spam seem to get through SA

[Robert A. Ober]

On 8/28/14, 3:17 PM, LuKreme wrote:

On Aug 28, 2014, at 12:00, Martin Gregorie  wrote:

The only obvious oddity, compared with my local main stream is its
direct one-hop delivery. I'd regard this as UCE rather than spam per se.
I only take measures against this type of mail if I see it more
frequently than every 6 months or so and/or if it has an 'unsubscribe'
facility which fails to work.

I get a lot of these, and they are in no way anything that was signed up for. It looks 
like your scores are mostly from hitting "known bad URL" recipes, Which were 
not hit when it arrived. I can try rerunning it.

__

I am getting a lot of this also, along with other easily recognizable junk.

If you find a solution without my having to write more rules I would 
appreciate you letting the list know.


Y'all be cool,
Robert A. Ober

Re: Reporting to SpamCop

[Chris]

On Thu, 2014-08-28 at 23:49 +0200, Karsten Bräckelmann wrote:
> On Thu, 2014-08-28 at 16:14 -0500, Chris wrote:
> > I'm having an issue with getting SA 3.4.0 when run as spamassassin -D -r
> > to report spam to SpamCop. The errors I'm seeing are:
> 
> Ignoring the Perl warnings for now.
> 
> > In my v310.pre file I have:
> > 
> > loadplugin Mail::SpamAssassin::Plugin::SpamCop 
> > /usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm
> 
> It should never be necessary to provide the (optional) filename argument
> with stock SA plugins. Even worse, absolute paths will eventually be
> harmful.
> 
> > I have set the SpamCop from and to addresses in the SpamCop.pm file:
> 
> The Perl modules are no user-serviceable parts. Do not edit them.
> 
> Moreover, the SpamCop plugin provides the spamcop_(from|to)_address
> options to set these in your configuration. See
> 
>   http://spamassassin.apache.org/doc/Mail_SpamAssassin_Plugin_SpamCop.html
> 
> > setting => 'cpoll...@example.com',
> > setting => 'submit.exam...@spam.spamcop.net',
> 
> Wait... What exactly did you edit?
> 
> The only instances of 'setting' in SpamCop.pm are the ones used to
> register SA options. Did you replace the string spamcop_from_address
> with your email address?
> 
> I have a gut feeling the Perl warnings will disappear, if you revert any
> modifications to the SpamCop.pm Perl module and set the options in your
> configuration instead...
> 
> 

That was the fix Karsten, thanks very much.

Chris

-- 
Chris
31.11°N 97.89°W (Elev. 1092 ft)
17:31:15 up 1 day, 1:13, 4 users, load average: 0.18, 0.36, 0.31
Ubuntu 14.04 LTS, kernel 3.13.0-35-generic

Re: no subject tagging in case of "X-Spam-Status: Yes"

[Reindl Harald]

Am 25.08.2014 um 11:37 schrieb Reindl Harald:
> header contains "X-Spam-Status: Yes, score=7.5 required=5.0"
> but the subject does not get [SPAM] tagging with the config
> below - not sure what i am missing
> 
> spamassassin-3.4.0-7.fc20.x86_64
> spamass-milter-0.3.2-11.fc20.x86_64
> 
> spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8 -- 
> -s 1048576
> perl -T -w /usr/bin/spamd -c -H --max-children=25 --min-children=10 
> --min-spare=5 --max-spare=15
> __
> 
> "/var/lib/spamass-milter/spamassassin/user_prefs" is empty
> "/etc/mail/spamassassin/local.cf" is configured below
> 
> use_bayes 1
> bayes_use_hapaxes 1
> bayes_expiry_max_db_size 30
> bayes_auto_expire 1
> bayes_auto_learn 0
> bayes_learn_during_report 0
> report_safe 0
> skip_rbl_checks 1
> 
> clear_headers
> add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_
> rewrite_header Subject [SPAM]

besides the permissions problem after the nightly "sa-update" the reason
was simply "clear_headers" without "add_header spam Flag _YESNO" which
is entirely unexpected behavior

why does the software changing the subject based on a decision made
by itself need a header written by itself as base for the next decision
to change the subject?



signature.asc
Description: OpenPGP digital signature

Re: writing own rbl rules

[Reindl Harald]

besides that the setup is now in production

Am 27.08.2014 um 03:48 schrieb Karsten Bräckelmann:
> Again: Craft your samples to match real-life (production) environment.
> Do not configure or try to fake an environment that will not match
> production later. It won't work.
> 
> You want to configure SA. So configure SA. Correctly.

finally yes, not at development and testing

that is what testing is for:

* no access from outside
* try to set trust on single IP's lacking different ranges

> If you insist on not following that advice, please refrain from further
> postings to this list.

the simple answer to my question would have been "no, in no case SA does
any RBL check if the client is from the same network range and there is
no way to change that temporary even for development" instead start
debug sessions with CLI tools while i already statet that i found
out the RBL's are check if the connection comes from a foreign network

that behavior still is a bug, not in production but it is a bug

if there is no hop before and hence no received headers before
there is still a known IP - the one and only and in that case
the currently connection client - there is no reason not fire
a DNSBL/DNSWL against that IP

>> the intention to berak it was to behave like it is external
>> and just check the RBL behavior
> 
> Read my previous post again, carefully. If you define everything to be
> external, there is no *last* external SA can trust.

if there is only *one* received header it's from the MTA
on which SA is running

>> well, there will never be internal relays, just a inbound-only MX
> 
> That IS an internal relay. Your MX must be in your internal_networks,
> and it is by the very definition of MX an SMTP relay.

the machine SA is running on *is the MX itself*

> Besides: SA is not an SMTP. It does not add the Received header. And it
> absolutely has to inspect headers, whether you like that or not. That is
> how SA determines exactly that last, trustworthy, "physical" IP. And for
> that, trusted and internal networks need be correct, so by extension
> external networks also are correct.

and the machine SA is running on receiving the message adds that
header which is in case of direct testing the one and only and
so trustable

> In particular, your MX, your first internal relay, absolutely MUST be
> trusted by SA. That is the SMTP relay identifying the sending host,
> complete with IP and rDNS.

again: the machine running SA *is the MX*

> Received headers before that simply CANNOT be trusted. There is no way
> to guarantee the host they claim to have received the message from is
> legit

in case running postfix with SA as milter *there are no* Received
headers *before* because there is nobody before



signature.asc
Description: OpenPGP digital signature

Re: Reporting to SpamCop

[Chris]

On Thu, 2014-08-28 at 23:49 +0200, Karsten Bräckelmann wrote:
> On Thu, 2014-08-28 at 16:14 -0500, Chris wrote:
> > I'm having an issue with getting SA 3.4.0 when run as spamassassin -D -r
> > to report spam to SpamCop. The errors I'm seeing are:
> 
> Ignoring the Perl warnings for now.
> 
> > In my v310.pre file I have:
> > 
> > loadplugin Mail::SpamAssassin::Plugin::SpamCop 
> > /usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm
> 
> It should never be necessary to provide the (optional) filename argument
> with stock SA plugins. Even worse, absolute paths will eventually be
> harmful.
> 
Thanks Karsten, I'll remove the path statement

> > I have set the SpamCop from and to addresses in the SpamCop.pm file:
> 
> The Perl modules are no user-serviceable parts. Do not edit them.
> 
> Moreover, the SpamCop plugin provides the spamcop_(from|to)_address
> options to set these in your configuration. See
> 
>   http://spamassassin.apache.org/doc/Mail_SpamAssassin_Plugin_SpamCop.html
> 
> > setting => 'cpoll...@example.com',
> > setting => 'submit.exam...@spam.spamcop.net',
> 
> Wait... What exactly did you edit?
> 
> The only instances of 'setting' in SpamCop.pm are the ones used to
> register SA options. Did you replace the string spamcop_from_address
> with your email address?

This is what I edited:

=item spamcop_from_address u...@example.com   (default: none)

This address is used during manual reports to SpamCop as the From:
address.  You can use your normal email address.  If this is not set, a
guess will be used as the From: address in SpamCop reports.

=cut

  push (@cmds, {
setting => 'cpoll...@example.com',
default => 'cpoll...@example.com',

=item spamcop_to_address u...@example.com   (default: generic reporting
address)

Your customized SpamCop report submission address.  You need to obtain
this address by registering at C.  If this is
not set, SpamCop reports will go to a generic reporting address for
SpamAssassin users and your reports will probably have less weight in
the SpamCop system.

=cut

  push (@cmds, {
setting => 'submit.exam...@spam.spamcop.net',

I've replaced my registered submit address here with 'example'.
> 
> I have a gut feeling the Perl warnings will disappear, if you revert any
> modifications to the SpamCop.pm Perl module and set the options in your
> configuration instead...
> 
> 
Thanks Karsten, I'll give that a try again by setting in my local.cf
file.


-- 
Chris
31.11°N 97.89°W (Elev. 1092 ft)
16:54:39 up 1 day, 37 min, 4 users, load average: 0.32, 0.19, 0.22
Ubuntu 14.04 LTS, kernel 3.13.0-35-generic

Re: Reporting to SpamCop

[Karsten Bräckelmann]

On Thu, 2014-08-28 at 16:14 -0500, Chris wrote:
> I'm having an issue with getting SA 3.4.0 when run as spamassassin -D -r
> to report spam to SpamCop. The errors I'm seeing are:

Ignoring the Perl warnings for now.

> In my v310.pre file I have:
> 
> loadplugin Mail::SpamAssassin::Plugin::SpamCop 
> /usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm

It should never be necessary to provide the (optional) filename argument
with stock SA plugins. Even worse, absolute paths will eventually be
harmful.

> I have set the SpamCop from and to addresses in the SpamCop.pm file:

The Perl modules are no user-serviceable parts. Do not edit them.

Moreover, the SpamCop plugin provides the spamcop_(from|to)_address
options to set these in your configuration. See

  http://spamassassin.apache.org/doc/Mail_SpamAssassin_Plugin_SpamCop.html

> setting => 'cpoll...@example.com',
> setting => 'submit.exam...@spam.spamcop.net',

Wait... What exactly did you edit?

The only instances of 'setting' in SpamCop.pm are the ones used to
register SA options. Did you replace the string spamcop_from_address
with your email address?

I have a gut feeling the Perl warnings will disappear, if you revert any
modifications to the SpamCop.pm Perl module and set the options in your
configuration instead...


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Reporting to SpamCop

[Chris]

I'm having an issue with getting SA 3.4.0 when run as spamassassin -D -r
to report spam to SpamCop. The errors I'm seeing are:

warn: Use of uninitialized value $v in concatenation (.) or string
at /usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm line
255.

Line 255 of the SpamCop.pm is:

  # compose message
  my $message;
  while (my ($k, $v) = each %head) {
$message .= "$k: $v\n"; <--Line 255
  }
  $message .= "\n" . $body;

warn: Use of uninitialized value $mx in substitution (s///)
at /usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm line
263.

  # send message
  my $failure;
  my $mx = $head{To};
  my $hello = Mail::SpamAssassin::Util::fq_hostname() || $from;
  $mx =~ s/.*\@//; <-Line 263
  $hello =~ s/.*\@//;

In my v310.pre file I have:

loadplugin
Mail::SpamAssassin::Plugin::SpamCop 
/usr/local/share/perl/5.18.2/Mail/SpamAssassin/Plugin/SpamCop.pm

I have set the SpamCop from and to addresses in the SpamCop.pm file:

setting => 'cpoll...@example.com',

setting => 'submit.exam...@spam.spamcop.net',

Yes, I am registered at SpamCop.

AFAICT I have all the necessary modules installed, Net::DNS; Net::SMTP
and so forth.

-- 
Chris
31.11°N 97.89°W (Elev. 1092 ft)
15:54:02 up 23:36, 4 users, load average: 0.43, 0.25, 0.33
Ubuntu 14.04 LTS, kernel 3.13.0-35-generic

Re: formatting of report headers

[Reindl Harald]

Am 28.08.2014 um 22:29 schrieb Karsten Bräckelmann:
> On Thu, 2014-08-28 at 21:43 +0200, Reindl Harald wrote:
>> Am 28.08.2014 um 19:11 schrieb Karsten Bräckelmann:
> 
>>> FWIW, SA even generates the Report header by default with your setting
>>> of report_safe 0. Not in your case, because you chose to clear_headers
>>> and manually define almost identical versions to the default headers.
> 
> More detail, in addition to my other reply.
> 
>> # header configuration
>> fold_headers 1
>> report_safe 0
> 
>  "If this option is set to 0, [...]. In addition, a header named
>   X-Spam-Report will be added to spam."  -- M::SA::Conf docs
> 
>> X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,CUST_DNSBL_2,
>>  
>> CUST_DNSBL_5,CUST_DNSWL_7,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,SPF_SOFTFAIL
>>  autolearn=disabled version=3.4.0
> 
> Not spam, no X-Spam-Report header

now we come together and you know why i use own settings
i want that report unconditionally or switch it off unconditionally

the question was only about the missing linebreaks



signature.asc
Description: OpenPGP digital signature

Re: formatting of report headers

[Reindl Harald]

Am 28.08.2014 um 22:18 schrieb Karsten Bräckelmann:
> On Thu, 2014-08-28 at 21:43 +0200, Reindl Harald wrote:
>> Am 28.08.2014 um 19:11 schrieb Karsten Bräckelmann:
> 
>>> FWIW, SA even generates the Report header by default with your setting
>>> of report_safe 0. Not in your case, because you chose to clear_headers
>>> and manually define almost identical versions to the default headers.
>>
>> no, it don't
> 
> Yes, it does.
> 
> Read my comment again, carefully. And see the docs, option report_safe
> in the section Basic Message Tagging Options.
> 
> http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html

please read my comment careful again instead refer to "in your config"

in my last reply where i said "no, it don't" i removed "clear_headers"
and there was no report and default headers as below
___

with only that header related settings the result is like below
no report included by default - period

as said: if SA includes breaks then it maybe caused by gmime on the
final destination mailserver to lose them

report_safe 0
rewrite_header Subject [SPAM]
___

Auto-Submitted: auto-generated
MIME-Version: 1.0
X-Virus-Scanned: Yes
X-Virus-Status: Clean
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,CUST_DNSBL_2,

CUST_DNSBL_5,CUST_DNSWL_7,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,SPF_SOFTFAIL
autolearn=disabled version=3.4.0
Return-Path: reindl.har...@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



signature.asc
Description: OpenPGP digital signature

Re: formatting of report headers

[Karsten Bräckelmann]

On Thu, 2014-08-28 at 21:43 +0200, Reindl Harald wrote:
> Am 28.08.2014 um 19:11 schrieb Karsten Bräckelmann:

> > FWIW, SA even generates the Report header by default with your setting
> > of report_safe 0. Not in your case, because you chose to clear_headers
> > and manually define almost identical versions to the default headers.

More detail, in addition to my other reply.

> # header configuration
> fold_headers 1
> report_safe 0

 "If this option is set to 0, [...]. In addition, a header named
  X-Spam-Report will be added to spam."  -- M::SA::Conf docs

> X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,CUST_DNSBL_2,
>   
> CUST_DNSBL_5,CUST_DNSWL_7,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,SPF_SOFTFAIL
>   autolearn=disabled version=3.4.0

Not spam, no X-Spam-Report header.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: formatting of report headers

[Karsten Bräckelmann]

On Thu, 2014-08-28 at 21:43 +0200, Reindl Harald wrote:
> Am 28.08.2014 um 19:11 schrieb Karsten Bräckelmann:

> > FWIW, SA even generates the Report header by default with your setting
> > of report_safe 0. Not in your case, because you chose to clear_headers
> > and manually define almost identical versions to the default headers.
> 
> no, it don't

Yes, it does.

Read my comment again, carefully. And see the docs, option report_safe
in the section Basic Message Tagging Options.

  http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Certain types of spam seem to get through SA

[LuKreme]

> On Aug 28, 2014, at 12:00, Martin Gregorie  wrote:
> 
> The only obvious oddity, compared with my local main stream is its
> direct one-hop delivery. I'd regard this as UCE rather than spam per se.
> I only take measures against this type of mail if I see it more
> frequently than every 6 months or so and/or if it has an 'unsubscribe'
> facility which fails to work.

I get a lot of these, and they are in no way anything that was signed up for. 
It looks like your scores are mostly from hitting "known bad URL" recipes, 
Which were not hit when it arrived. I can try rerunning it.

Re: formatting of report headers

[Reindl Harald]

Am 28.08.2014 um 19:11 schrieb Karsten Bräckelmann:
> That long _TESTS_ string without line-breaks is due to the very long
> _REPORT_ in that header. If you add a dedicated Report header, the
> Status header and its list of tests will be wrapped appropriately, too.
> 
> FWIW, SA even generates the Report header by default with your setting
> of report_safe 0. Not in your case, because you chose to clear_headers
> and manually define almost identical versions to the default headers.

no, it don't - see below, anyways, i think it's a gimime problem
due reconstruct the message from DBMail

the intention of the override defaults is control that
by a webinterface (on/off) and other operators later
not need a shell login on the machine and touch configs

# header configuration
fold_headers 1
report_safe 0
rewrite_header Subject [SPAM]

Auto-Submitted: auto-generated
MIME-Version: 1.0
X-Virus-Scanned: Yes
X-Virus-Status: Clean
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,CUST_DNSBL_2,

CUST_DNSBL_5,CUST_DNSWL_7,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,SPF_SOFTFAIL
autolearn=disabled version=3.4.0
Return-Path: reindl.har...@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



signature.asc
Description: OpenPGP digital signature

Re: Certain types of spam seem to get through SA

[Martin Gregorie]

On Thu, 2014-08-28 at 09:31 -0600, LuKreme wrote:
> On 28 Aug 2014, at 09:21 , Antony Stone 
>  wrote:
> > Please post pastebin samples of the actual email content (as well as 
> > minimally-anonymised headers) so that others can check on known-working 
> > configurations.
> 
> The only thing I changed was the mail address it was sent to.
> 
> 
> 
Here are the hits I get:

X-Spam-Status: Yes, score=8.6 required=6.0 tests=MG_WRONG_DOMAIN,
RCVD_IN_BRBL_LASTEXT,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK,URIBL_DBL_SPAM,
URI_OPTOUT_USME autolearn=no autolearn_force=no version=3.4.0


The only local rule is MG_WRONG_DOMAIN, which adds 0.01 to the score
because its only used as part of local meta-rules.

The only obvious oddity, compared with my local main stream is its
direct one-hop delivery. I'd regard this as UCE rather than spam per se.
I only take measures against this type of mail if I see it more
frequently than every 6 months or so and/or if it has an 'unsubscribe'
facility which fails to work.


Martin





Martin

Re: Certain types of spam seem to get through SA

[Karsten Bräckelmann]

On Thu, 2014-08-28 at 09:15 -0600, LuKreme wrote:
> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.covisp.net
> X-Spam-Level: *
> X-Spam-Status: No, score=1.7 required=5.0 tests=URIBL_BLACK autolearn=no
>   version=3.3.2

> X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS
>   autolearn=ham version=3.3.2

Bayes and auto-learning are enabled, yet there are no BAYES_XX rules hit
in either sample. Something seems broken.

(Not a first time poster, so I just assume the Bayes DB isn't fresh.)


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: formatting of report headers

[Karsten Bräckelmann]

On Thu, 2014-08-28 at 11:08 +0200, Reindl Harald wrote:
> is it somehow possible to get line-breaks in the
> report headers to have them better readable?

SA inserts line-breaks by default, to keep headers below 80 chars wide.


> report_safe 0
> clear_headers
> add_header spam Flag _YESNO_
> add_header all Status _YESNO_, score=_SCORE_/_REQD_, tests=_TESTS_, 
> report=_REPORT_

> on the shell it looks like this

What you get in the shell is precisely what SA returns -- to the shell
or any other calling process. Any reformatting or re-flow of multiline
headers has been done by other tools.


> X-Spam-Status: No, score=4.3/5.0,
> tests=ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,ALL_TRUSTED,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,T_MONEY_PERCENT,URG_BIZ,
> report=
> * -2.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
> *  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
> *  [score: 1.]

That long _TESTS_ string without line-breaks is due to the very long
_REPORT_ in that header. If you add a dedicated Report header, the
Status header and its list of tests will be wrapped appropriately, too.

FWIW, SA even generates the Report header by default with your setting
of report_safe 0. Not in your case, because you chose to clear_headers
and manually define almost identical versions to the default headers.


-- 
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>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Bayes Problem

[Jeff Mincy]

   From: Julian Brown 
   Date: Thu, 28 Aug 2014 10:46:55 -0500
   
   I work for a company that has lots of mail users.  We use Exim with
   Spamassassin.   My job is to track down this problem.
   
   We are getting complaints of too much spam and have tracked it down, using
   Google, to our bayes files not working correctly.  I do not know if they
   are poisoned or just not working.
   
   When bad spam gets through it is always the same, BAYES_00 -1.9 in the
   headers.   According to what I have googled there is only one thing we can
   do and that is to clear the bayes filters and either allow it to start
   again and possibly retrain.   Each individual has their own bayes filters,
   /home/user/.spamassassin/bayes_*.
   
   Exim version 4.82 #2 built 17-Jul-2014 13:21:53
   SpamAssassin Server version 3.3.2
   CentOS 6.5 64bit
   
   But we are getting a lot of it, not all accounts, so I think this means we
   are getting poisoned or something they are doing is rendering the bayes
   filters non functional.
   
   Here is from one of them from a week or 2 ago:
   
   sa-learn --dump magic
   0.000  0476  0  non-token data: nspam
   0.000  0  40270  0  non-token data: nham
...
   
   I don't know the significance of the above readout, but all the discussions
   talk about this.
   
   Julian

You need to learn way more spam messages.   You will get the best results
by learning from essentially all messages, as long as the messages are
learned correctly.   In addition to not having enough spam messages
you probably have learned various spam messages as ham.

-jeff

Bayes Problem

[Julian Brown]

I work for a company that has lots of mail users.  We use Exim with
Spamassassin.   My job is to track down this problem.

We are getting complaints of too much spam and have tracked it down, using
Google, to our bayes files not working correctly.  I do not know if they
are poisoned or just not working.

When bad spam gets through it is always the same, BAYES_00 -1.9 in the
headers.   According to what I have googled there is only one thing we can
do and that is to clear the bayes filters and either allow it to start
again and possibly retrain.   Each individual has their own bayes filters,
/home/user/.spamassassin/bayes_*.

Exim version 4.82 #2 built 17-Jul-2014 13:21:53
SpamAssassin Server version 3.3.2
CentOS 6.5 64bit

But we are getting a lot of it, not all accounts, so I think this means we
are getting poisoned or something they are doing is rendering the bayes
filters non functional.

Here is from one of them from a week or 2 ago:

sa-learn --dump magic
0.000  0  3  0  non-token data: bayes db version
0.000  0476  0  non-token data: nspam
0.000  0  40270  0  non-token data: nham
0.000  0 178749  0  non-token data: ntokens
0.000  0 1203387778  0  non-token data: oldest atime
0.000  0 1408472415  0  non-token data: newest atime
0.000  0 1409168326  0  non-token data: last journal sync
atime
0.000  0 1408444279  0  non-token data: last expiry atime
0.000  0   22118400  0  non-token data: last expire atime
delta
0.000  0   3617  0  non-token data: last expire
reduction count

I don't know the significance of the above readout, but all the discussions
talk about this.

What I was hoping to do, is there a programmatic way such as with a script,
I could do something to an accounts files and voila know that it is in this
corrupt state?

If so I could automate this clear and possibly retrain.

Thank you

Julian

Re: Certain types of spam seem to get through SA

[LuKreme]

On 28 Aug 2014, at 09:21 , Antony Stone 
 wrote:
> Please post pastebin samples of the actual email content (as well as 
> minimally-anonymised headers) so that others can check on known-working 
> configurations.

The only thing I changed was the mail address it was sent to.



-- 
i wasn't born a programmer. i became one because i was impatient. - Dave
Winer

Re: Certain types of spam seem to get through SA

[Antony Stone]

On Thursday 28 August 2014 at 17:15:43 (EU time), LuKreme wrote:

> I’ve been getting a lot of auto sales, windows install, and pharma spam
> recently that is getting through SA. Here are headers for one from this
> morning:

Please post pastebin samples of the actual email content (as well as 
minimally-anonymised headers) so that others can check on known-working 
configurations.


Thanks,


Antony.

-- 
The first fifty percent of an engineering project takes ninety percent of the 
time, and the remaining fifty percent takes another ninety percent of the time.

   Please reply to the list;
 please *don't* CC me.

Certain types of spam seem to get through SA

[LuKreme]

I’ve been getting a lot of auto sales, windows install, and pharma spam 
recently that is getting through SA. Here are headers for one from this morning:

Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.covisp.net
X-Spam-Level: *
X-Spam-Status: No, score=1.7 required=5.0 tests=URIBL_BLACK autolearn=no
version=3.3.2
X-Spam-Report: 
*  1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
*  [URIs: windowmate-832.us]
X-Original-To: mun...@null.com
Delivered-To: lbut...@covisp.net
Received: from windowmate-832.us (108.168.239.180-static.reverse.softlayer.com 
[108.168.239.180])
by mail.covisp.net (Postfix) with ESMTP id CEE0D50D40B
for ; Thu, 28 Aug 2014 08:48:51 -0600 (MDT)
Date: Thu, 28 Aug 2014 07:45:10 -0700
To: 
Content-Type: text/plain
CMDAuthCode: 10-6414818373-install-75d769e5b2e49dd09bd8c43836b66aaf
From: "Installation Notice" 
Mime-Version: 1.0
Subject: Re: Your Home Depot window installation appt. is coming up...
Message-ID: 

or this one:

Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.covisp.net
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS
autolearn=ham version=3.3.2
X-Spam-Report: 
* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
* -0.0 SPF_PASS SPF: sender matches SPF record
X-Original-To: mun...@null.com
Delivered-To: lbut...@covisp.net
Received: from auto-cover-id66121.us 
(108.168.239.177-static.reverse.softlayer.com [108.168.239.177])
by mail.covisp.net (Postfix) with ESMTP id 926A150D40B
for ; Thu, 28 Aug 2014 08:09:39 -0600 (MDT)
Date: Thu, 28 Aug 2014 07:08:27 -0700
RTS-Auto: 14911343-3244-14507179-97
Content-Type: text/plain
Message-ID: 
Subject: Re: Your Updated Auto-Policy Payment Rate Info: 08/28/14
From: "Auto Insurance Notice" 
Mime-Version: 1.0
To: 


(I am currently updating SA to 3.4 $CURRENT)

-- 
'I'll tell you this!' shouted Rincewind. 'I'd rather trust me than
history! Oh, shit, did I just say that?'

Re: Outlook, we do love to hate you....

[Matus UHLAR - fantomas]

On 27.08.14 18:32, Matteo Dessalvi wrote:

Is anybody else got in trouble due to this 'fantastic'
auto responder feature? Especially when these email
are generated by an Exchange server.

Just curious, since the last week one of our mail
server (for outbound traffic) got listed in one
black list due to this 'out of office'|'vacation'
messages.

I am aware of the RFC3834 but not sure if our
Exchange server is following it.


Of course is does not. Microsoft does not follow standards.
It does violate them, break them, misinterpret them...

--
Matus UHLAR - fantomas, uh...@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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

Re: formatting of report headers (spamassassin)

[Reindl Harald]

Am 28.08.2014 um 16:55 schrieb Matus UHLAR - fantomas:
> On 28.08.14 11:08, Reindl Harald wrote:
>> is it somehow possible to get line-breaks in the
>> report headers to have them better readable?
> 
>> X-Spam-Status: No, score=-101.7/5.0,
>> tests=BAYES_50,CUST_DNSWL_5,HEADER_FROM_DIFFERENT_DOMAINS,USER_IN_WHITELIST
>> , report= * -2.5 CUST_DNSWL_5 RBL: list.dnswl.org (High Trust) *
>> [168.100.1.4 listed in list.dnswl.org] * -100 USER_IN_WHITELIST From:
>> address is in the user's white-list *  0.0 HEADER_FROM_DIFFERENT_DOMAINS
>> From and EnvelopeFrom 2nd level mail *  domains are different *  0.8
>> BAYES_50 BODY: Bayes spam probability is 40 to 60% *  [score: 0.5000]
> 
> it's apparently your MUA that re-formats those headers.
> fix the MUA, complain to authors or get other one

no it is not - see attached stored to local disk with no MUA involved

the MUA is Thunderbird, so if the headers are intented to be formatted
like below and there is no way that any config changes this i forward
that to DBMail and the gmime-reconstruction

hence the DBMail list CC'ed
_

X-Spam-Status: No, score=4.3/5.0,
tests=ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,ALL_TRUSTED,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,T_MONEY_PERCENT,URG_BIZ,
report=
* -2.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
*  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
*  [score: 1.]
*  0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail 
provider
*  (reindl.harald[at]gmail.com)
*  0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
*  CUSTOM_MED
*  0.6 URG_BIZ BODY: Contains urgent matter
*  2.0 DEAR_SOMETHING BODY: Contains 'Dear (something)'
*  0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
*  [score: 1.]
*  0.0 LOTS_OF_MONEY Huge... sums of money
*  0.0 T_MONEY_PERCENT X% of a lot of money for you
*  0.0 ADVANCE_FEE_5_NEW Appears to be advance fee fraud (Nigerian 419)
*  0.0 ADVANCE_FEE_4_NEW Appears to be advance fee fraud (Nigerian 419)
*  0.0 ADVANCE_FEE_4_NEW_MONEY Advance Fee fraud and lots of money
*  0.0 ADVANCE_FEE_5_NEW_MONEY Advance Fee fraud and lots of money
--- Begin Message ---
Test
--- End Message ---


signature.asc
Description: OpenPGP digital signature

Re: formatting of report headers

[Matus UHLAR - fantomas]

On 28.08.14 11:08, Reindl Harald wrote:

is it somehow possible to get line-breaks in the
report headers to have them better readable?



X-Spam-Status: No, score=-101.7/5.0,
tests=BAYES_50,CUST_DNSWL_5,HEADER_FROM_DIFFERENT_DOMAINS,USER_IN_WHITELIST
, report= * -2.5 CUST_DNSWL_5 RBL: list.dnswl.org (High Trust) *
[168.100.1.4 listed in list.dnswl.org] * -100 USER_IN_WHITELIST From:
address is in the user's white-list *  0.0 HEADER_FROM_DIFFERENT_DOMAINS
From and EnvelopeFrom 2nd level mail *  domains are different *  0.8
BAYES_50 BODY: Bayes spam probability is 40 to 60% *  [score: 0.5000]


it's apparently your MUA that re-formats thhose headers.
fix the MUA, complain to authors or get other one.
--
Matus UHLAR - fantomas, uh...@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.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)

Re: A simple rule

[Kevin A. McGrail]

On 8/28/2014 10:05 AM, Axb wrote:

On 08/28/2014 03:45 PM, Rejaine Monteiro wrote:

body MYRULE /deputado|presidente/i


body MYRULE /(?:deputado|presidente)/i

Technically, Alex's rule is faster but not technically different.

The ?: tells the regexp not to store any matches in $1, $2, etc.

But otherwise, the ()'s are implied.

I have to believe you are either A) running against a version of spamd 
that hasn't been restarted to reload the latest rule or B) the text 
appears somehow in the message.


Regards,
KAM

Re: A simple rule

[Axb]

On 08/28/2014 03:45 PM, Rejaine Monteiro wrote:

body MYRULE /deputado|presidente/i


body MYRULE /(?:deputado|presidente)/i

A simple rule

[Rejaine Monteiro]

In this example, I need to catch emails containing the word 'deputado' 
or 'presidente' in the message body. So..


body MYRULE /deputado|presidente/i
score MYRULE5.0

I did a test with a saved email that does _NOT_ contain any of the above 
expressions and he got the message.


spamc -R < sample.eml

pts rule name  description
 -- 
--
 1.0 EXTRA_MPART_TYPE   Header has extraneous Content-type:...type= 
entry

 5.0 MYRULE
 0.0 HTML_MESSAGE   BODY: HTML included in message
 0.0 BAYES_50   BODY: Bayesian spam probability is 40 to 60%
[score: 0.5000]
 2.2 DCC_CHECK  Listed in DCC 
(http://rhyolite.com/anti-spam/dcc/)
 0.1 RDNS_NONE  Delivered to trusted network by a host with 
no rDNS


What i'm doing wrong??

Re: How to report spam to mailspike

[Reindl Harald]

Am 28.08.2014 um 11:11 schrieb Marcin Mirosław:
> I've noticed growing volume of emails listed by mailspike. Usually it's
> spam listed as "good reputation". On his webpage I can see only page
> http://mailspike.org/contact.html , they want to fill many personal
> information, I don't want to send it to them and I don't want to lie

i would say that's one part why they are somehow trustable
because require that personal information makes a little
barrier (you have proven) that any random guy with one
single and maybe careless click can have impact in both
directions (maybe bad - intentionally or unintentionally)



signature.asc
Description: OpenPGP digital signature

How to report spam to mailspike

[Marcin Mirosław]

Hi!
I've noticed growing volume of emails listed by mailspike. Usually it's
spam listed as "good reputation". On his webpage I can see only page
http://mailspike.org/contact.html , they want to fill many personal
information, I don't want to send it to them and I don't want to lie.
abuse@ doesn't work:
: host zimbra.anubisnetworks.com[195.22.26.196]
said: 550
5.1.1 : Recipient address rejected:
mailspike.org (in
reply to RCPT TO command)

Thanks,
Marcin

formatting of report headers

[Reindl Harald]

Hi

is it somehow possible to get line-breaks in the
report headers to have them better readable?

given that "Received" and "DKIM" are coming with
more than one line and the additional ones with
a intention it should be technically possible

report_safe 0
clear_headers
add_header spam Flag _YESNO_
add_header all Status _YESNO_, score=_SCORE_/_REQD_, tests=_TESTS_, 
report=_REPORT_

X-Spam-Status: No, score=-101.7/5.0,
 tests=BAYES_50,CUST_DNSWL_5,HEADER_FROM_DIFFERENT_DOMAINS,USER_IN_WHITELIST
 , report= * -2.5 CUST_DNSWL_5 RBL: list.dnswl.org (High Trust) *
 [168.100.1.4 listed in list.dnswl.org] * -100 USER_IN_WHITELIST From:
 address is in the user's white-list *  0.0 HEADER_FROM_DIFFERENT_DOMAINS
 From and EnvelopeFrom 2nd level mail *  domains are different *  0.8
 BAYES_50 BODY: Bayes spam probability is 40 to 60% *  [score: 0.5000]
___

on the shell it looks like this

X-Spam-Status: No, score=4.3/5.0,
tests=ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,ALL_TRUSTED,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,T_MONEY_PERCENT,URG_BIZ,
report=
* -2.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
*  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
*  [score: 1.]
*  0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail 
provider
*  (reindl.harald[at]gmail.com)
*  0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
*  CUSTOM_MED
*  0.6 URG_BIZ BODY: Contains urgent matter
*  2.0 DEAR_SOMETHING BODY: Contains 'Dear (something)'
*  0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
*  [score: 1.]
*  0.0 LOTS_OF_MONEY Huge... sums of money
*  0.0 T_MONEY_PERCENT X% of a lot of money for you
*  0.0 ADVANCE_FEE_5_NEW Appears to be advance fee fraud (Nigerian 419)
*  0.0 ADVANCE_FEE_4_NEW Appears to be advance fee fraud (Nigerian 419)
*  0.0 ADVANCE_FEE_4_NEW_MONEY Advance Fee fraud and lots of money
*  0.0 ADVANCE_FEE_5_NEW_MONEY Advance Fee fraud and lots of money




signature.asc
Description: OpenPGP digital signature