You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Matus UHLAR - fantomas <uh...@fantomas.sk> on 2019/04/26 13:44:54 UTC
__DOS_DIRECT_TO_MX superflous __DOS_RELAYED_EXT
Hello,
when looking at __DOS_DIRECT_TO_MX I have noticed that it consists of one
superflous rule:
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 believe hitting __DOS_SINGLE_EXT_RELAY implies not hitting
__DOS_RELAYED_EXT, because:
header __DOS_SINGLE_EXT_RELAY X-Spam-Relays-External =~ /^\[ [^\]]+ \]$/
header __DOS_RELAYED_EXT ALL-EXTERNAL =~ /(?:^|\n)[Rr][eE][cC][eE][iI][vV][eE][dD]:\s.+\n[Rr][eE][cC][eE][iI][vV][eE][dD]:\s/s
looking at the docs, __DOS_RELAYED_EXT only matches when there are multiple
Received: headers in external relays, however such mail would have multiple
relays in X-Spam-Relays-External and thus it could not match
__DOS_SINGLE_EXT_RELAY
do I misunderstand this?
--
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.
Silvester Stallone: Father of the RISC concept.
Re: __DOS_DIRECT_TO_MX superflous __DOS_RELAYED_EXT
Posted by RW <rw...@googlemail.com>.
On Sat, 27 Apr 2019 15:21:13 +0200
Matus UHLAR - fantomas wrote:
> >On Fri, 26 Apr 2019 15:44:54 +0200
> >I think that __DOS_SINGLE_EXT_RELAY could FP where an external
> >MTA, configured to use a smart host, authenticates into the internal
> >network (see bug 7590)
>
> I don't quite understand the bug. The presence of authentication
> header should cause the rest of headers being in the trusted/internal
> network.
That's how I used to think it worked. IIRC someone remarked that they
didn't want to put their submission server into msi_networks because
they didn't wish to make anything beyond their submission server
trusted, so I ran some tests to see what happens if you leave it to
authentication detection.
What I found was that only the submission relay was being made
internal, but looking at it again it looks like additional relays can be
made internal if they also have authentication, until we get to one
that isn't authenticated, which becomes the first entry in
relays-[external,untrusted].
So there is some scope for running blocklists, but it's very limited.
If you have:
Received: from open-relay by submission-server with ESMTPSA
Received: from client by open-relay with ESMTP
the second relay gets treated as the last-external, so the client gets
all the look-ups including PBL etc, but no look-ups are made against the
open-relay.
This is a bit sub-optimal, but not hugely wrong. The more serious
problem is that it's possible to forge a header that will be treated
as the edge of the trusted network.
I doesn't look like this is relevant to the direct-to-mx thing.
Re: __DOS_DIRECT_TO_MX superflous __DOS_RELAYED_EXT
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Fri, 26 Apr 2019 15:44:54 +0200
>Matus UHLAR - fantomas wrote:
>> when looking at __DOS_DIRECT_TO_MX I have noticed that it consists of
>> one superflous rule:
>...
>> I believe hitting __DOS_SINGLE_EXT_RELAY implies not hitting
>> __DOS_RELAYED_EXT, because:
>>
>> header __DOS_SINGLE_EXT_RELAY X-Spam-Relays-External =~ /^\[ [^\]]+
>> \]$/ header __DOS_RELAYED_EXT ALL-EXTERNAL
>> =~ /(?:^|\n)[Rr][eE][cC][eE][iI][vV][eE][dD]:\s.+\n[Rr][eE][cC][eE][iI][vV][eE][dD]:\s/s
>>
>> looking at the docs, __DOS_RELAYED_EXT only matches when there are
>> multiple Received: headers in external relays, however such mail
>> would have multiple relays in X-Spam-Relays-External and thus it
>> could not match __DOS_SINGLE_EXT_RELAY
On 26.04.19 19:13, RW wrote:
>I noticed this myself. IIRC I didn't mention it because it's harmless
>and it's difficult to establish that there aren't rare corner cases
>where it's needed.
this is just why I ask - just for sure.
>I think that __DOS_SINGLE_EXT_RELAY could FP where an external
>MTA, configured to use a smart host, authenticates into the internal
>network (see bug 7590)
I don't quite understand the bug. The presence of authentication header
should cause the rest of headers being in the trusted/internal network.
I think authentication should cause behaviour just as 81.171.57.60 was in
msa_networks.
> - possibly __DOS_SINGLE_EXT_RELAY mitigates
>that.
you apparently mean __DOS_RELAYED_EXT ;-)
--
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.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
Re: __DOS_DIRECT_TO_MX superflous __DOS_RELAYED_EXT
Posted by RW <rw...@googlemail.com>.
On Fri, 26 Apr 2019 19:13:43 +0100
RW wrote:
> On Fri, 26 Apr 2019 15:44:54 +0200
> Matus UHLAR - fantomas wrote:
>
> > Hello,
> >
> > when looking at __DOS_DIRECT_TO_MX I have noticed that it consists
> > of one superflous rule:
> ...
> > I believe hitting __DOS_SINGLE_EXT_RELAY implies not hitting
> > __DOS_RELAYED_EXT, because:
> >
> > header __DOS_SINGLE_EXT_RELAY X-Spam-Relays-External
> > =~ /^\[ [^\]]+ \]$/ header __DOS_RELAYED_EXT ALL-EXTERNAL
> > =~ /(?:^|\n)[Rr][eE][cC][eE][iI][vV][eE][dD]:\s.+\n[Rr][eE][cC][eE][iI][vV][eE][dD]:\s/s
> >
> > looking at the docs, __DOS_RELAYED_EXT only matches when there are
> > multiple Received: headers in external relays, however such mail
> > would have multiple relays in X-Spam-Relays-External and thus it
> > could not match __DOS_SINGLE_EXT_RELAY
>
> I noticed this myself. IIRC I didn't mention it because it's harmless
> and it's difficult to establish that there aren't rare corner cases
> where it's needed.
They are both needed.
__DOS_SINGLE_EXT_RELAY would miss an upstream relay if it's unparsable,
whereas __DOS_RELAYED_EXT is looking for a deep received header.
!__DOS_RELAYED_EXT alone would FP in the cases where there are no
received headers in ALL-EXTERNAL, whereas __DOS_SINGLE_EXT_RELAY
requires a single entry in Relays-External.
Re: __DOS_DIRECT_TO_MX superflous __DOS_RELAYED_EXT
Posted by RW <rw...@googlemail.com>.
On Fri, 26 Apr 2019 15:44:54 +0200
Matus UHLAR - fantomas wrote:
> Hello,
>
> when looking at __DOS_DIRECT_TO_MX I have noticed that it consists of
> one superflous rule:
...
> I believe hitting __DOS_SINGLE_EXT_RELAY implies not hitting
> __DOS_RELAYED_EXT, because:
>
> header __DOS_SINGLE_EXT_RELAY X-Spam-Relays-External =~ /^\[ [^\]]+
> \]$/ header __DOS_RELAYED_EXT ALL-EXTERNAL
> =~ /(?:^|\n)[Rr][eE][cC][eE][iI][vV][eE][dD]:\s.+\n[Rr][eE][cC][eE][iI][vV][eE][dD]:\s/s
>
> looking at the docs, __DOS_RELAYED_EXT only matches when there are
> multiple Received: headers in external relays, however such mail
> would have multiple relays in X-Spam-Relays-External and thus it
> could not match __DOS_SINGLE_EXT_RELAY
I noticed this myself. IIRC I didn't mention it because it's harmless
and it's difficult to establish that there aren't rare corner cases
where it's needed.
I think that __DOS_SINGLE_EXT_RELAY could FP where an external
MTA, configured to use a smart host, authenticates into the internal
network (see bug 7590) - possibly __DOS_SINGLE_EXT_RELAY mitigates
that.