Bug 1128364 - every message -> 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
Summary: every message -> 0.0 UNPARSEABLE_RELAY Informational: message has unparseable...
Alias: None
Product: Fedora
Classification: Fedora
Component: spamassassin
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-09 14:28 UTC by Harald Reindl
Modified: 2015-06-30 01:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-30 01:06:45 UTC

Attachments (Terms of Use)
test message (1.14 KB, message/rfc822)
2014-08-11 15:48 UTC, Harald Reindl
no flags Details

System ID Priority Status Summary Last Updated
Apache Bugzilla 7077 None None None Never

Description Harald Reindl 2014-08-09 14:28:00 UTC
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines

nobody can explain me that *every* message going to spamass-milter
has unparseble relay lines wheter it is sent with Thunderbird
or a webform

frankly messages directly submitted through port 587 and 
authentication have no relay lines at all nor are relay
lines mandatory

Comment 1 Kevin Fenzi 2014-08-11 15:32:46 UTC
Can you possibly provide headers from a message where you are seeing this?

(with hostnames and ip's changed if you like). 


Comment 2 Harald Reindl 2014-08-11 15:48:16 UTC
Created attachment 925821 [details]
test message

complete test message attached

uncommented the config line to disable that and BTW 
the spamass version should not be in the headers by 
default, hence the "add_header"

[root@testserver:~]$ cat /etc/mail/spamassassin/local.cf
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_


Comment 3 Kevin Fenzi 2014-08-17 18:01:13 UTC
Do you mind if I share this test message with upstream? 

There's definitely a bug here in parsing the relay's.

Comment 4 Harald Reindl 2014-08-17 18:03:27 UTC
no problem - that's why i attached it

in general i disabled that warning here but be glad if others looking careful at headers and outputs don't have that issue in the future

Comment 5 Kevin Fenzi 2014-08-17 18:11:28 UTC
Filed upstream as: 


Comment 6 Kevin Fenzi 2014-08-21 21:37:36 UTC
Upstream has closed this as they were not able to duplicate it. :( 

They suggested that this could be a spamass-milter problem?

Are you using spamass-milter?

Comment 7 Harald Reindl 2014-08-21 21:45:00 UTC
surely, milter is mandatory because you must reject or deliver messages required by law - however "score UNPARSEABLE_RELAY 0" disables that notice

i thought it's worth to report and help to realize/solve bugs 
instead dig them with a site specific override

Comment 8 Kevin Fenzi 2014-08-21 21:50:02 UTC
The place to fix this seems spamass-milter: 


Are you using the Fedora spamass-milter? Shall we reassign this over there or file a new bug on it?

Comment 9 Harald Reindl 2014-08-21 21:54:06 UTC

[root@mail-gw:~]$ rpm -qa | grep milter

Comment 10 Kevin Fenzi 2014-08-26 15:06:34 UTC
ok, so spamass-milter in Fedora has that patch mentioned above for a long time now. 

Can you share how you are adding spamass-milter into your sendmail.mc?

Comment 11 Harald Reindl 2014-08-26 15:27:24 UTC
postfix - no sendmail for me :-)

smtpd_milters = unix:/run/clamav-milter/clamav-milter.socket, unix:/run/spamass-milter/spamass-milter.sock
milter_connect_macros = j {daemon_name} v {if_name} _

i also fight with the [SPAM] adding to subjects and maybe the
wrong permissions after sa-update are a look worth

Comment 12 Kevin Fenzi 2014-08-26 16:15:30 UTC
Can you also show your /etc/sysconfig/spamass-milter file? 

Are you/should you be using -I or -i ?

Also, have you considered using a postfix content filter instead of a milter? :)

Comment 13 Harald Reindl 2014-08-27 08:56:08 UTC
i found the reason for the not tagging
"add_header spam Flag _YESNO_" is needed also
who comes to the idea look in his own headers to decide subjet change...

add_header spam Flag _YESNO_
add_header all Status _YESNO_, score=_SCORE_/_REQD_, tests=_TESTS_

> Are you/should you be using -I or -i?

nope, inbound only

> postfix content filter instead of a milter?

no, built up webinterfaces and what not else for postfix/clamav/spamassasin in the last two weeks from scratch and i am at "well it's done, let us put my private domain live"

> Can you also show your /etc/sysconfig/spamass-milter file? 

[root@mail-gw:~]$ cat /etc/sysconfig/spamass-milter 
# all connfiguration moved to systemd-unit template 
# /scripts/spamfilter/templates/spamass-milter.service

ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type d -exec /bin/chmod 0755 "{}" \;
ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type f -exec /bin/chmod 0644 "{}" \;
ExecStart=/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r [required_hits_reject] -- -s [max_msg_size] --port=10027

Comment 14 Fedora End Of Life 2015-05-29 12:35:35 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Fedora End Of Life 2015-06-30 01:06:45 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.