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...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: spamassassin
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2015-06-30 01:06:45 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Apache Bugzilla 7077 0 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). 

Thanks.

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]

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

# score UNPARSEABLE_RELAY 0

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: 

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

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: 

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

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
yes

[root@mail-gw:~]$ rpm -qa | grep milter
spamass-milter-0.3.2-11.fc20.x86_64
clamav-milter-systemd-0.98.4-1.fc20.noarch
sendmail-milter-8.14.8-2.fc20.x86_64
clamav-milter-0.98.4-1.fc20.x86_64

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
http://www.gossamer-threads.com/lists/spamassassin/users/187118#187118

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...

clear_headers
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

[Service]
Type=simple
UMask=0022
Environment="TMPDIR=/tmp"
PermissionsStartOnly=true
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
Environment="LANG=en_GB.UTF-8"
User=sa-milt
Group=sa-milt
Nice=15
Restart=always
RestartSec=1
PrivateTmp=true
NoNewPrivileges=yes
CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib
ReadWriteDirectories=/var/lib/spamassassin
ReadWriteDirectories=/var/lib/spamass-milter

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
bug.

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.