You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Pedro David Marco <pe...@yahoo.com> on 2016/11/21 22:54:02 UTC
relay not detected
Hi,
i have spam emails with a Received line like this:
Received: by 9-30-239-23.uocdn.net (Postfix) with ESMTPSA id 693A0C56B with (unknown [158.69.130.12]) ; Sun, 20 Nov 2016 21:06:55 -0300
there is no parsing perl code for lines like this in Received.pm module so the relay 158.69.130.12 is never checked
is this normal?
---------
Pedro.
Re: relay not detected
Posted by RW <rw...@googlemail.com>.
On Tue, 22 Nov 2016 05:48:29 +0000 (UTC)
Pedro David Marco wrote:
> Thanks Bill,
> >. I don't know why some spammers do this sort of lame
> >Received fakery, since it fingerprints their mail as spam, but it
> >has been a fairly common practice for a long time.
> But SA did not trigger any rule about the forgering...
SA doesn't punish unknown formats. This one might allow for a useful
rule, but it depends on how often the same pattern is repeated.
> and debug mode does not show any message about unparseable lines. It
> seems just ignored,
It is ignored. SA doesn't even try to parse a relay that starts with
"by". It only logs a relay as unparseable if it fails to parse a
relay that might be useful.
This header does contain an IP address, but it's part of what the
header is claiming to be a protocol name.
> so the relay remains unchecked in RBLS.
It's worth bearing in mind that a received header logs the IP address
of the previous host, so the useful spammer IP address is recorded in
the first header that's *not* written by a spammer. Checking made-up
spammer headers does no harm, but it's not particularly important.
Actually, most RBLs are configured as "last-external" so they only use
the IP address recorded by your MX server.
Re: relay not detected
Posted by RW <rw...@googlemail.com>.
On Tue, 22 Nov 2016 12:18:14 -0500
Bill Cole wrote:
> On 22 Nov 2016, at 0:48, Pedro David Marco wrote:
>
> > Thanks Bill,
> >> . I don't know why some spammers do this sort of lame
> >> Received fakery, since it fingerprints their mail as spam, but it
> >> has been a fairly common practice for a long time.
> > But SA did not trigger any rule about the forgering...
>
> I'm surprised that it didn't trigger UNPARSEABLE_RELAY, but it is
> hard to know why based on one isolated header.
SA ignores headers like this:
Received: by 10.28.48.15 with SMTP id w15csp2319529wmw;
Tue, 22 Nov 2016 11:10:36 -0800 (PST)
because they don't affect anything. For a received header to count as
unparseable it has to have a "from".
> > and debug mode does not showany message about unparseable lines.
> > It seems just ignored, so the relay remains unchecked in RBLS.
>
> As it should. Untrusted relays are untrusted. There's no reason to
> believe ANYTHING in that header. The string in it that looks like an
> IP address might as well be 234.567.891.0.
It's fine to used untrusted IP addresses in positive scoring rules.
There's just not much advantage in trying to extract IP addresses from
all the possible variants of forged header.
Re: relay not detected
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 22 Nov 2016, at 0:48, Pedro David Marco wrote:
> Thanks Bill,
>> . I don't know why some spammers do this sort of lame�
>> Received fakery, since it fingerprints their mail as spam, but it has
>> been a fairly common practice for a long time.
> But SA did not trigger any rule about the forgering...
I'm surprised that it didn't trigger UNPARSEABLE_RELAY, but it is hard
to know why based on one isolated header.
> �and debug mode does not showany message about unparseable lines. It
> seems just ignored, so the relay remains unchecked in RBLS.
As it should. Untrusted relays are untrusted. There's no reason to
believe ANYTHING in that header. The string in it that looks like an IP
address might as well be 234.567.891.0.
Re: relay not detected
Posted by Pedro David Marco <pe...@yahoo.com>.
Thanks Bill,
>. I don't know why some spammers do this sort of lame
>Received fakery, since it fingerprints their mail as spam, but it has
>been a fairly common practice for a long time.
But SA did not trigger any rule about the forgering... and debug mode does not showany message about unparseable lines. It seems just ignored, so the relay remains unchecked in RBLS.
---------Pedro.
Re: relay not detected
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 21 Nov 2016, at 17:54, Pedro David Marco wrote:
> Hi,
> i have spam emails with a Received line like this:
> Received: by 9-30-239-23.uocdn.net (Postfix) with ESMTPSA id 693A0C56B
> with�(unknown [158.69.130.12]) ; Sun, 20 Nov 2016 21:06:55 -0300
> there is no parsing perl code for lines like this in Received.pm
> module so the relay 158.69.130.12 is never checked
> is this normal?�
Yes. Why would anyone want SA to attempt to parse an intentionally
deceptive Received header?
Unadulterated Postfix does not now generate (and never has generated)
Received headers like that. The queue id is too short and the header
would start with 'from' not 'by' if it was actually Postfix generating
it as claimed. That looks like some moron spammer tried to weld together
the 2-part mutant qmail Received format and label it as Postfix for
obfuscation. I don't know why some spammers do this sort of lame
Received fakery, since it fingerprints their mail as spam, but it has
been a fairly common practice for a long time.