You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by mark <ma...@incet.com> on 2009/04/27 13:24:27 UTC
sa with spamass-milter UNPARSEABLE_RELAY problem
Hey,
I am trying to track down an issue on Centos 5 x86_64 with
spamass-milter-0.3.2-1 and spamassassin-3.2.5.
Nearly all the emails are received with UNPARSEABLE_RELAY - but if I
take the email as delivered by the MDA and run it with spamassassin -t
-D < spam.eml then its correctly detected as spam and no sign of
UNPARSEABLE_RELAY.
I have created case 6103 - but this may be a milter-issue, although the
same version of the milter worked very well on centos-4 i386 and SA 3.1
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
thanks in advance
mark
Re: sa with spamass-milter UNPARSEABLE_RELAY problem - fixed
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Fri, 1 May 2009, mark wrote:
> Just posting this for others who may encounter this:-
>
> This turned out to be an interaction between milter-greylist and
> spamass-milter. In sendmail.mc the following grey list config was included
> as part of the greylist setup:-
>
> define(`confMILTER_MACROS_ENVRCPT', `{greylist}')dnl
>
> however for the spamass-milter to work properly the following needs to be
> set:
>
> define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, b, _')dnl
>
> and I commented out: dnl define(`confMILTER_MACROS_ENVRCPT', `{greylist}')dnl
[snip..]
Mark,
When configuring multiple milters in a sendmail instance, make that
"confMILTER_MACROS_ENVRCPT" macro contain the union of all the attributes
that the various milters want. That sets the list of variables that are
offered to each milter instance. A given milter does not have to look at
all the variables offered but it cannot 'see' any that are not offered.
So when in doubt give it more than it needs.
EG for your instance, set that confMILTER_MACROS_ENVRCPT to be:
define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, b, _, {greylist}')dnl
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: sa with spamass-milter UNPARSEABLE_RELAY problem - fixed
Posted by mark <ma...@incet.com>.
>> I have created case 6103 - but this may be a milter-issue, although
>> the same version of the milter worked very well on centos-4 i386 and
>> SA 3.1
>>
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
>>
>> thanks in advance
>> mark
>>
>>
> This is a spamass-milter bug. They generate a malformed fake sendmail
> header and it's unparseable.
>
> There's a fix for spamass-milter in the debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
>
Just posting this for others who may encounter this:-
This turned out to be an interaction between milter-greylist and
spamass-milter. In sendmail.mc the following grey list config was
included as part of the greylist setup:-
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')dnl
however for the spamass-milter to work properly the following needs to
be set:
define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, b, _')dnl
and I commented out: dnl define(`confMILTER_MACROS_ENVRCPT',
`{greylist}')dnl
setting the following for the spamass-milter:
EXTRA_FLAGS="-m -r 5"
rejects mail that scores over 5 without delivery. This is particularly
useful when the box forwards mails via virtusertble / /etc/aliases
example:
May 1 16:06:50 host spamd[15382]: spamd: result: Y 5 -
DYN_RDNS_AND_INLINE_IMAGE,FH_HELO_EQ_D_D_D_D,RCVD_IN_PBL,RCVD_IN_XBL,RDNS_DYNAMIC
May 1 16:06:50 host sendmail[15382]: n4146fZ6015382:
to=<em...@domain.org>, delay=00:00:08, pri=31489, stat=Blocked by
SpamAssassin
System: Centos 5.3 + std sendmail, spamass-milter-0.3.1 - with fixes in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
and spamassassin-3.2.5-1.el5
milter-greylist-3.0-2.el5.rf
Re: sa with spamass-milter UNPARSEABLE_RELAY problem
Posted by Matt Kettler <mk...@verizon.net>.
mark wrote:
>>
> Thanks for this, the bug issue had some more info, which I had not
> included in my email:
>
> > I have recompiled spamass-milter with this patch:-
>
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
>
> However, this has not resolved the issue, can you tell me if SA can
> output the headers as received from spamass-milter so I can compare
> with the headers generated by sendmail?
>
> thanks
> Mark.
>
You could start spamd with the -D (note: capital D) to put it into debug
mode. This would cause quite verbose logging at the debug level. That
logging should include the Received: headers, and how SA parses them.
Look for "dbg: received-header: unknown format:" in the debug output.
I wouldn't want to run this way normally, as the log output is going to
be around 100 lines per message, but for a short while it should be fine.
Re: sa with spamass-milter UNPARSEABLE_RELAY problem
Posted by mark <ma...@incet.com>.
>> Nearly all the emails are received with UNPARSEABLE_RELAY - but if I
>> take the email as delivered by the MDA and run it with spamassassin -t
>> -D < spam.eml then its correctly detected as spam and no sign of
>> UNPARSEABLE_RELAY.
>>
>> I have created case 6103 - but this may be a milter-issue, although
>> the same version of the milter worked very well on centos-4 i386 and
>> SA 3.1
>>
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
>>
>> thanks in advance
>> mark
>>
>>
> This is a spamass-milter bug. They generate a malformed fake sendmail
> header and it's unparseable.
>
> There's a fix for spamass-milter in the debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
>
Thanks for this, the bug issue had some more info, which I had not
included in my email:
> I have recompiled spamass-milter with this patch:-
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
However, this has not resolved the issue, can you tell me if SA can
output the headers as received from spamass-milter so I can compare with
the headers generated by sendmail?
thanks
Mark.
Re: sa with spamass-milter UNPARSEABLE_RELAY problem
Posted by Matt Kettler <mk...@verizon.net>.
mark wrote:
> Hey,
>
> I am trying to track down an issue on Centos 5 x86_64 with
> spamass-milter-0.3.2-1 and spamassassin-3.2.5.
>
> Nearly all the emails are received with UNPARSEABLE_RELAY - but if I
> take the email as delivered by the MDA and run it with spamassassin -t
> -D < spam.eml then its correctly detected as spam and no sign of
> UNPARSEABLE_RELAY.
>
> I have created case 6103 - but this may be a milter-issue, although
> the same version of the milter worked very well on centos-4 i386 and
> SA 3.1
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
>
> thanks in advance
> mark
>
This is a spamass-milter bug. They generate a malformed fake sendmail
header and it's unparseable.
There's a fix for spamass-milter in the debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510665
Re: sa with spamass-milter UNPARSEABLE_RELAY problem
Posted by Robert Schetterer <ro...@schetterer.org>.
mark schrieb:
> Hey,
>
> I am trying to track down an issue on Centos 5 x86_64 with
> spamass-milter-0.3.2-1 and spamassassin-3.2.5.
>
> Nearly all the emails are received with UNPARSEABLE_RELAY - but if I
> take the email as delivered by the MDA and run it with spamassassin -t
> -D < spam.eml then its correctly detected as spam and no sign of
> UNPARSEABLE_RELAY.
>
> I have created case 6103 - but this may be a milter-issue, although the
> same version of the milter worked very well on centos-4 i386 and SA 3.1
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
>
> thanks in advance
> mark
http://wiki.apache.org/spamassassin/Rules/UNPARSEABLE_RELAY
Rules/UNPARSEABLE RELAY
SpamAssassin Rule: UNPARSEABLE_RELAY
Standard description: Informational: message has unparseable relay lines
Explanation
The Received: lines from the email are analyzed to determine the relay
path. This rule matches mail that contains one or more Received: lines
that cannot be parsed to extract this information.
Note that this is an "informational" rule -- in other words, it is not
intended to differentiate spam from nonspam, and should not have a
significant score.
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria