You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2014/08/17 20:10:27 UTC

[Bug 7077] New: UNPARSEABLE_RELAY false positives

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

            Bug ID: 7077
           Summary: UNPARSEABLE_RELAY false positives
           Product: Spamassassin
           Version: 3.4.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Rules
          Assignee: dev@spamassassin.apache.org
          Reporter: kevin@scrye.com

Given the following email: 

Received: from testserver.rhsoft.net (testserver.vmware.local
[192.168.196.12])→(using TLSv1.2
→       with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))→(No client
certificate requested)
→       by srv-rhsoft.rhsoft.net (MTA) with ESMTPS id 3hX1hV2qLWzBqRl
→       for <rh...@test.rh>; Mon, 11 Aug 2014 17:44:58 +0200 (CEST)
Received: from rh.thelounge.net (unknown [91.118.73.99])→       (using TLSv1.2
→       with cipher ECDHE-RSA-AES256-SHA (256/256 bits))→       (No client
certificate requested)
→       by testserver.rhsoft.net (MTA) with ESMTPSA id 3hX1hT05Lmz29MX
→       for <rh...@test.rh>; Mon, 11 Aug 2014 17:44:56 +0200 (CEST)
Message-ID: <53...@testserver.rhsoft.net>
Date: Mon, 11 Aug 2014 17:44:56 +0200
From: "Reindl Harald (Testserver)" <te...@testserver.rhsoft.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.0
MIME-Version: 1.0
To: rhsoft@test.rh
Subject: Test

The UNPARSEABLE_RELAY rule is triggered. The relays should be valid, so perhaps
the test could be updated to handle this pretty common case?

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1128364

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7077] UNPARSEABLE_RELAY false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

Karsten Bräckelmann <gu...@rudersport.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Karsten Bräckelmann <gu...@rudersport.de> ---
(In reply to Kevin Fenzi from comment #0)
> The UNPARSEABLE_RELAY rule is triggered.

No, it is not.

> Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1128364

Running RH bug 1128364 attachment 925821 through spamassasin yields exactly one
rule triggered: ALL_TRUSTED

Moreover, grepping -D debug output for X-Spam-Relays-* metadata headers shows
both Received headers being parsed correctly.

Closing RESOLVED INVALID.

Probably a duplicate of bug 6103. This most likely is an issue with
spamass-milter generating a broken fake header, or missing milter macros.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665


Loosely related:

In the RH bug the reporter states "the spamass version should not be in the
headers by default".

This is just wrong. The X-Spam-Checker-Version header is always added and
cannot be removed by the remove_header or clear_headers options. The
M::SA::Conf docs clearly state this, explaining the reason.

The reporter's clear_headers and duplicated add_header configuration does not
work as intended, he still gets the Version header added.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2014-08-26 at 09:07 -0600, Kevin Fenzi wrote:
> On Fri, 22 Aug 2014 20:53:08 +0200
> Karsten Bräckelmann <gu...@rudersport.de> wrote:

> > Does the reporter lack the milter connect macro?
> 
> I wouldn't think so, or it wouldn't have ever gone to spamassassin. 

Yes, it would. I am talking about the milter_connect_macros setting
mentioned as required in Debian bug 510665 [1]. Debian bug 609647 [2] is
another hint that it "works" without that setting, but still triggers
UNPARSEABLE_RELAY.

> I've asked them for more details. 

And in comment 11 on the RH bug, the reporter shows he has that setting.


In that same comment, he links to a recent thread on the SA users@
mailing list, solving his issue of missing header rewrite, which
actually turned out to be missing any options due to file ownership.

In that thread's original post his SA conf shows he has disabled
UNPARSEABLE_RELAY by zeroing out its score. If he still has that
setting, he is unable to tell whether this issue actually still exists,
or some fixing of his broken environment fixed it since.

I'd ask him to comment out that score 0 overriding, re-activating the
rule and see if he still can reproduce the issue.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609647

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
Re-post, sorry for the noise. Forgot to add Kevin to the recipients.


On Tue, 2014-08-26 at 09:07 -0600, Kevin Fenzi wrote:
> On Fri, 22 Aug 2014 20:53:08 +0200
> Karsten Bräckelmann <gu...@rudersport.de> wrote:

> > Does the reporter lack the milter connect macro?
> 
> I wouldn't think so, or it wouldn't have ever gone to spamassassin. 

Yes, it would. I am talking about the milter_connect_macros setting
mentioned as required in Debian bug 510665 [1]. Debian bug 609647 [2] is
another hint that it "works" without that setting, but still triggers
UNPARSEABLE_RELAY.

> I've asked them for more details. 

And in comment 11 on the RH bug, the reporter shows he has that setting.


In that same comment, he links to a recent thread on the SA users@
mailing list, solving his issue of missing header rewrite, which
actually turned out to be missing any options due to file ownership.

In that thread's original post his SA conf shows he has disabled
UNPARSEABLE_RELAY by zeroing out its score. If he still has that
setting, he is unable to tell whether this issue actually still exists,
or some fixing of his broken environment fixed it since.

I'd ask him to comment out that score 0 overriding, re-activating the
rule and see if he still can reproduce the issue.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609647

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Kevin Fenzi <ke...@scrye.com>.
On Fri, 22 Aug 2014 20:53:08 +0200
Karsten Bräckelmann <gu...@rudersport.de> wrote:

...snip...

> > > The following 5 year old Debian bug report (which I provided)
> > > also is RH #496763, or patch3 in the RH src rpm. No need to move
> > > Component, it's already been patched.
> > 
> > But yet, they still see the issue? So, something further is going
> > on?
> 
> Does the reporter lack the milter connect macro?

I wouldn't think so, or it wouldn't have ever gone to spamassassin. 

I've asked them for more details. 

Thanks. 

kevin



Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2014-08-22 at 08:42 -0600, Kevin Fenzi wrote:
> On Fri, 22 Aug 2014 04:10:31 +0200
> Karsten Bräckelmann <gu...@rudersport.de> wrote:
> 
> > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077
> > 
> > Kevin, some comments on this issue. Off-bugzilla, since it really
> > doesn't belong to the SA bugzilla, and I don't feel like creating a RH
> > bugzilla account just to comment. I will moderate accept your replies
> > to the SA dev@ list, in case you are not subscribed.
> 
> ok. 
> 
> > First of all: Unparseable Relay FP hits with spamass-milter is old
> > news. The referenced Debian bug is from 2009. This has been mentioned
> > on SA lists a few times, and google has plenty of relevant results if
> > the milter bit is included.
> 
> I've never used it, so I guess I will have to read up when I have
> time to do so. Note that maintaining spamassassin for Fedora is
> something I do because I use it and the previous maintainer is gone
> now. It's in no way something I have vast amounts of time for. 

Volunteer work. I hear you.


> > RH bug 1128364 comment 6:
> > > Upstream has closed this as they were not able to duplicate it. :( 
> > 
> > The reporter Harald Reindl didn't reproduce the issue with SA
> > (alone!), but merely reported he always gets that rule hit with
> > spamass-milter. Frankly, despite providing a sample, you didn't try
> > to reproduce the issue either before reporting upstream.
> 
> Sorry. I'll try and be better about duplicating things before filing
> upstream. sorry if you feel I wasted your time. 

Don't worry.

I was just surprised to see a bug being filed upstream without actually
verifying the issue. So I had to. ;)


> > RH bug 1128364 comment 8:
> > > The place to fix this seems spamass-milter: 
> > 
> > The following 5 year old Debian bug report (which I provided) also is
> > RH #496763, or patch3 in the RH src rpm. No need to move Component,
> > it's already been patched.
> 
> But yet, they still see the issue? So, something further is going on?

Does the reporter lack the milter connect macro?


> > Which kind of leaves me with the necessary milter connect macros. Or,
> > failing that, any evidence of reproducibility in any environment
> > clearly specified by the reporter.
> 
> Alright. I will look into spamass-milter as time permits. 
> 
> If you (or anyone else) wants the reporter to provide more info or try
> anything, feel free to post it to the bug. 


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Kevin Fenzi <ke...@scrye.com>.
On Fri, 22 Aug 2014 04:10:31 +0200
Karsten Bräckelmann <gu...@rudersport.de> wrote:

> > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077
> 
> Kevin, some comments on this issue. Off-bugzilla, since it really
> doesn't belong to the SA bugzilla, and I don't feel like creating a RH
> bugzilla account just to comment. I will moderate accept your replies
> to the SA dev@ list, in case you are not subscribed.

ok. 

> First of all: Unparseable Relay FP hits with spamass-milter is old
> news. The referenced Debian bug is from 2009. This has been mentioned
> on SA lists a few times, and google has plenty of relevant results if
> the milter bit is included.

I've never used it, so I guess I will have to read up when I have
time to do so. Note that maintaining spamassassin for Fedora is
something I do because I use it and the previous maintainer is gone
now. It's in no way something I have vast amounts of time for. 

> RH bug 1128364 comment 6:
> > Upstream has closed this as they were not able to duplicate it. :( 
> 
> The reporter Harald Reindl didn't reproduce the issue with SA
> (alone!), but merely reported he always gets that rule hit with
> spamass-milter. Frankly, despite providing a sample, you didn't try
> to reproduce the issue either before reporting upstream.

Sorry. I'll try and be better about duplicating things before filing
upstream. sorry if you feel I wasted your time. 
 
> RH bug 1128364 comment 8:
> > The place to fix this seems spamass-milter: 
> 
> The following 5 year old Debian bug report (which I provided) also is
> RH #496763, or patch3 in the RH src rpm. No need to move Component,
> it's already been patched.

But yet, they still see the issue? So, something further is going on?

> Which kind of leaves me with the necessary milter connect macros. Or,
> failing that, any evidence of reproducibility in any environment
> clearly specified by the reporter.

Alright. I will look into spamass-milter as time permits. 

If you (or anyone else) wants the reporter to provide more info or try
anything, feel free to post it to the bug. 

kevin

Re: [Bug 7077] UNPARSEABLE_RELAY false positives

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

Kevin, some comments on this issue. Off-bugzilla, since it really
doesn't belong to the SA bugzilla, and I don't feel like creating a RH
bugzilla account just to comment. I will moderate accept your replies to
the SA dev@ list, in case you are not subscribed.


First of all: Unparseable Relay FP hits with spamass-milter is old news.
The referenced Debian bug is from 2009. This has been mentioned on SA
lists a few times, and google has plenty of relevant results if the
milter bit is included.

RH bug 1128364 comment 6:
> Upstream has closed this as they were not able to duplicate it. :( 

The reporter Harald Reindl didn't reproduce the issue with SA (alone!),
but merely reported he always gets that rule hit with spamass-milter.
Frankly, despite providing a sample, you didn't try to reproduce the
issue either before reporting upstream.

RH bug 1128364 comment 8:
> The place to fix this seems spamass-milter: 

The following 5 year old Debian bug report (which I provided) also is RH
#496763, or patch3 in the RH src rpm. No need to move Component, it's
already been patched.


Which kind of leaves me with the necessary milter connect macros. Or,
failing that, any evidence of reproducibility in any environment clearly
specified by the reporter.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


[Bug 7077] UNPARSEABLE_RELAY false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

Kevin Fenzi <ke...@scrye.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevin@scrye.com

--- Comment #4 from Kevin Fenzi <ke...@scrye.com> ---
Yes, I am aware.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7077] UNPARSEABLE_RELAY false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

--- Comment #3 from Karsten Bräckelmann <gu...@rudersport.de> ---
> Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1128364

Kevin, just a reminder to close that RH bug. It still is open and assigned to
you.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7077] UNPARSEABLE_RELAY false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7077

--- Comment #1 from AXB <ax...@gmail.com> ---
FTR: 
score UNPARSEABLE_RELAY 0.001

-- 
You are receiving this mail because:
You are the assignee for the bug.