You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by hg user <me...@gmail.com> on 2019/12/09 08:10:25 UTC
__UNPARSEABLE_RELAY_COUNT: which one?
Investigating why a message scored X when arrived and Y now (recovered from
user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all
messages recovered from user inbox.
In almost all cases this is not a problem, except for XPRIO_SHORT_SUBJ: it
fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
Thanks
Francesco
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by RW <rw...@googlemail.com>.
On Mon, 9 Dec 2019 10:05:47 +0100
hg user wrote:
> Yes, I'm still at 3.4.1... can't update now.
>
I wouldn't bother, an unparseable relay only really matters if it's on
the edge of the trusted or internal network - mainly the internal. If
SA can't parse your own MTA's header all kinds of things are broken,
but an internal realy is mostly harmless.
IMO the parsing shouldn't count any header that has "\bwith LMTP\b" as
an unparseable relay.
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by Henrik K <he...@hege.li>.
If it starts bothers you, simply patch the small change..
https://svn.apache.org/viewvc/spamassassin/branches/3.4/lib/Mail/SpamAssassin/Message/Metadata/Received.pm?r1=1686458&r2=1686457&pathrev=1686458&view=patch
On Mon, Dec 09, 2019 at 10:05:47AM +0100, hg user wrote:
> Yes, I'm still at 3.4.1... can't update now.
>
> Thank you
> Francesco
>
>
>
> On Mon, Dec 9, 2019 at 9:55 AM Henrik K <[1...@hege.li> wrote:
>
>
> I guess you are using old SA version, it was fixed in 3.4.2
>
> # Received: from [2]mail-backend.DDDD.com (LHLO [3]
> mail-backend.DDDD.com) (10.2.2.20) by [4]mail-backend.DDDD.com with LMTP;
> Thu, 18 Jun 2015 16:50:56 -0700 (PDT)
> if (/^(\S+) \(LHLO (\S*)\) \((${IP_ADDRESS})\) by (\S+) with LMTP/) {
> $rdns = $1; $helo = $2; $ip = $3; $by = $4; goto enough;
> }
>
>
> On Mon, Dec 09, 2019 at 09:33:39AM +0100, hg user wrote:
> > Here the line, redacted:
> > Dec 9 09:30:36.700 [10600] dbg: received-header: unparseable: from
> > [5]host4.domain.it (LHLO [6]host4.domain.it) (1.1.1.1) by [7]
> host3.domain.it with
> > LMTP; Tue, 3 Dec 2019 11:55:44 +0100 (CET)
> >
> > Thank you
> > Francesco
> >
> > On Mon, Dec 9, 2019 at 9:22 AM Henrik K <[8...@hege.li> wrote:
> >
> > > On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> > > > Investigating why a message scored X when arrived and Y now
> (recovered
> > > from
> > > > user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on
> all
> > > messages
> > > > recovered from user inbox.
> > > > In almost all cases this is not a problem, except for
> XPRIO_SHORT_SUBJ:
> > > it
> > > > fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
> > > >
> > > > How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
> > >
> > > Use debugging
> > >
> > > spamassassin -t -D -L < message | grep unparseable:
> > >
> > > Show the output here if you can, it might need to be added in SA code.
>
>
> References:
>
> [1] mailto:hege@hege.li
> [2] http://mail-backend.dddd.com/
> [3] http://mail-backend.dddd.com/
> [4] http://mail-backend.dddd.com/
> [5] http://host4.domain.it/
> [6] http://host4.domain.it/
> [7] http://host3.domain.it/
> [8] mailto:hege@hege.li
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by hg user <me...@gmail.com>.
Yes, I'm still at 3.4.1... can't update now.
Thank you
Francesco
On Mon, Dec 9, 2019 at 9:55 AM Henrik K <he...@hege.li> wrote:
>
> I guess you are using old SA version, it was fixed in 3.4.2
>
> # Received: from mail-backend.DDDD.com (LHLO mail-backend.DDDD.com)
> (10.2.2.20) by mail-backend.DDDD.com with LMTP; Thu, 18 Jun 2015 16:50:56
> -0700 (PDT)
> if (/^(\S+) \(LHLO (\S*)\) \((${IP_ADDRESS})\) by (\S+) with LMTP/) {
> $rdns = $1; $helo = $2; $ip = $3; $by = $4; goto enough;
> }
>
>
> On Mon, Dec 09, 2019 at 09:33:39AM +0100, hg user wrote:
> > Here the line, redacted:
> > Dec 9 09:30:36.700 [10600] dbg: received-header: unparseable: from
> > host4.domain.it (LHLO host4.domain.it) (1.1.1.1) by host3.domain.it with
> > LMTP; Tue, 3 Dec 2019 11:55:44 +0100 (CET)
> >
> > Thank you
> > Francesco
> >
> > On Mon, Dec 9, 2019 at 9:22 AM Henrik K <he...@hege.li> wrote:
> >
> > > On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> > > > Investigating why a message scored X when arrived and Y now
> (recovered
> > > from
> > > > user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on
> all
> > > messages
> > > > recovered from user inbox.
> > > > In almost all cases this is not a problem, except for
> XPRIO_SHORT_SUBJ:
> > > it
> > > > fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
> > > >
> > > > How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
> > >
> > > Use debugging
> > >
> > > spamassassin -t -D -L < message | grep unparseable:
> > >
> > > Show the output here if you can, it might need to be added in SA code.
>
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by Henrik K <he...@hege.li>.
I guess you are using old SA version, it was fixed in 3.4.2
# Received: from mail-backend.DDDD.com (LHLO mail-backend.DDDD.com) (10.2.2.20) by mail-backend.DDDD.com with LMTP; Thu, 18 Jun 2015 16:50:56 -0700 (PDT)
if (/^(\S+) \(LHLO (\S*)\) \((${IP_ADDRESS})\) by (\S+) with LMTP/) {
$rdns = $1; $helo = $2; $ip = $3; $by = $4; goto enough;
}
On Mon, Dec 09, 2019 at 09:33:39AM +0100, hg user wrote:
> Here the line, redacted:
> Dec 9 09:30:36.700 [10600] dbg: received-header: unparseable: from
> host4.domain.it (LHLO host4.domain.it) (1.1.1.1) by host3.domain.it with
> LMTP; Tue, 3 Dec 2019 11:55:44 +0100 (CET)
>
> Thank you
> Francesco
>
> On Mon, Dec 9, 2019 at 9:22 AM Henrik K <he...@hege.li> wrote:
>
> > On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> > > Investigating why a message scored X when arrived and Y now (recovered
> > from
> > > user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all
> > messages
> > > recovered from user inbox.
> > > In almost all cases this is not a problem, except for XPRIO_SHORT_SUBJ:
> > it
> > > fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
> > >
> > > How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
> >
> > Use debugging
> >
> > spamassassin -t -D -L < message | grep unparseable:
> >
> > Show the output here if you can, it might need to be added in SA code.
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by hg user <me...@gmail.com>.
Here the line, redacted:
Dec 9 09:30:36.700 [10600] dbg: received-header: unparseable: from
host4.domain.it (LHLO host4.domain.it) (1.1.1.1) by host3.domain.it with
LMTP; Tue, 3 Dec 2019 11:55:44 +0100 (CET)
Thank you
Francesco
On Mon, Dec 9, 2019 at 9:22 AM Henrik K <he...@hege.li> wrote:
> On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> > Investigating why a message scored X when arrived and Y now (recovered
> from
> > user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all
> messages
> > recovered from user inbox.
> > In almost all cases this is not a problem, except for XPRIO_SHORT_SUBJ:
> it
> > fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
> >
> > How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
>
> Use debugging
>
> spamassassin -t -D -L < message | grep unparseable:
>
> Show the output here if you can, it might need to be added in SA code.
>
>
Re: __UNPARSEABLE_RELAY_COUNT: which one?
Posted by Henrik K <he...@hege.li>.
On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> Investigating why a message scored X when arrived and Y now (recovered from
> user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all messages
> recovered from user inbox.
> In almost all cases this is not a problem, except for XPRIO_SHORT_SUBJ: it
> fired on X and didn't fire on Y due to UNPARSEABLE_RELAY_COUNT...
>
> How can I understand why UNPARSEABLE_RELAY_COUNT rule fires?
Use debugging
spamassassin -t -D -L < message | grep unparseable:
Show the output here if you can, it might need to be added in SA code.