Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. SpamAssassin>
  3. users
__DOS_DIRECT_TO_MX false positive
premax at hot
Jan 30, 2020, 1:24 PM
Post #1 of 7 (458 views)
Permalink
Hello there,

The sender is using Outlook and his own mail server. Mail comes to my server
and scores against DOS_OUTLOOK_TO_MX, because of __DOS_DIRECT_TO_MX false
positive. I've been looking into message headers for hours and see nothing
strange over there. 'Received' header are present. Why is that happening?

Here go message headers:

Return-Path: <webmaster@SENDERDOMAIN.ORG>
Delivered-To: xxx.xxx@MYDOMAIN.COM
Received: from localhost (localhost [127.0.0.1])
by mail.MYSERVER.COM (Postfix) with ESMTP id 8FF5CF801E2
for <xxx.xxx@MYDOMAIN.COM>; Wed, 29 Jan 2020 15:08:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at mail.MYSERVER.COM
X-Spam-Flag: NO
X-Spam-Score: 4.351
X-Spam-Level: ****
X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31
tests=[.BAYES_00=-1.9, DCC_CHECK=1.1, DIGEST_MULTIPLE=0.293,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001,
MIME_HTML_MOSTLY=0.1, PYZOR_CHECK=1.392, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
ZABOJCASPAMU_BULK_SIGNATURE=0.01, ZABOJCASPAMU_FSL_HTML_COMMENT=0.7,
ZABOJCASPAMU_SMTPNUMBER=0.01] autolearn=no autolearn_force=no
Authentication-Results: ln2.MYSERVER.COM (amavisd-new); dkim=pass (1024-bit
key)
header.d=SENDERDOMAIN.ORG
Received: from mail.MYSERVER.COM ([172.20.11.96])
by localhost (ln2.MYSERVER.COM [127.0.0.1]) (amavisd-new, port
10024)
with ESMTP id hH6H7WQcFFvZ
for <xxx.xxx@MYDOMAIN.COM>;
Wed, 29 Jan 2020 15:08:44 +0100 (CET)
Received: from cache35.HISSERVER.COM (cache35.HISSERVER.COM [xx.xx.241.219])
by mail.MYSERVER.COM (Postfix) with ESMTPS id 5797DF801DE
for <xxx.xxx@MYDOMAIN.COM>; Wed, 29 Jan 2020 15:08:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=SENDERDOMAIN.ORG;
s=devil;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender:

Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:

Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:

In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=h4pJYmQ0nUrSyDSpmmTMRGQujrhNUzRT7j0y17TLUlw=;
b=RaP5CxIGho9jLMUqOoxkBvlmsV

An6EeqGxIn7siqMrP6Lci9cLlCOQ09553AOH4U0sHXNfLZR/dgeXRXl5j7C4hj7BRtM8lBYw4TtZL

FGli8gs4b4qaJSYhIdeTFTuygg4X/8wD8qTRxYTrE1dujJggPR1neGdtTBaF6WliKsD4=;
From: <webmaster@SENDERDOMAIN.ORG>
To: <xxx.xxx@MYDOMAIN.COM>
Subject: test
Date: Wed, 29 Jan 2020 15:09:27 +0100
Message-ID: <008201d5d6ad$b7f85850$27e908f0$@SENDERDOMAIN.ORG>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0083_01D5D6B6.19BDF8D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdXWrba3pRodoOJQQkyaRqs7rd42Tw==
Content-Language: pl
X-AV-Check: Passed
X-System-Sender: webmaster@SENDERDOMAIN.ORG
X-System-UID: 1227

I am using Spamassasin 3.42 run by Amavisd-new 2.7.1. All rules updated.

Any suggestions?

Cheers

PP



--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
jhardin at impsec
Jan 30, 2020, 3:37 PM
Post #2 of 7 (457 views)
Permalink
On Thu, 30 Jan 2020, premax wrote:

> Hello there,
>
> The sender is using Outlook and his own mail server. Mail comes to my
> server and scores against DOS_OUTLOOK_TO_MX, because of
> __DOS_DIRECT_TO_MX false positive. I've been looking into message
> headers for hours and see nothing strange over there. 'Received' header
> are present. Why is that happening?
>
> Here go message headers:

...pruned a bit to focus...

> Received: from localhost (localhost [127.0.0.1])
> by mail.MYSERVER.COM (Postfix) with ESMTP id 8FF5CF801E2
> for <xxx.xxx@MYDOMAIN.COM>; Wed, 29 Jan 2020 15:08:48 +0100 (CET)
> SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
> ZABOJCASPAMU_BULK_SIGNATURE=0.01, ZABOJCASPAMU_FSL_HTML_COMMENT=0.7,
> ZABOJCASPAMU_SMTPNUMBER=0.01] autolearn=no autolearn_force=no
> Received: from mail.MYSERVER.COM ([172.20.11.96])
> by localhost (ln2.MYSERVER.COM [127.0.0.1]) (amavisd-new, port 10024)
> with ESMTP id hH6H7WQcFFvZ
> for <xxx.xxx@MYDOMAIN.COM>;
> Wed, 29 Jan 2020 15:08:44 +0100 (CET)
> Received: from cache35.HISSERVER.COM (cache35.HISSERVER.COM [xx.xx.241.219])
> by mail.MYSERVER.COM (Postfix) with ESMTPS id 5797DF801DE
> for <xxx.xxx@MYDOMAIN.COM>; Wed, 29 Jan 2020 15:08:44 +0100 (CET)

...and that's it.

The problem is that there are no Received headers internal to his domain,
and that makes it look like a MUA is directly contacting your MTA to send
an email - hence, "DIRECT_TO_MX".

If you can, advise the sender to not remove all the Received headers from
their email before sending it to others. There should be at least one: the
Received header for his MTA accepting the message from his MUA.

Absent that, you could whitelist his domain.

That message is not being scored as spam, even if you weren't increasing
the threshold from the default:

> X-Spam-Flag: NO
> X-Spam-Score: 4.351
> X-Spam-Level: ****
> X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31

That a given rule hits on some ham does not make the rule a FP. This rule
is working as designed.


--
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
-----------------------------------------------------------------------
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like "Oh my God, this
place is teeming with utter morons" to incorrect conclusions like
"there's nothing of value here". -- Al Petrofsky, in Y! SCOX
-----------------------------------------------------------------------
2 days until the 17th anniversary of the loss of STS-107 Columbia
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
kmcgrail at apache
Jan 30, 2020, 9:28 PM
Post #3 of 7 (456 views)
Permalink
On 1/30/2020 6:37 PM, John Hardin wrote:
> The problem is that there are no Received headers internal to his
> domain, and that makes it look like a MUA is directly contacting your
> MTA to send an email - hence, "DIRECT_TO_MX".
>
> If you can, advise the sender to not remove all the Received headers
> from their email before sending it to others. There should be at least
> one: the Received header for his MTA accepting the message from his MUA.
>
> Absent that, you could whitelist his domain.
>
> That message is not being scored as spam, even if you weren't
> increasing the threshold from the default:
>
>> X-Spam-Flag: NO
>> X-Spam-Score: 4.351
>> X-Spam-Level: ****
>> X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31
>
> That a given rule hits on some ham does not make the rule a FP. This
> rule is working as designed.


I just wanted to +1 John's analysis on this issue and he is dead-on.  I
also want to reiterate that a FP is only when a email is flagged as
spam.  Some rules are designed to fire in cases that do not indicate
spam or ham status except when analyzed in totality with all the other
scores.

Regards,

KAM

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
rwmaillists at googlemail
Jan 31, 2020, 7:09 AM
Post #4 of 7 (453 views)
Permalink
On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
John Hardin wrote:

> That a given rule hits on some ham does not make the rule a FP. This
> rule is working as designed.

DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
50_scores.cf, set 10 years ago. Is that supposed to happen?
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
uhlar at fantomas
Feb 1, 2020, 8:38 AM
Post #5 of 7 (447 views)
Permalink
>On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
>John Hardin wrote:
>> That a given rule hits on some ham does not make the rule a FP. This
>> rule is working as designed.

On 31.01.20 15:09, RW wrote:
>DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
>50_scores.cf, set 10 years ago. Is that supposed to happen?

if by "that" you mean DOS_OUTLOOK_TO_MX hitting, it's common in companies
without authentication and with single mailserver.

...and, of course, where someone removes or does not add Received: headers.

problem could be lowered by adding that server to trusted_networks although
I'm not sure whether that kind of servers should be added there...
--
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.
99 percent of lawyers give the rest a bad name.
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
rwmaillists at googlemail
Feb 2, 2020, 8:46 AM
Post #6 of 7 (445 views)
Permalink
On Sat, 1 Feb 2020 17:38:52 +0100
Matus UHLAR - fantomas wrote:

> >On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
> >John Hardin wrote:
> >> That a given rule hits on some ham does not make the rule a FP.
> >> This rule is working as designed.
>
> On 31.01.20 15:09, RW wrote:
> >DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
> >50_scores.cf, set 10 years ago. Is that supposed to happen?
>
> if by "that" you mean DOS_OUTLOOK_TO_MX hitting,

No, I meant a rule that's defined in 72_active.cf not having a
modern generated score in 72_scores.cf.
Re: __DOS_DIRECT_TO_MX false positive [ In reply to ]
premax at hot
Feb 4, 2020, 5:52 AM
Post #7 of 7 (440 views)
Permalink
John Hardin wrote
> The problem is that there are no Received headers internal to his domain,
> and that makes it look like a MUA is directly contacting your MTA to send
> an email - hence, "DIRECT_TO_MX".
>
> If you can, advise the sender to not remove all the Received headers from
> their email before sending it to others. There should be at least one: the
> Received header for his MTA accepting the message from his MUA.

Thank you for your reply, now I can see the issue.
I have contacted sender's ISP and asked for not removing 1st Received
header.

regards
PP




--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal