You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Tino de Bruijn <he...@tino.io> on 2016/02/14 05:22:36 UTC
Test results differ when input from MTA vs spamc cmdline
Hi,
I have some trouble filtering my spam, as everything I try from the commandline works fine (spamc -t < spam.eml , where spam.eml is a spam message i dragged out of Mail.app and uploaded to the server), but when delivered to SA by my MTA (Haraka), it gets a way too low score (11 vs 3.5 respectively). The spamd.log shows that the online blacklist checks are not run in the last case:
spamc MTA (Haraka)
-------- -----
HTML_MESSAGE HTML_MESSAGE
POOR_DOMAIN POOR_DOMAIN
PYZOR_CHECK PYZOR_CHECK
RP_MATCHES_RCVD RP_MATCHES_RCVD
SPF_HELO_PASS SPF_HELO_PASS
SPF_PASS SPF_PASS
T_REMOTE_IMAGE T_REMOTE_IMAGE
URIBL_BLOCKED URIBL_BLOCKED
RCVD_IN_MSPIKE_H4
RCVD_IN_MSPIKE_WL
RCVD_IN_RP_RNBL
RCVD_IN_SBL_CSS
TVD_RCVD_IP
TVD_RCVD_IP4
URIBL_ABUSE_SURBL
URIBL_DBL_SPAM
My MTA and SA run locally, and I haven’t set anything special for trusted_networks. I think that is picked up allright seeing this in the mails:
X-Spam-Relaysuntrusted: [ ip=91.92.108.188 rdns=thesequestion.top helo=thesequestion.top by=alpha.mydomain.io ident= envfrom=blearedness@thesequestion.top intl=0 id=EC7C2A51-41A1-48A7-BA9A-6CDF35C1916C.1 auth= msa=0 ]
And that ip is also the ip the message was received from.
SA is run like this /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid -x --virtual-config-dir=/etc/spamassassin/ --max-children 1 --username spamd -s /var/log/spamassassin/spamd.log --debug=check pyzor by systemctl, and the logs and headers of the message can be found here: https://gist.github.com/tino/2925d64a018310dc02a8 <https://gist.github.com/tino/2925d64a018310dc02a8>
Any ideas on how to make SA able to run the remote tests from my MTA?
Thanks,
Tino
Re: Test results differ when input from MTA vs spamc cmdline
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.02.2016 um 05:22 schrieb Tino de Bruijn:
> I have some trouble filtering my spam, as everything I try from the
> commandline works fine (spamc -t < spam.eml , where spam.eml is a spam
> message i dragged out of Mail.app and uploaded to the server), but when
> delivered to SA by my MTA (Haraka), it gets a way too low score (11 vs
> 3.5 respectively). The spamd.log shows that the online blacklist checks
> are not run in the last case
https://www.google.com/search?q=URUBL_BLOCKED
horrible that we see that same topic every week again and again - don't
use a radnom DNS server on a inbound MX
setup unbound or whatever DNS server *without* forwarding and configure
/etc/resolv.conf to only use 127.0.0.1 as DNS
Re: Test results differ when input from MTA vs spamc cmdline
Posted by Tino de Bruijn <he...@tino.io>.
> On 15 Feb 2016, at 02:12, John Hardin <jh...@impsec.org> wrote:
>
> On Sun, 14 Feb 2016, RW wrote:
>
>> On Sun, 14 Feb 2016 12:22:36 +0800
>> Tino de Bruijn wrote:
>>
>>> I have some trouble filtering my spam, as everything I try from the
>>> commandline works fine (spamc -t < spam.eml , where spam.eml is a
>>> spam message i dragged out of Mail.app and uploaded to the server),
>>> but when delivered to SA by my MTA (Haraka), it gets a way too low
>>> score (11 vs 3.5 respectively). The spamd.log shows that the online
>>> blacklist checks are not run in the last case:
>>
>> Even without the DNS problem implied by URIBL_BLOCKED, it's fairly
>> common to get a much higher score on a retest. The reason is simply that
>> that new IP addresses and domains take some time to get listed.
>
> That's most likely the cause here. The presence of URIBL_BLOCKED in the MTA results shows that DNS BL lookups *are* working.
>
> If you have some way to re-inject that message into your mail stream for processing, I wager you'd see new BL hits now from the MTA as well.
Ah, I guess you are right. I notice some URIBL_DBL_SPAM for example in other messages that do get scored properly. Hmm, so I guess I’ll have to train the bayes filter more to get rid of those messages then right?
On a side note, I have set up bind9 as a local, non-forwarding resolver, and it’s configured as the only nameserver. This test works:
# host -tA 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com has address 127.0.0.14
but spamassassin still generates URIBL_BLOCKED. Any suggestions on this?
Thanks,
Tino
Re: Test results differ when input from MTA vs spamc cmdline
Posted by Tino de Bruijn <he...@tino.io>.
> On 15 Feb 2016, at 02:12, John Hardin <jh...@impsec.org> wrote:
>
> On Sun, 14 Feb 2016, RW wrote:
>
>> On Sun, 14 Feb 2016 12:22:36 +0800
>> Tino de Bruijn wrote:
>>
>>> I have some trouble filtering my spam, as everything I try from the
>>> commandline works fine (spamc -t < spam.eml , where spam.eml is a
>>> spam message i dragged out of Mail.app and uploaded to the server),
>>> but when delivered to SA by my MTA (Haraka), it gets a way too low
>>> score (11 vs 3.5 respectively). The spamd.log shows that the online
>>> blacklist checks are not run in the last case:
>>
>> Even without the DNS problem implied by URIBL_BLOCKED, it's fairly
>> common to get a much higher score on a retest. The reason is simply that
>> that new IP addresses and domains take some time to get listed.
>
> That's most likely the cause here. The presence of URIBL_BLOCKED in the MTA results shows that DNS BL lookups *are* working.
>
> If you have some way to re-inject that message into your mail stream for processing, I wager you'd see new BL hits now from the MTA as well.
Ah, I guess you are right. I notice some URIBL_DBL_SPAM for example in other messages that do get scored properly. Hmm, so I guess I’ll have to train the bayes filter more to get rid of those messages then right?
On a side note, I have set up bind9 as a local, non-forwarding resolver, and it’s configured as the only nameserver. This test works:
# host -tA 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com has address 127.0.0.14
but spamassassin still generates URIBL_BLOCKED. Any suggestions on this?
Thanks,
Tino
Re: Test results differ when input from MTA vs spamc cmdline
Posted by John Hardin <jh...@impsec.org>.
On Sun, 14 Feb 2016, RW wrote:
> On Sun, 14 Feb 2016 12:22:36 +0800
> Tino de Bruijn wrote:
>
>> I have some trouble filtering my spam, as everything I try from the
>> commandline works fine (spamc -t < spam.eml , where spam.eml is a
>> spam message i dragged out of Mail.app and uploaded to the server),
>> but when delivered to SA by my MTA (Haraka), it gets a way too low
>> score (11 vs 3.5 respectively). The spamd.log shows that the online
>> blacklist checks are not run in the last case:
>
> Even without the DNS problem implied by URIBL_BLOCKED, it's fairly
> common to get a much higher score on a retest. The reason is simply that
> that new IP addresses and domains take some time to get listed.
That's most likely the cause here. The presence of URIBL_BLOCKED in the
MTA results shows that DNS BL lookups *are* working.
If you have some way to re-inject that message into your mail stream for
processing, I wager you'd see new BL hits now from the MTA as well.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Ignorance is no excuse for a law.
-----------------------------------------------------------------------
8 days until George Washington's 284th Birthday
Re: Test results differ when input from MTA vs spamc cmdline
Posted by RW <rw...@googlemail.com>.
On Sun, 14 Feb 2016 12:22:36 +0800
Tino de Bruijn wrote:
> Hi,
>
> I have some trouble filtering my spam, as everything I try from the
> commandline works fine (spamc -t < spam.eml , where spam.eml is a
> spam message i dragged out of Mail.app and uploaded to the server),
> but when delivered to SA by my MTA (Haraka), it gets a way too low
> score (11 vs 3.5 respectively). The spamd.log shows that the online
> blacklist checks are not run in the last case:
Even without the DNS problem implied by URIBL_BLOCKED, it's fairly
common to get a much higher score on a retest. The reason is simply that
that new IP addresses and domains take some time to get listed.