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 2016/11/12 16:27:27 UTC
__MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Hi,
We have one user whose mail server consistently hits
URI_ONLY_MSGID_MALF for what appears to be a misconfigured Exchange
server:
Message-ID: <1E...@bwsrvxch01>
Is a 2.7 point penalty really warranted for this rule when the user
sends an email with only an image in the body?
Of course I could communicate this to the sender, and I will try, but
everyone knows how that goes. If it's warranted, I'll make a local
adjustment, but just wanted to make sure this was scored properly.
Thanks,
Alex
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> the whole point of the DOS_OUTLOOK_TO_MX is to catch mail received directly
>> (no Received: header) from MUAs like outloook (spamware or malware using
>> outlook engine) without using mail server, which is outlook supposed to do.
On 14.11.16 12:43, Alex wrote:
>I don't understand that. There was a Received: header (iceportal.com).
>Are you saying the sender used Outlook to connect to iceportal.com,
>which then sent the email to us? I don't see that being a problem.
Both Received: headers were added by your mail server
"by mail01.example.com" and "by localhost".
The sending server sent messages without any Received: headers, which
together with outlook headers made the mail look like sent from outlook to
your mail server.
According to further discussion you can blame iceportal for that.
>What's missing from this header that shows it wasn't authenticated?
>Something like "Authenticated sender:" we normally see with
>submission?
this is possible, provided iceportal and mailer.alexhost.md provide the info
and SA will gather it.
--
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.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Mon, 14 Nov 2016, RW wrote:
> On Mon, 14 Nov 2016 15:15:28 +0100
> Matus UHLAR - fantomas wrote:
>
>> On 13.11.16 20:54, Alex wrote:
>
>> the whole point of the DOS_OUTLOOK_TO_MX is to catch mail received
>> directly (no Received: header) from MUAs like outloook (spamware or
>> malware using outlook engine) without using mail server, which is
>> outlook supposed to do.
>
> Possibly, but I've always assumed that the point is to catch forged
> outlook headers. There are several other rules that detect them
> through format errors.
>
>>> Received: from mail.iceportal.com (mail.iceportal.com [54.84.44.70])
>>> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
>
> If you point a browser to mail.iceportal.com there's a webmail login
> page that says they are running something called surgemail. I had a
> quick look on the surgemail site and, as I suspected, it has a "privacy"
> option to suppress the received header for an authenticated submission.
Ugh.
So it sounds like the direct-to-MX rules may need to exclude messages
received via mail.iceportal.com? And potentially others using surgemail?
How would we detect *that*?
> I had a look at some emails sent via Hushmail and they add the header
> but don't put much in it, which seems more sensible.
Agreed. I hope iceportal/surgemail is open to doing the same.
--
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
-----------------------------------------------------------------------
Maxim IX: Never turn your back on an enemy.
-----------------------------------------------------------------------
329 days since the first successful real return to launch site (SpaceX)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by RW <rw...@googlemail.com>.
On Mon, 14 Nov 2016 15:15:28 +0100
Matus UHLAR - fantomas wrote:
> On 13.11.16 20:54, Alex wrote:
> the whole point of the DOS_OUTLOOK_TO_MX is to catch mail received
> directly (no Received: header) from MUAs like outloook (spamware or
> malware using outlook engine) without using mail server, which is
> outlook supposed to do.
Possibly, but I've always assumed that the point is to catch forged
outlook headers. There are several other rules that detect them
through format errors.
> >Received: from mail.iceportal.com (mail.iceportal.com [54.84.44.70])
> > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
If you point a browser to mail.iceportal.com there's a webmail login
page that says they are running something called surgemail. I had a
quick look on the surgemail site and, as I suspected, it has a "privacy"
option to suppress the received header for an authenticated submission.
I had a look at some emails sent via Hushmail and they add the header
but don't put much in it, which seems more sensible.
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
Hi,
> the whole point of the DOS_OUTLOOK_TO_MX is to catch mail received directly
> (no Received: header) from MUAs like outloook (spamware or malware using
> outlook engine) without using mail server, which is outlook supposed to do.
I don't understand that. There was a Received: header (iceportal.com).
Are you saying the sender used Outlook to connect to iceportal.com,
which then sent the email to us? I don't see that being a problem.
>> X-Spam-Status: No, score=0.454 tagged_above=-200 required=5
>> tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845,
>> RELAYCOUNTRY_US=0.01,
>> RP_MATCHES_RCVD=-0.5, SPF_PASS=-0.001] autolearn=disabled
>> X-Spam-RelaysUntrusted: [ ip=54.84.44.70 rdns=mail.iceportal.com
>> helo=mail.iceportal.com by=mail01.example.com ident= envfrom=
>> intl=0 id=709AA6800A028 auth= msa=0 ]
>> Received: from mail01.example.com ([127.0.0.1])
>> by localhost (mail01.example.com [127.0.0.1]) (amavisd-new, port
>> 10024)
>> with ESMTP id UcdVmb46ChiS for <Da...@example.com>;
>> Tue, 8 Nov 2016 16:57:29 -0500 (EST)
>> Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
>> client-ip=54.84.44.70; helo=mail.iceportal.com;
>> envelope-from=bo@iceportal.com; receiver=dan.rambach@example.com
>> Received: from mail.iceportal.com (mail.iceportal.com [54.84.44.70])
>> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
>> bits))
>> (No client certificate requested)
>> by mail01.example.com (Postfix) with ESMTPS id 709AA6800A028
>> for <Da...@example.com>; Tue, 8 Nov 2016 16:57:29 -0500
>> (EST)
>> X-Default-Received-SPF: pass (skip=forwardok (res=PASS));
>> From: "Bo Yao" <Bo...@iceportal.com>
>> To: "'Rambach, Dan'" <Da...@example.com>
>
>
> looks like the above - no relay. Mail was received from mail.iceportal.com
> with no Received: header.
> the mail apparently contains:
>
> __ANY_OUTLOOK_MUA X-Mailer =~ /^Microsoft (?:Office )?Outlook\b/
>
> because:
>
> meta DOS_OUTLOOK_TO_MX __ANY_OUTLOOK_MUA && !__OE_MUA &&
> __DOS_DIRECT_TO_MX && !T_DOS_OUTLOOK_TO_MX_IMAGE
>
> finally that means, the mail does contain outloook header but no Received:
> header, so it fullfills reasons to hit DOS_OUTLOOK_TO_MX
It's more complicated than that because __DOS_DIRECT_TO_MX itself
expands to numerous other rules.
meta __DOS_DIRECT_TO_MX __DOS_SINGLE_EXT_RELAY &&
!__DOS_HAS_LIST_ID && !__DOS_HAS_LIST_UNSUB && !__DOS_HAS_MAILING_LIST
&& !__DOS_RELAYED_EXT
I checked __DOS_SINGLE_EXT_RELAY, and X-Spam-Relays-External does not
exist in any of the messages with __DOS_DIRECT_TO_MX, so I don't know
how this rule hit.
I do see __ANY_OUTLOOK_MUA , so perhaps I'm not fully understanding the rule.
John wrote:
> So it sounds like the direct-to-MX rules may need to exclude messages
> received via mail.iceportal.com? And potentially others using surgemail?
> How would we detect *that*?
Here's also the original header to help with that:
Received: from mailer.alexhost.md (mailer.alexhost.md [176.123.6.65])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail02.example.com (Postfix) with ESMTPS id 992593511CD
for <La...@example.com>; Tue, 8 Nov 2016 02:59:18 -0500
What's missing from this header that shows it wasn't authenticated?
Something like "Authenticated sender:" we normally see with
submission?
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 13.11.16 20:54, Alex wrote:
>>> * 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook
>>>
>>> Are we sure that rule is correct?
>>
>> Pretty sure. Senders should smtp authentication.
>
>I meant the score, but I don't know how to trigger the rule so I can
>investigate further. I'd appreciate guidance there.
the whole point of the DOS_OUTLOOK_TO_MX is to catch mail received directly
(no Received: header) from MUAs like outloook (spamware or malware using
outlook engine) without using mail server, which is outlook supposed to do.
>> On 12.11.16 22:58, Alex wrote:
>>> No. It looks like it was received by another mail server directly using
>>> TLS:
so it just hits what is should hit... TLS is unimportant, authenthication is
important there.
>>> Received: from mailer.alexhost.md (mailer.alexhost.md [176.123.6.65])
>>> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>>> (No client certificate requested)
>>> by mail01.example.com (Postfix) with ESMTPS id 9A7186800C807
>>> for <La...@example.com>; Mon, 7 Nov 2016 06:56:37 -0500
>>> (EST)
>I also see quite a few occurrences of T_DOS_OUTLOOK_TO_MX_IMAGE.
T_DOS_OUTLOOK_TO_MX_IMAGE is complementary to DOS_OUTLOOK_TO_MX
>Here's another example from a few days ago with a more complete header:
>
>X-Spam-Status: No, score=0.454 tagged_above=-200 required=5
> tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RELAYCOUNTRY_US=0.01,
> RP_MATCHES_RCVD=-0.5, SPF_PASS=-0.001] autolearn=disabled
>X-Spam-RelaysUntrusted: [ ip=54.84.44.70 rdns=mail.iceportal.com
> helo=mail.iceportal.com by=mail01.example.com ident= envfrom=
> intl=0 id=709AA6800A028 auth= msa=0 ]
>Received: from mail01.example.com ([127.0.0.1])
> by localhost (mail01.example.com [127.0.0.1]) (amavisd-new, port 10024)
> with ESMTP id UcdVmb46ChiS for <Da...@example.com>;
> Tue, 8 Nov 2016 16:57:29 -0500 (EST)
>Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
>client-ip=54.84.44.70; helo=mail.iceportal.com;
>envelope-from=bo@iceportal.com; receiver=dan.rambach@example.com
>Received: from mail.iceportal.com (mail.iceportal.com [54.84.44.70])
> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
> (No client certificate requested)
> by mail01.example.com (Postfix) with ESMTPS id 709AA6800A028
> for <Da...@example.com>; Tue, 8 Nov 2016 16:57:29 -0500 (EST)
>X-Default-Received-SPF: pass (skip=forwardok (res=PASS));
>From: "Bo Yao" <Bo...@iceportal.com>
>To: "'Rambach, Dan'" <Da...@example.com>
looks like the above - no relay. Mail was received from mail.iceportal.com
with no Received: header.
the mail apparently contains:
__ANY_OUTLOOK_MUA X-Mailer =~ /^Microsoft (?:Office )?Outlook\b/
because:
meta DOS_OUTLOOK_TO_MX __ANY_OUTLOOK_MUA && !__OE_MUA && __DOS_DIRECT_TO_MX && !T_DOS_OUTLOOK_TO_MX_IMAGE
finally that means, the mail does contain outloook header but no Received:
header, so it fullfills reasons to hit DOS_OUTLOOK_TO_MX
--
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.
(R)etry, (A)bort, (C)ancer
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
Hi,
>> * 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook
>>
>> Are we sure that rule is correct?
>
> Pretty sure. Senders should smtp authentication.
I meant the score, but I don't know how to trigger the rule so I can
investigate further. I'd appreciate guidance there.
>>> Are you accepting email directly from clients (MUAs) on your public MTA
>>> interface? Without authentication?
>
>
> On 12.11.16 22:58, Alex wrote:
>>
>> No. It looks like it was received by another mail server directly using
>> TLS:
>>
>> Received: from mailer.alexhost.md (mailer.alexhost.md [176.123.6.65])
>> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>> (No client certificate requested)
>> by mail01.example.com (Postfix) with ESMTPS id 9A7186800C807
>> for <La...@example.com>; Mon, 7 Nov 2016 06:56:37 -0500
>> (EST)
>
>
> may be problem of trustpath. Are you sure the 176.123.6.65 is not in your
> internal_networks? Are you sure the DOS_OUTLOOK_TO_MX wasn't
> added by 176.123.6.65 ?
No, that IP or any range similar to that are in my trust path. It's
also not the first time I've seen it over the last few days, on
completely different IP ranges.
I also see quite a few occurrences of T_DOS_OUTLOOK_TO_MX_IMAGE.
Here's another example from a few days ago with a more complete header:
X-Spam-Status: No, score=0.454 tagged_above=-200 required=5
tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RELAYCOUNTRY_US=0.01,
RP_MATCHES_RCVD=-0.5, SPF_PASS=-0.001] autolearn=disabled
X-Spam-RelaysUntrusted: [ ip=54.84.44.70 rdns=mail.iceportal.com
helo=mail.iceportal.com by=mail01.example.com ident= envfrom=
intl=0 id=709AA6800A028 auth= msa=0 ]
Received: from mail01.example.com ([127.0.0.1])
by localhost (mail01.example.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UcdVmb46ChiS for <Da...@example.com>;
Tue, 8 Nov 2016 16:57:29 -0500 (EST)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
client-ip=54.84.44.70; helo=mail.iceportal.com;
envelope-from=bo@iceportal.com; receiver=dan.rambach@example.com
Received: from mail.iceportal.com (mail.iceportal.com [54.84.44.70])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail01.example.com (Postfix) with ESMTPS id 709AA6800A028
for <Da...@example.com>; Tue, 8 Nov 2016 16:57:29 -0500 (EST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS));
From: "Bo Yao" <Bo...@iceportal.com>
To: "'Rambach, Dan'" <Da...@example.com>
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On Sat, 12 Nov 2016, Alex wrote:
>>> I found another one today while going through FPs.
>>>
>>> * 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
>>>
>>> Are we sure that rule is correct?
Pretty sure. Senders should smtp authentication.
>On Sat, Nov 12, 2016 at 10:01 PM, John Hardin <jh...@impsec.org> wrote:
>> Are you accepting email directly from clients (MUAs) on your public MTA
>> interface? Without authentication?
On 12.11.16 22:58, Alex wrote:
>No. It looks like it was received by another mail server directly using TLS:
>
>Received: from mailer.alexhost.md (mailer.alexhost.md [176.123.6.65])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by mail01.example.com (Postfix) with ESMTPS id 9A7186800C807
> for <La...@example.com>; Mon, 7 Nov 2016 06:56:37 -0500 (EST)
may be problem of trustpath. Are you sure the 176.123.6.65 is not in your
internal_networks? Are you sure the DOS_OUTLOOK_TO_MX wasn't added by
176.123.6.65 ?
--
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.
Christian Science Programming: "Let God Debug It!".
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
Hi,
On Sat, Nov 12, 2016 at 10:01 PM, John Hardin <jh...@impsec.org> wrote:
> On Sat, 12 Nov 2016, Alex wrote:
>
>> I found another one today while going through FPs.
>>
>> * 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
>>
>> Are we sure that rule is correct?
>
> Are you accepting email directly from clients (MUAs) on your public MTA
> interface? Without authentication?
No. It looks like it was received by another mail server directly using TLS:
Received: from mailer.alexhost.md (mailer.alexhost.md [176.123.6.65])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail01.example.com (Postfix) with ESMTPS id 9A7186800C807
for <La...@example.com>; Mon, 7 Nov 2016 06:56:37 -0500 (EST)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Sat, 12 Nov 2016, Alex wrote:
> I found another one today while going through FPs.
>
> * 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
>
> Are we sure that rule is correct?
Are you accepting email directly from clients (MUAs) on your public MTA
interface? Without authentication?
--
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
-----------------------------------------------------------------------
Justice is justice, whereas "social justice" is code for one set
of rules for the rich, another for the poor; one set for whites,
another set for minorities; one set for straight men, another for
women and gays. In short, it's the opposite of actual justice.
-- Burt Prelutsky
-----------------------------------------------------------------------
327 days since the first successful real return to launch site (SpaceX)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
Hi,
On Sat, Nov 12, 2016 at 2:22 PM, John Hardin <jh...@impsec.org> wrote:
> On Sat, 12 Nov 2016, Alex wrote:
>
>> Just found another disproportionate rule. Can you also tell me if you
>> think URI_OBFU_WWW deserves 2.5 points? That also seems quite high.
>>
>> * 2.5 URI_OBFU_WWW BODY: Obfuscated URI
>>
>> Choice Central<www,choicecentral.com>
>
>
> That one came up a week or so back. Given the S/O I can't understand why
> it's being scored that high (ignoring the score limit!), or even being
> published.
>
> I've disabled it as masscheck still doesn't seem to be handling this rule
> correctly.
I found another one today while going through FPs.
* 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
Are we sure that rule is correct? Other than BAYES50 and SPF_SOFTFAIL,
it wouldn't have been pushed over.
* 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
* 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
* [score: 0.4266]
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 1.0 BODY_CYRILLIC No description available.
* 0.2 RELAYCOUNTRY_MED Relayed by an improbable email source
* 0.0 T_DMARC_TESTS_FAIL No description available.
* 0.0 T_REMOTE_IMAGE Message contains an external image
* 0.1 LOC_RUSS Cyrillic text to non-local recipient
* 2.8 DOS_OUTLOOK_TO_MX Delivered direct to MX with Outlook headers
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Sat, 12 Nov 2016, Alex wrote:
> Just found another disproportionate rule. Can you also tell me if you
> think URI_OBFU_WWW deserves 2.5 points? That also seems quite high.
>
> * 2.5 URI_OBFU_WWW BODY: Obfuscated URI
>
> Choice Central<www,choicecentral.com>
That one came up a week or so back. Given the S/O I can't understand why
it's being scored that high (ignoring the score limit!), or even being
published.
I've disabled it as masscheck still doesn't seem to be handling this rule
correctly.
--
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
-----------------------------------------------------------------------
Win95: Where do you want to go today?
Vista: Where will Microsoft allow you to go today?
-----------------------------------------------------------------------
327 days since the first successful real return to launch site (SpaceX)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
On Sat, Nov 12, 2016 at 12:07 PM, John Hardin <jh...@impsec.org> wrote:
> On Sat, 12 Nov 2016, Alex wrote:
>
>> Hi,
>> We have one user whose mail server consistently hits
>> URI_ONLY_MSGID_MALF for what appears to be a misconfigured Exchange
>> server:
>>
>> Message-ID: <1E...@bwsrvxch01>
>>
>> Is a 2.7 point penalty really warranted for this rule when the user
>> sends an email with only an image in the body?
>
>
> If spammers send image-only spam having malformed message IDs that doesn't
> hit a lot of other rules, yes.
>
> That said, given its current performance in masscheck I'm surprised it's
> being scored quite that high.
>
>> Of course I could communicate this to the sender, and I will try, but
>> everyone knows how that goes. If it's warranted, I'll make a local
>> adjustment, but just wanted to make sure this was scored properly.
>
>
> What is the total score his messages are getting? 2.7 points isn't a poison
> pill score.
Just found another disproportionate rule. Can you also tell me if you
think URI_OBFU_WWW deserves 2.5 points? That also seems quite high.
* 2.5 URI_OBFU_WWW BODY: Obfuscated URI
Choice Central<www,choicecentral.com>
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Sat, 12 Nov 2016, Alex wrote:
> X-Spam-Status: Yes, score=5.985 tag=-200 tag2=5 kill=5 tests=[BAYES_50=0.8,
> BODY_SINGLE_WORD=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001,
> KAM_COUK=0.7, KAM_LAZY_DOMAIN_SECURITY=1, LOC_CDIS_INLINE=0.1,
> LOC_IMGSPAM=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_LOW=-0.7,
> RCVD_IN_HOSTKARMA_W=-1, RCVD_IN_MSPIKE_H3=-0.01,
> RCVD_IN_MSPIKE_WL=-0.01, RELAYCOUNTRY_LOW=0.1,
> T_DMARC_TESTS_FAIL=0.01, URI_ONLY_MSGID_MALF=2.699] autolearn=disabled
OK, I also added an exclusion for RCVD_IN_DNSWL_LOW, which seems safe to
me. That should fix you when it goes out.
--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
327 days since the first successful real return to launch site (SpaceX)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Sat, 12 Nov 2016, Alex wrote:
> Hi,
>
> On Sat, Nov 12, 2016 at 12:07 PM, John Hardin <jh...@impsec.org> wrote:
>> On Sat, 12 Nov 2016, Alex wrote:
>>
>>> Hi,
>>> We have one user whose mail server consistently hits
>>> URI_ONLY_MSGID_MALF for what appears to be a misconfigured Exchange
>>> server:
>>>
>>> Message-ID: <1E...@bwsrvxch01>
>>>
>>> Is a 2.7 point penalty really warranted for this rule when the user
>>> sends an email with only an image in the body?
>>
>> If spammers send image-only spam having malformed message IDs that doesn't
>> hit a lot of other rules, yes.
>>
>> That said, given its current performance in masscheck I'm surprised it's
>> being scored quite that high.
>>
>>> Of course I could communicate this to the sender, and I will try, but
>>> everyone knows how that goes. If it's warranted, I'll make a local
>>> adjustment, but just wanted to make sure this was scored properly.
>>
>> What is the total score his messages are getting? 2.7 points isn't a poison
>> pill score.
>
> Less than 7.7. I believe 5.9, so it was the rule that pushed it over.
> Here it is:
>
> X-Spam-Status: Yes, score=5.985 tag=-200 tag2=5 kill=5 tests=[BAYES_50=0.8,
> BODY_SINGLE_WORD=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001,
> KAM_COUK=0.7, KAM_LAZY_DOMAIN_SECURITY=1, LOC_CDIS_INLINE=0.1,
> LOC_IMGSPAM=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_LOW=-0.7,
> RCVD_IN_HOSTKARMA_W=-1, RCVD_IN_MSPIKE_H3=-0.01,
> RCVD_IN_MSPIKE_WL=-0.01, RELAYCOUNTRY_LOW=0.1,
> T_DMARC_TESTS_FAIL=0.01, URI_ONLY_MSGID_MALF=2.699] autolearn=disabled
>
> So with the right combination of bayes training and some points being
> added from local rules, it probably could have been avoided even with
> this rule, but it still seems overly punitive. Hmm.. I actually
> wouldn't want to train bayes on an empty body anyway.
Given the current masscheck performance I'll put a limit of 2.000 on it,
but that won't be enough to fix this situation for you.
I'd suggest if that user is consistently sending image-only mails from a
broken/misconfigured MTA, then that user should be whitelisted.
--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
327 days since the first successful real return to launch site (SpaceX)
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by Alex <my...@gmail.com>.
Hi,
On Sat, Nov 12, 2016 at 12:07 PM, John Hardin <jh...@impsec.org> wrote:
> On Sat, 12 Nov 2016, Alex wrote:
>
>> Hi,
>> We have one user whose mail server consistently hits
>> URI_ONLY_MSGID_MALF for what appears to be a misconfigured Exchange
>> server:
>>
>> Message-ID: <1E...@bwsrvxch01>
>>
>> Is a 2.7 point penalty really warranted for this rule when the user
>> sends an email with only an image in the body?
>
> If spammers send image-only spam having malformed message IDs that doesn't
> hit a lot of other rules, yes.
>
> That said, given its current performance in masscheck I'm surprised it's
> being scored quite that high.
>
>> Of course I could communicate this to the sender, and I will try, but
>> everyone knows how that goes. If it's warranted, I'll make a local
>> adjustment, but just wanted to make sure this was scored properly.
>
> What is the total score his messages are getting? 2.7 points isn't a poison
> pill score.
Less than 7.7. I believe 5.9, so it was the rule that pushed it over.
Here it is:
X-Spam-Status: Yes, score=5.985 tag=-200 tag2=5 kill=5 tests=[BAYES_50=0.8,
BODY_SINGLE_WORD=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001,
KAM_COUK=0.7, KAM_LAZY_DOMAIN_SECURITY=1, LOC_CDIS_INLINE=0.1,
LOC_IMGSPAM=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_HOSTKARMA_W=-1, RCVD_IN_MSPIKE_H3=-0.01,
RCVD_IN_MSPIKE_WL=-0.01, RELAYCOUNTRY_LOW=0.1,
T_DMARC_TESTS_FAIL=0.01, URI_ONLY_MSGID_MALF=2.699] autolearn=disabled
So with the right combination of bayes training and some points being
added from local rules, it probably could have been avoided even with
this rule, but it still seems overly punitive. Hmm.. I actually
wouldn't want to train bayes on an empty body anyway.
Re: __MSGID_NOFQDN2 and URI_ONLY_MSGID_MALF
Posted by John Hardin <jh...@impsec.org>.
On Sat, 12 Nov 2016, Alex wrote:
> Hi,
> We have one user whose mail server consistently hits
> URI_ONLY_MSGID_MALF for what appears to be a misconfigured Exchange
> server:
>
> Message-ID: <1E...@bwsrvxch01>
>
> Is a 2.7 point penalty really warranted for this rule when the user
> sends an email with only an image in the body?
If spammers send image-only spam having malformed message IDs that doesn't
hit a lot of other rules, yes.
That said, given its current performance in masscheck I'm surprised it's
being scored quite that high.
> Of course I could communicate this to the sender, and I will try, but
> everyone knows how that goes. If it's warranted, I'll make a local
> adjustment, but just wanted to make sure this was scored properly.
What is the total score his messages are getting? 2.7 points isn't a
poison pill score.
--
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
-----------------------------------------------------------------------
USMC Rules of Gunfighting #6: If you can choose what to bring to a
gunfight, bring a long gun and a friend with a long gun.
-----------------------------------------------------------------------
327 days since the first successful real return to launch site (SpaceX)