You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Helmut Schneider <ju...@gmx.de> on 2016/04/15 12:10:13 UTC
remaining relays will be considered trusted, but no longer internal
Hi,
when further investigating my issue that ALL_TRUSTED is always true I
came along the following lines when debugging SA:
Apr 15 11:44:43.211 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: parsed as [ ip=172.20.12.10 rdns=relay-in
helo=mail2 by=mail01 ident= envfrom= intl=0 id= auth= msa=0 ]
Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: netset: trusted_networks lookup on 172.20.12.10, 5 networks,
result: 1, 0.617 ms
Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: netset: internal_networks lookup on 172.20.12.10, 5 networks,
result: 1, 0.204 ms
Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: relay 172.20.12.10 trusted? yes internal? yes
msa? no
Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: parsed as [ ip=195.245.231.135
rdns=mail6.bemta5.messagelabs.com helo=mail6.bemta5.messagelabs.com
by=mail2 ident= envfrom= intl=0 id=0CC1B30E auth= msa=0 ]
Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: netset: trusted_networks lookup on 195.245.231.135, 5 networks,
result: 0, 0.204 ms
Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: originating, 195.245.231.135 and remaining relays
will be considered trusted, but no longer internal
Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: relay 195.245.231.135 trusted? yes internal? no
msa? no
Apr 15 11:44:43.216 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: parsed as [ ip=85.158.139.35 rdns= helo=
by=server-4.bemta-5.messagelabs.com ident= envfrom= intl=0
id=B6/BA-18387-A08B0175 auth= msa=0 ]
Apr 15 11:44:43.216 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
dbg: received-header: relay 85.158.139.35 trusted? yes internal? no
msa? no
So SA correctly identifies an relay as external but still trusts the
whole path. Why?
Thanky you
Re: remaining relays will be considered trusted, but no longer internal
Posted by Helmut Schneider <ju...@gmx.de>.
Helmut Schneider wrote:
> when further investigating my issue that ALL_TRUSTED is always true I
> came along the following lines when debugging SA:
>
> Apr 15 11:44:43.211 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: parsed as [ ip=172.20.12.10 rdns=relay-in
> helo=mail2 by=mail01 ident= envfrom= intl=0 id= auth= msa=0 ]
> Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: netset: trusted_networks lookup on 172.20.12.10, 5 networks,
> result: 1, 0.617 ms
> Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: netset: internal_networks lookup on 172.20.12.10, 5 networks,
> result: 1, 0.204 ms
> Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: relay 172.20.12.10 trusted? yes internal? yes
> msa? no
> Apr 15 11:44:43.212 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: parsed as [ ip=195.245.231.135
> rdns=mail6.bemta5.messagelabs.com helo=mail6.bemta5.messagelabs.com
> by=mail2 ident= envfrom= intl=0 id=0CC1B30E auth= msa=0 ]
> Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: netset: trusted_networks lookup on 195.245.231.135, 5 networks,
> result: 0, 0.204 ms
> Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: originating, 195.245.231.135 and remaining
> relays will be considered trusted, but no longer internal
> Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: relay 195.245.231.135 trusted? yes internal? no
> msa? no
> Apr 15 11:44:43.216 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: parsed as [ ip=85.158.139.35 rdns= helo=
> by=server-4.bemta-5.messagelabs.com ident= envfrom= intl=0
> id=B6/BA-18387-A08B0175 auth= msa=0 ]
> Apr 15 11:44:43.216 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: relay 85.158.139.35 trusted? yes internal? no
> msa? no
>
> So SA correctly identifies an relay as external but still trusts the
> whole path. Why?
For the archives: There might be other solutions but exclude your
postfix instances from @mynetworks in amavisd.conf and your fine.
Re: remaining relays will be considered trusted, but no longer
internal
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.04.2016 um 16:34 schrieb Helmut Schneider:
> Reindl Harald wrote:
>
>>
>> Am 15.04.2016 um 16:08 schrieb Helmut Schneider:
>>> What does "submission" mean in this context?
>>
>> ESMT(S)A
>>
>> https://en.wikipedia.org/wiki/SMTP_Authentication
>
> I'm neither using authentication nor smtp submission (TCP587)
but your other hops probably do and record it in the headers, just look
for "with ESMTP", "with ESMTPA" or "with ESMTPSA", and SA reads them
something like
Received: from gumby.homeunix.com ([90.195.213.141])
by smtp.gmail.com with ESMTPSA id r10sm37262232wjf.2.2016.04.15.07.34.51
Re: remaining relays will be considered trusted, but no longer internal
Posted by Helmut Schneider <ju...@gmx.de>.
Reindl Harald wrote:
>
> Am 15.04.2016 um 16:08 schrieb Helmut Schneider:
> > What does "submission" mean in this context?
>
> ESMT(S)A
>
> https://en.wikipedia.org/wiki/SMTP_Authentication
I'm neither using authentication nor smtp submission (TCP587).
Re: remaining relays will be considered trusted, but no longer
internal
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.04.2016 um 16:08 schrieb Helmut Schneider:
> What does "submission" mean in this context?
ESMT(S)A
https://en.wikipedia.org/wiki/SMTP_Authentication
Re: remaining relays will be considered trusted, but no longer internal
Posted by Helmut Schneider <ju...@gmx.de>.
RW wrote:
> On Fri, 15 Apr 2016 14:08:15 +0000 (UTC)
> Helmut Schneider wrote:
>
> > RW wrote:
> >
> > > On Fri, 15 Apr 2016 12:35:24 +0100
> > > RW wrote:
> > >
> > > > On Fri, 15 Apr 2016 10:10:13 +0000 (UTC)
> > > > Helmut Schneider wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > when further investigating my issue that ALL_TRUSTED is always
> > > > > true I came along the following lines when debugging SA:
> > > > >
> > > > > ...
> > > > > Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]:
> > > > > (09991-02) SA dbg: received-header: originating,
> > > > > 195.245.231.135 and remaining relays will be considered
> > > > > trusted, but no longer internal ...
> > > > >
> > > > > So SA correctly identifies an relay as external but still
> > > > > trusts the whole path. Why?
> > > >
> > > > It looks like it's being seen as mail submission. Do you have
> > > > msa_networks set?
> > >
> > > I had a look at the code, and it looks like that particular
> > > message with "but no longer internal" can only be be reached when
> > > a flag is set that asserts that the message was submitted. This
> > > causes the point at which trust would otherwise be broken to be
> > > treated as a submission server.
> >
> > msa_networks is not set.
>
> It's when a mail client submits outgoing mail to an mta. This should
> involve some form of authentication
>
> For some reason amavisd thinks that all of your mail is being
> submitted locally. SA is finding that it's ALL_TRUSTED because amavisd
> is telling SA that it is via the SA perl library interface.
Thank you, this helped a lot:
I have 2 servers with 3 postfix instances each, postfix-in, postfix-out
and postfix-amavis with different IPs each.
All mail is received by the postfix-in instances. For some domains I
forward mails directly to their final destinations, for some I do SPAM
filtering on the postfix-amavis instances.
It seems that ALL mail is treated as relayed internally as soon as I
forward those mails to the postfix-amavis instance:
Passed CLEAN {RelayedInbound}, [52.71.20.6]:55081
52.71.20.6 is an external IP adress.
Now I have to figure out how to prevent amavis from behaving like that.
Re: remaining relays will be considered trusted, but no longer
internal
Posted by RW <rw...@googlemail.com>.
On Fri, 15 Apr 2016 14:08:15 +0000 (UTC)
Helmut Schneider wrote:
> RW wrote:
>
> > On Fri, 15 Apr 2016 12:35:24 +0100
> > RW wrote:
> >
> > > On Fri, 15 Apr 2016 10:10:13 +0000 (UTC)
> > > Helmut Schneider wrote:
> > >
> > > > Hi,
> > > >
> > > > when further investigating my issue that ALL_TRUSTED is always
> > > > true I came along the following lines when debugging SA:
> > > >
> > > > ...
> > > > Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02)
> > > > SA dbg: received-header: originating, 195.245.231.135 and
> > > > remaining relays will be considered trusted, but no longer
> > > > internal ...
> > > >
> > > > So SA correctly identifies an relay as external but still trusts
> > > > the whole path. Why?
> > >
> > > It looks like it's being seen as mail submission. Do you have
> > > msa_networks set?
> >
> > I had a look at the code, and it looks like that particular message
> > with "but no longer internal" can only be be reached when a flag is
> > set that asserts that the message was submitted. This causes the
> > point at which trust would otherwise be broken to be treated as a
> > submission server.
>
> msa_networks is not set.
It wont make any difference if amavisd is overriding SA's normal
submission detection.
> What does "submission" mean in this context?
It's when a mail client submits outgoing mail to an mta. This should
involve some form of authentication
For some reason amavisd thinks that all of your mail is being
submitted locally. SA is finding that it's ALL_TRUSTED because amavisd
is telling SA that it is via the SA perl library interface.
Re: remaining relays will be considered trusted, but no longer internal
Posted by Helmut Schneider <ju...@gmx.de>.
RW wrote:
> On Fri, 15 Apr 2016 12:35:24 +0100
> RW wrote:
>
> > On Fri, 15 Apr 2016 10:10:13 +0000 (UTC)
> > Helmut Schneider wrote:
> >
> > > Hi,
> > >
> > > when further investigating my issue that ALL_TRUSTED is always
> > > true I came along the following lines when debugging SA:
> > >
> > > ...
> > > Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02)
> > > SA dbg: received-header: originating, 195.245.231.135 and
> > > remaining relays will be considered trusted, but no longer
> > > internal ...
> > >
> > > So SA correctly identifies an relay as external but still trusts
> > > the whole path. Why?
> >
> > It looks like it's being seen as mail submission. Do you have
> > msa_networks set?
>
> I had a look at the code, and it looks like that particular message
> with "but no longer internal" can only be be reached when a flag is
> set that asserts that the message was submitted. This causes the point
> at which trust would otherwise be broken to be treated as a submission
> server.
msa_networks is not set.
What does "submission" mean in this context?
Re: remaining relays will be considered trusted, but no longer
internal
Posted by RW <rw...@googlemail.com>.
On Fri, 15 Apr 2016 12:35:24 +0100
RW wrote:
> On Fri, 15 Apr 2016 10:10:13 +0000 (UTC)
> Helmut Schneider wrote:
>
> > Hi,
> >
> > when further investigating my issue that ALL_TRUSTED is always true
> > I came along the following lines when debugging SA:
> >
> > ...
> > Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> > dbg: received-header: originating, 195.245.231.135 and remaining
> > relays will be considered trusted, but no longer internal
> > ...
> >
> > So SA correctly identifies an relay as external but still trusts the
> > whole path. Why?
>
> It looks like it's being seen as mail submission. Do you have
> msa_networks set?
I had a look at the code, and it looks like that particular message
with "but no longer internal" can only be be reached when a flag is
set that asserts that the message was submitted. This causes the point
at which trust would otherwise be broken to be treated as a submission
server.
That flag is never set in any SpamAssassin code; it will have been
passed in from amavisd.
Re: remaining relays will be considered trusted, but no longer
internal
Posted by RW <rw...@googlemail.com>.
On Fri, 15 Apr 2016 10:10:13 +0000 (UTC)
Helmut Schneider wrote:
> Hi,
>
> when further investigating my issue that ALL_TRUSTED is always true I
> came along the following lines when debugging SA:
>
> ...
> Apr 15 11:44:43.213 mail /usr/sbin/amavisd-new[9991]: (09991-02) SA
> dbg: received-header: originating, 195.245.231.135 and remaining
> relays will be considered trusted, but no longer internal
> ...
>
> So SA correctly identifies an relay as external but still trusts the
> whole path. Why?
It looks like it's being seen as mail submission. Do you have
msa_networks set?
A server should only go in msa_networks if it's a pure submission server
that's outside the normal delivery path. If your MX server doubles as a
submission server, submission has to be detected by a trusted received
header recording authentication.