Description of problem: After switching from Sendmail to Postfix, spamass-milter no longer detects SMTP AUTH authenticated mail as such. This causes SPF failures and false positives. Version-Release number of selected component (if applicable): spamass-milter-0.3.1-21.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. configure postfix, spamassassin with spamass-milter 2. receive an SMTP AUTH authenticated mail from an untrustworthy source 3. examine the received mail headers Actual results: IP-adress of untrustworthy source is examined by spamassassin Expected results: IP-adress of untrustworthy source is ignored Additional info: Having spamass-milter recognize authenticated messages should sufficient, but making sure by using the -I option does not work either Probable cause: spamass-milter relies on the sendmail {auth_ssf} macro which is not available in Postfix Suggested fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627989
The patch implementing AUTH support in Fedora uses the {auth_authen} macro, which according to http://www.postfix.org/MILTER_README.html is supported by Postfix. You could try running with the "-d misc" option to help debug what the milter is getting when asking Postfix for {auth_authen}.
Additional note: make sure you have {auth_authen} in milter_mail_macros.
That is the case by default. The only change I made was adding "_" to milter_connect_macros, in order to prevent UNPARSEBLE_RELAY reports milter_connect_macros = j {daemon_name} v {if_name} _ milter_data_macros = i milter_end_of_data_macros = i milter_end_of_header_macros = i milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer} milter_mail_macros = i {auth_type} {auth_authen} {auth_author} {mail_addr} {mail_host} {mail_mailer} milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer} milter_unknown_command_macros =
It now appears I was bit by another bug. Changes to to /etc/sysconfig/spamass-milter were not caught after restarting spamass-milter. I was testing the -I and the -d options on a non-production Fedora 15 box. I can now conclude that systemctl restart spamass-milter.service does not kill the old instance. The new instance cannot connect to the MTA. After manually restarting spamass-milter, the Fedora patch that provides the -I option does work as advertised. Still, I would prefer the proposed Debian patch, as it does not require a custom startup config and allows the mail to be processed by spamassassin rather than skipping that.
(In reply to comment #4) > It now appears I was bit by another bug. > Changes to to /etc/sysconfig/spamass-milter were not caught after restarting > spamass-milter. > > I was testing the -I and the -d options on a non-production Fedora 15 box. > I can now conclude that > > systemctl restart spamass-milter.service > > does not kill the old instance. The new instance cannot connect to the MTA. This is strange because the SysV initscript just does a stop and a start for "restart", which involves killing the old one and starting a new one. Can you reproduce this? > After manually restarting spamass-milter, the Fedora patch that provides the -I > option does work as advertised. > > Still, I would prefer the proposed Debian patch, as it does not require a > custom startup config and allows the mail to be processed by spamassassin > rather than skipping that. Looking at that patch, I feel it's complementary to what's already in, which already includes adding the "(authenticated bits={auth_ssf})" part of the Received: header if {auth_ssf} is present. It just needs tweaking to add "(authenticated)" if {auth_authen} is present but {auth_ssf} is not.
> This is strange because the SysV initscript just does a stop and a start for > "restart", which involves killing the old one and starting a new one. Can you > reproduce this? Every time. And there's a warning from systemd that might be related: systemd[1]: spamass-milter.service: Supervising process nnnn which is not our child. We'll most likely not notice when it exits. Typing stop and start instead of restart did work; maybe because of the typing delay. This was with spamass-milter-0.3.2-1.fc15.x86_64 which still had the wrapper script. Upgrading to spamass-milter-0.3.2-2.fc16.x86_64 from rawhide fixes that. I suppose I don't have to file this as a separate bug, as the solution is already there.
Can you give this scratch build a try: (f14) http://koji.fedoraproject.org/koji/taskinfo?taskID=3282480 (f15) http://koji.fedoraproject.org/koji/taskinfo?taskID=3282495 It adds "(authenticated)" to the dummy Received: header if {auth_authen} is present but {auth_ssf} is missing. I use sendmail myself and that's still working OK :-)
I tried the f15 version on an x86_64 non-production server. It works as advertised. I could switch off the -I switch; authenticated mail is now processed by spamassassin, but it is tagged ALL_TRUSTED like it did with sendmail. Thanks. I will try the f14 version later.
The f14 version fails on our x86_64 production server. Mail will be rejected. Syslog says "postfix/smtpd[12184]: warning: milter unix:/var/run/spamass-milter/postfix/sock: can't read SMFIC_MAIL reply packet header: Broken pipe"
(In reply to comment #9) > The f14 version fails on our x86_64 production server. > Mail will be rejected. > Syslog says "postfix/smtpd[12184]: warning: milter > unix:/var/run/spamass-milter/postfix/sock: can't read SMFIC_MAIL reply packet > header: Broken pipe" That doesn't look like something that would have changed as a result of the new patch; is the only thing changed the new milter? If you revert to the old one (which version exactly?), does it start working again? I trust you have the spamass-milter-postfix package installed too?
I was kind of very hasty to revert back when I noticed all mail was being rejected on this production server. I tried it again, this time restarted postfix as well. That did it. Somehow, other upgrades and downgrades did not require a postfix restart. Thanks
spamass-milter-0.3.2-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.fc16
spamass-milter-0.3.2-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.fc15
spamass-milter-0.3.2-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.fc14
spamass-milter-0.3.2-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.el6
spamass-milter-0.3.2-3.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.el5
spamass-milter-0.3.2-3.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.el4
Package spamass-milter-0.3.2-3.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spamass-milter-0.3.2-3.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/spamass-milter-0.3.2-3.fc14 then log in and leave karma (feedback).
spamass-milter-0.3.2-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.2-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.2-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.2-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.2-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.2-3.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.