• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

10.4 upgrade - postfix adds multiple headers X-No-Auth: unauthenticated sender

BrewsterL

New Pleskian
A few weeks back upgraded from 10.3 to 10.4.4 and it broke something with postfix handling outbound messages from mailman. Posts to a list can get dozens of header lines with:

X-No-Auth: unauthenticated sender

They appear to be the last headers added (i.e. before them are the headers from the local MTA that received the message from my server)

I've been searching /reading up on postfix but so far I don't have a clue as to where to look. Anyone have any pointers or advice?

-----------------------------

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Linux 2.6.18-164.11.1.el5
10.4.4 Update #24, last updated at Mar 31, 2012 09:13 PM

Parallels Plesk Panel v10.4.4_build1013111102.18 os_CentOS 5
mailman 2.1.9-6.el5_6.1
postfix 2.8.4-11100518

PROBLEM DESCRIPTION
multiple "X-No-Auth: unauthenticated sender" headers added to outbound messages sent with mailman.

Does not seem to happen with other (non mailman) email.

mail logs look normal

ANY ADDITIONAL INFORMATION
The site uses a commercial anti-spam system (Precise Mail Anti Spam Gateway) that accepts the in bound port 25 connections and then forwards it to postfix on a different port. However this problem seems to be on the outbound side, regardless it worked before upgrading to 10.4.4 so something must have changed to break things.
 
Last edited:
Same Thing Here

We are seeing the same issue after loading a new server with 10.4.4. We are also using Mailman to manage a mailing list. Any news on what is happening with this one?
 
Smooth, I've just reproduced it on a 10.4.4 #MU24 server. Might be an artifact of changing in 10.4.4 the Postfix integration of Plesk filter from smtp proxy to milter. I'm not sure it's a bug yet, but it's definitely not right. The more members you add to the mailing list, the more headers are added.
I'll try to find some time to do a bit of research on this.

L.E. On the test server I have this:
# postconf smtpd_sender_restrictions
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re, check_sender_access hash:/var/spool/postfix/plesk/blacklists
# cat /var/spool/postfix/plesk/non_auth.re
/^/ PREPEND X-No-Auth: unauthenticated sender

Igor, any idea what's the reason for adding this custom header?
 
Last edited:
If you haven't fixed this already, here is the solution for anybody who has the same problem, as I found this hard to locate on the internet. It's actually pretty simple: this means that your mailing script did not authenticate to the SMTP server. 2 ways to fix this: either go to Tools & settings > Mail server settings and Uncheck the box that says: authorization is required for: SMTP.

Or just authenticate with an e-mail adres and password combination.

Cheers
 
We are still struggling with this issue and we have email that is not being delivered as a result. I went to Tools & Settings > Mail Server Settings and tried to remove the authorize smtp check mark. The only way we can turn this off is by making the server closed to relay -- this is not an option for us.

mailman is sending the email to a mailing list we have on the server. I'm not sure how to modify mailman to issue the smtp auth. It seems that local networks of the plesk server should not need to authenticate. Perhaps there is a postfix setting that is not correct? I have studied /etc/postfix/mail.cf and am concerned about making changes as I am sure plesk uses this file as we can see from burnleyvic post here.

Any help would be appreciated! Greg
 
It seems that there may be a configuration problem in /etc/postfix/main.cf. Mine contains the following line:

smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

Could it be that we need to add "permit_mynetworks" here? This might bypass auth checking for networks defined by "mynetworks". In my case, mynetworks includes 127.0.0.0/8 and the IP Address that is actually sending mail on my server.
 
Like some of the others, I can't shut off relay.

I found some other comments that indicated that since mailman doesn't perform SMTP authentication that was "the issue"; the fix was to make sure the local machine was allowed (which seems odd that it wouldn't be by default?). In my main.cf I uncommented:
mynetworks_style = host

I already have:
smtpd_recipient_restrictions = permit_mynetworks as the first thing.

Doing this caused normal email to have a large number of:
X-No-Relay: not in my network
headers added to each email.

I undid that change. I have to set this aside for a bit; For now I'm living with (well, all the hundreds of list users...) all the bogus X-No-Auth: unauthenticated sender headers but if anyone has other suggestions...
 
Workaround Available

There is an easy workaround to this problem until Parallels builds a complete solution. The /etc/postfix/main.cf file contains the following line:

smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

This point to the file /var/spool/postfix/plesk/non_auth.re file which contains the header that is appended to the mailman generated emails. This file contains:

/^/ PREPEND X-No-Auth: unauthenticated sender

The workaround is to backup the non_auth.re file and create a new file with the same name of zero length -- a Null file. Postfix will continue to append this file to the mailman generated email -- but now the appended headers will be Null. The end result is no additional headers will be added.

This has been running on our server for a few days now and it does not seem to have any negative side effects. It is having the positive effect of people and systems not complaining about the X-No-Auth headers.
 
ahh, yeah, thanks for reminding me about the 'obvious' fix. I'm all for anything that lets me hope that some future upgrade of Plesk will have a permanent fix...

Thanks
 
Just a heads up that 10.4.4 update #28 breaks the workaround (i.e. it puts back the original non_auth.re file). Since this results in all the headers again I guess the underlying problem isn't fixed yet (and for me the workaround is good enough).
 
Back
Top