Hi Everyone,
My CentOS 4.4 mail server is having problems sending mail after updating it to 4.4 Before the update, I did not have any problems.
My ISP requires that email clients must authenticate to their mail servers before mail can be sent out. I setup smtp auth to get postfix to relay mail through the ISP's mail servers. Here's my config:
main.cf -------- relayhost = [smtp.broadband.rogers.com] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options =
sasl_passwd --------------- smtp.broadband.rogers.com blah@blah.com:password
I've done the usual run through of config files after an update, and made some small changes to main.cf (just added in comments and examples that were in main.cf.rpmnew). When I try to send a message, this is the error I get:
F060D1C068: to=m3freak@rogers.com, relay=smtp-rog.mail.yahoo2.akadns.net[206.190.36.18], delay=1, status=bounced (host smtp-rog.mail.yahoo2.akadns.net[206.190.36.18] said: 530 authentication required - for help go to http://help.yahoo.com/help/us/mail/pop/pop-11.html (in reply to MAIL FROM command))
Just in case the ISP had done something, I manually tested authenticating to the ISP's mail server, and it worked just fine:
Connected to smtp.broadband.rogers.com (206.190.36.18). Escape character is '^]'. 220 smtp105.rog.mail.re2.yahoo.com ESMTP ehlo krs 250-smtp105.rog.mail.re2.yahoo.com 250-AUTH LOGIN PLAIN XYMCOOKIE 250-PIPELINING 250 8BITMIME AUTH PLAIN blahblahblahblahblahblahblahblahblah 235 ok, go ahead (#2.0.0)
So, the problem is on the Postfix end. I must assume something in the Postfix update broke my setup, but I can't figure out what it is. Has anyone else run into this? Am I missing something obvious?
Hints appreciated.
Regards,
Ranbir
I use postfix in a multiple MailScanner systems. One thing I found is that the postfix update reset the rights on the /var/spool/postfix directory and subdirectories from postfix.root and postfix.postdrop to root.root. I would receive mail all day long but they just sat in the queue and didn't go anywhere. Not sure if this is your problem but would be worth a look.
Chris
Kanwar Ranbir Sandhu m3freak@rogers.com 08/31/06 4:23 PM >>>
Hi Everyone,
My CentOS 4.4 mail server is having problems sending mail after updating it to 4.4 Before the update, I did not have any problems.
My ISP requires that email clients must authenticate to their mail servers before mail can be sent out. I setup smtp auth to get postfix to relay mail through the ISP's mail servers. Here's my config:
main.cf -------- relayhost = [smtp.broadband.rogers.com] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options =
sasl_passwd --------------- smtp.broadband.rogers.com blah@blah.com:password
I've done the usual run through of config files after an update, and made some small changes to main.cf (just added in comments and examples that were in main.cf.rpmnew). When I try to send a message, this is the error I get:
F060D1C068: to=m3freak@rogers.com, relay=smtp- rog.mail.yahoo2.akadns.net[206.190.36.18], delay=1, status=bounced (host smtp- rog.mail.yahoo2.akadns.net[206.190.36.18] said: 530 authentication required - for help go to http://help.yahoo.com/help/us/mail/pop/pop- 11.html (in reply to MAIL FROM command))
Just in case the ISP had done something, I manually tested authenticating to the ISP's mail server, and it worked just fine:
Connected to smtp.broadband.rogers.com (206.190.36.18). Escape character is '^]'. 220 smtp105.rog.mail.re2.yahoo.com ESMTP ehlo krs 250- smtp105.rog.mail.re2.yahoo.com 250- AUTH LOGIN PLAIN XYMCOOKIE 250- PIPELINING 250 8BITMIME AUTH PLAIN blahblahblahblahblahblahblahblahblah 235 ok, go ahead (#2.0.0)
So, the problem is on the Postfix end. I must assume something in the Postfix update broke my setup, but I can't figure out what it is. Has anyone else run into this? Am I missing something obvious?
Hints appreciated.
Regards,
Ranbir
-- Kanwar Ranbir Sandhu Linux 2.6.17- 1.2142_FC4 i686 GNU/Linux 16:11:07 up 2 days, 9:40, 3 users, load average: 1.06, 0.75, 0.62
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, 2006-31-08 at 16:29 -0400, Chris Hammond wrote:
I use postfix in a multiple MailScanner systems. One thing I found is that the postfix update reset the rights on the /var/spool/postfix directory and subdirectories from postfix.root and postfix.postdrop to root.root. I would receive mail all day long but they just sat in the queue and didn't go anywhere. Not sure if this is your problem but would be worth a look.
That's plausible. And in fact, I do see a number of dirs with owner:group set to root:root under /var/spool/postfix.
But, I have no idea what the permissions should be. How did you figure it out?
BTW, I'm running postfix in a chroot, though I'm not sure why that would break it now when it didn't in the past (there are no errors when postfix is started).
Regards,
Ranbir
Do you get any errors when starting postfix? I received errors about the directories not being writable by postfix. Cat your postfix log and grep for warnings and see if anything stands out.
Chris
Kanwar Ranbir Sandhu m3freak@rogers.com 08/31/06 8:46 PM >>>
On Thu, 2006- 31- 08 at 16:29 - 0400, Chris Hammond wrote:
I use postfix in a multiple MailScanner systems. One thing I found is that the postfix update reset the rights on the /var/spool/postfix directory and subdirectories from postfix.root and postfix.postdrop to root.root. I would receive mail all day long but they just sat in the queue and didn't go anywhere. Not sure if this is your problem but would be worth a look.
That's plausible. And in fact, I do see a number of dirs with owner:group set to root:root under /var/spool/postfix.
But, I have no idea what the permissions should be. How did you figure it out?
BTW, I'm running postfix in a chroot, though I'm not sure why that would break it now when it didn't in the past (there are no errors when postfix is started).
Regards,
Ranbir -- Kanwar Ranbir Sandhu Linux 2.6.17- 1.2142_FC4 i686 GNU/Linux 20:45:42 up 2 days, 14:15, 3 users, load average: 0.63, 0.36, 0.23
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, 2006-31-08 at 20:53 -0400, Chris Hammond wrote:
Do you get any errors when starting postfix? I received errors about the directories not being writable by postfix. Cat your postfix log and grep for warnings and see if anything stands out.
No errors (see below):
Kanwar Ranbir Sandhu m3freak@rogers.com 08/31/06 8:46 PM >>>
BTW, I'm running postfix in a chroot, though I'm not sure why that would break it now when it didn't in the past (there are no errors when postfix is started).
As far as I can tell, Postfix isn't even trying to authenticate to the ISP mail server. It's kind of like the parameters are being ignored.
Thanks for your help. I'm puzzled why the update would break my otherwise smoothly running mail server.
Regards,
Ranbir
Sorry, missed that. But I agree, the update should not have broken a working system. I thought that was the point of the way that Red Hat did things with not always upgrading to the "bleeding edge". Oh well, hope you figure it out.
Chris
Kanwar Ranbir Sandhu m3freak@rogers.com 08/31/06 9:09 PM >>>
On Thu, 2006- 31- 08 at 20:53 - 0400, Chris Hammond wrote:
Do you get any errors when starting postfix? I received errors about the directories not being writable by postfix. Cat your postfix log and grep for warnings and see if anything stands out.
No errors (see below):
Kanwar Ranbir Sandhu m3freak@rogers.com 08/31/06 8:46 PM >>>
BTW, I'm running postfix in a chroot, though I'm not sure why that would break it now when it didn't in the past (there are no errors when postfix is started).
As far as I can tell, Postfix isn't even trying to authenticate to the ISP mail server. It's kind of like the parameters are being ignored.
Thanks for your help. I'm puzzled why the update would break my otherwise smoothly running mail server.
Regards,
Ranbir
-- Kanwar Ranbir Sandhu Linux 2.6.17- 1.2142_FC4 i686 GNU/Linux 21:05:53 up 2 days, 14:35, 3 users, load average: 0.61, 0.38, 0.32
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
That's plausible. And in fact, I do see a number of dirs with owner:group set to root:root under /var/spool/postfix.
But, I have no idea what the permissions should be. How did you figure it out?
BTW, I'm running postfix in a chroot, though I'm not sure why that would break it now when it didn't in the past (there are no errors when postfix is started).
ps auxww|grep smtp ls -l /var/spool/postfix ls -l /var/spool/postfix/etc/postfix/sasl_passwd.db (you run chrooted right?)
or grep 'postfix/smtp[' /var/log/maillog and look for messages related to sasl and/or sasl_passwd.db
the smtp daemons will run as postfix user and so sasl_passwd.db has to be readable by postfix user.
On Fri, 2006-01-09 at 11:06 +0800, Feizhou wrote:
or grep 'postfix/smtp[' /var/log/maillog and look for messages related to sasl and/or sasl_passwd.db
I'd already done that before, but I thought maybe the results warranted another look (after a several hour break). I'm glad you suggested the above because I now I have the relay working again!
The smtp server my ISP tells its customers to use is smtp.broadband.rogers.com. When I grepped maillog, I noticed messages from Aug 30 were going out successfully like this:
relay=smtp.broadband.rogers.com[206.190.36.18], delay=1, status=sent (250 ok 1156773933 qp 73034)
However, messages from Aug 31 were giving this error:
relay=smtp-rog.mail.yahoo2.akadns.net[206.190.36.18], delay=0, status=bounced (host smtp-rog.mail.yahoo2.akadns.net[206.190.36.18] said: 530 authentication required - for help go to http://help.yahoo.com/help/us/mail/pop/pop-11.html (in reply to MAIL FROM command))
Interesting: there's been a change at the ISP. smtp.broadband.rogers.com is now pointing to smtp-rog.mail.yahoo2.akadns.net. I changed my postfix config to include the new smtp server name, and my emails started heading out again. Yeah!
I don't know enough about the process to know exactly what happened, but it looks like Postfix attempted to auth directly to the old server. When it was "forwarded" to the new server, the login failed.
I'm puzzled why the manual test I performed worked using the old server name, but wouldn't with Postfix. Anyone know the details about the auth process to explain what happened?
Anyway, I'm just glad it's all running again. I'm even happier that it wasn't the postfix update that messed things up.
the smtp daemons will run as postfix user and so sasl_passwd.db has to be readable by postfix user.
Actually, postfix starts as the root user, reads everything it needs to get going (including the sasl_passwd.db file), and then drops privileges to the postfix user.
Thanks Chris and Feizhou for your help. I appreciated the replies very much!
Regards,
Ranbir
Anyway, I'm just glad it's all running again. I'm even happier that it wasn't the postfix update that messed things up.
glad you have got things up and running again.
the smtp daemons will run as postfix user and so sasl_passwd.db has to be readable by postfix user.
Actually, postfix starts as the root user, reads everything it needs to get going (including the sasl_passwd.db file), and then drops privileges to the postfix user.
Actually, master runs as root and it does not read everything and then drop privileges but continues running as root.
Try 'ps axuww|grep master'
Stilling running as root.
smtpd, smtp processes will be run as postfix user and they do not read everything to get going either. That why you can update tables without stopping and starting postfix and see the updates going live after a while.
Hi
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted.
It took me a while to realise what happened and restore the aliases file from a backup.
Now it's fine.
Odd.
Chris
Chris Croome wrote:
Hi
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted.
It took me a while to realise what happened and restore the aliases file from a backup.
Now it's fine.
Odd.
you mean broken.
Chris Croome wrote:
Hi
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted.
It took me a while to realise what happened and restore the aliases file from a backup.
Now it's fine.
Has this happened to anyone else?
Bbt Lists wrote:
Chris Croome wrote:
Hi
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted.
It took me a while to realise what happened and restore the aliases file from a backup.
Now it's fine.
Has this happened to anyone else?
It hasn't happened to me yet and I've upgraded a half dozen or so machines already.
Cheers,
On Fri, 2006-01-09 at 09:53 -0700, Bbt Lists wrote:
Has this happened to anyone else?
Hasn't happened to me. Three CentOS servers updated, and the alaises database is intact. Also, my "problem" had nothing to do with the Postfix update - it was the stupid ISP (I can't stand Rogers, but I'm forced to use them).
All in all, the U4 update went very well.
Regards,
Ranbir
On Fri, Sep 01, 2006 at 09:53:15AM -0700, Bbt Lists wrote:
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted. It took me a while to realise what happened and restore the aliases file from a backup. Now it's fine.
Has this happened to anyone else?
Wasn't postfix changed to use the system-standard /etc/aliases before the RHEL4 release? I'm a bit hazy on this -- maybe we ported that modification over from Fedora Core locally.
On Fri, Sep 01, 2006 at 04:23:35PM -0400, Matthew Miller wrote:
On Fri, Sep 01, 2006 at 09:53:15AM -0700, Bbt Lists wrote:
My 4.4 upgrade experience with postfix involved /etc/postfix/aliases and /etc/postfix/aliases.db getting deleted. It took me a while to realise what happened and restore the aliases file from a backup. Now it's fine.
Has this happened to anyone else?
Wasn't postfix changed to use the system-standard /etc/aliases before the RHEL4 release? I'm a bit hazy on this -- maybe we ported that modification over from Fedora Core locally.
CentOS-3 [tru@sillage ~]$ rpm -q postfix postfix-2.0.16-14.RHEL3.x86_64 [tru@sillage ~]$ rpm -qlc postfix| grep aliases /etc/postfix/aliases /etc/postfix/aliases.db
CentOS-4: [tru@casewell ~]$ rpm -q postfix postfix-2.2.10-1.RHEL4.2.i386 [tru@casewell ~]$ rpm -qlc postfix | grep aliases [tru@casewell ~]$ rpm -qf /etc/aliases setup-2.5.37-1.3.noarch
Tru
Hi
On Fri 01-Sep-2006 at 10:51:59PM +0200, Tru Huynh wrote:
On Fri, Sep 01, 2006 at 09:53:15AM -0700, Bbt Lists wrote:
Wasn't postfix changed to use the system-standard /etc/aliases before the RHEL4 release? I'm a bit hazy on this -- maybe we ported that modification over from Fedora Core locally.
CentOS-4: [tru@casewell ~]$ rpm -q postfix postfix-2.2.10-1.RHEL4.2.i386 [tru@casewell ~]$ rpm -qlc postfix | grep aliases [tru@casewell ~]$ rpm -qf /etc/aliases setup-2.5.37-1.3.noarch
Right, I'm not exactly sure why my aliases file was in /etc/postfix -- the machine was a centos 4 install from scratch, I think I copied it from an older install.
This explains why others didn't have their aliases deleted perhaps...
Chris
Kanwar Ranbir Sandhu wrote:
Hi Everyone,
My CentOS 4.4 mail server is having problems sending mail after updating it to 4.4 Before the update, I did not have any problems.
My ISP requires that email clients must authenticate to their mail servers before mail can be sent out. I setup smtp auth to get postfix to relay mail through the ISP's mail servers. Here's my config:
main.cf
relayhost = [smtp.broadband.rogers.com] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options =
sasl_passwd
It's late and I've had a long day, so forgive me if I overlooked this from someone else mentioning it. Have you checked the permissions on the sasl_passwd and sasl_passwd.db file?
When I updated today, one machine stopped working sending mail, and the other one was fine. For me, I found the relayhost commented out, and I have no idea why. On the working machine, everything was fine.
Given the strange happenings of updating today, I'd check the permissions on the sasl_passwd files. They should be 600. If that doesn't work, did you simply try to regenerate the sasl_passwd.db file after the permission is correct?
postmap hash:/etc/postfix/sasl_passwd
The last update from 4.2 -> 4.3 made my relaying stop working, and all I had to do was regenerate the password file and life was good again. Whatcha think?
Max
-
Bbt Lists -
Chris Croome -
Chris Hammond -
chrism＠imntv.com -
Feizhou -
Kanwar Ranbir Sandhu -
Matthew Miller -
Max H. -
Tru Huynh