Hi. I fetchmail down and postfix up to my ISP's Smarthost. Often this works fine. Too often, it doesn't. I suspected over-aggressive greylisting, but that appears not to be the case. And now, I see it's not. Within an hour's time, mails go out fine, then fail (see Subject). Or fail, then start working, then fail. I hate intermittent failures. I've disabled mysqld startup. I don't need it if I'm not using it. Can that be involved? I've tried troubleshooting this with my ISP (which is *nix aware/generally competent), but they think my system is not always sending authentication. I find that hard to believe. SMTP is supposed to queue messages, and temporary bounces ought to be re-tried, but aren't. Why? Is a 501 error supposed to be final? Dec 12 17:35:20 infidel postfix/smtp[8939]: 39F3352172: to=<libranet-ot@yahoogroups.com>, relay=smtp.nucleus.com[66.18.251.14]:25, delay=0.18, delays=0.03/0.01/0.08/0.06, dsn=5.7.1, status=bounced (host smtp.nucleus.com[66.18.251.14] said: 501 5.7.1 This system is not configured to relay mail from <keeling@nucleus.com> to <libranet-ot@yahoogroups.com> for dsl-vlan423-66-18-197-214.nucleus.com (in reply to RCPT TO command)) Successful:
This does not appear to be a debian packaging bug, so the proper place for this is probably upstream, on the postfix-users list. As you have guessed, this actually does not also appear to be a postfix bug at all. It appears that your upstream provider is having issues and you don't have enough information to resolve it, short of helpful tech support at your provider. A 5xx series error is a permanent error, as you surmise. Greylisting generally uses 4xx temporary errors and Postfix would, in fact, retry as it should, so this is probably not greylisting related. Two questions: 1) one set of log messages does show your IP address, but the other doesn't. Is your IP address being changed by your provider every so often? 2) How are you authenticating to the smart host? Does your smart host require POP-before-SMTP authentication? If so, then fetchmail would have to check email before you try to send mail.
Incoming from Jamieson Becker: http://postfix.state-of-mind.de/patrick.koetter/smtpauth/smtp_auth_mailservers.html was suggested, but didn't help. However, mentioning POP before SMTP gave me a clue. I run fetchmail in a script run by my user crontab, and recently, I'd changed it to run every 10 min., where it was previously running every 5 min. Perhaps that's why this raised its ugly head in the first place. Question for you: does "/etc/init.d/postfix restart" do a "postfix reload"? I don't think so and think it should, perhaps testing whether /etc/postfix/sasl_password is newer than /etc/postfix/sasl_password.db first. I also noticed /etc/postfix/sasl_password.db didn't exist when I looked into this, so "postmap hash:/etc/postfix/sasl_passwd" hadn't been done. You might consider adding that based on the same test above. Still looking into it. Thanks Jamieson.