Re: Strange SASL Authentication Issue
On 01/11/2012 08:38 PM, Gary Smith wrote: Restarting postfix, saslauthd and authdaemon seems to get it working again, at least for a while. Are you using pam_mysql by chance? Yes, I am.
Re: Strange SASL Authentication Issue
On 01/13/2012 09:52 AM, lst_ho...@kwsoft.de wrote: Zitat von Robert Krig robert.k...@render-wahnsinn.de: On 01/11/2012 08:38 PM, Gary Smith wrote: Restarting postfix, saslauthd and authdaemon seems to get it working again, at least for a while. Are you using pam_mysql by chance? Yes, I am. Too bad, pam_mysql is known to leak memory. We have used it some time ago and the only option to get it stable was with saslauthd -n 0. Regards Andreas So far it's been running stable, memorywise by using the -c flag for cacheing. Is there any downside to the -n 0 flag? I had read about before, but I wanted to see if cacheing alone made a difference.
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 13:11:12 Wietse Venema wrote: Robert Krig: This is just a quick heads up for people who might be experiencing similar issues. I think I might have identified the problem. Apparently in some situations SASLauthd can produce memory leaks. This is what I've gathered from other people's posts. Now I'm not certain if this is what was causing my particular issue (too soon to tell), but it's worth checking out. I noticed that the RAM usage on my mailserver seemed to continually grow over time, and the date when the authentication issues arose, seem to coincide with the ram usage growing beyond the upper limit of the Server's resources. Anyways, I added the -c parameter to my saslauthd options. This is supposed to cache the authentication credentials. So far, my ram usage seems to stay more or less constant. It's still too early to tell if this solved it or not. Since my issue is very sporadic. But I thought I'd just mention it, in case someone here has similar issues.
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 07:14:14 Wietse Venema wrote: Why do you believe that there is a problem with SASL authentication between the PHP application and Postfix? Because the only error that shows up in the log file is this: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: warning: www2.domain.com[xx.xx.xx.xx]: SASL LOGIN authentication failed: authentication failure postfix/smtpd[7310]: lost connection after RSET from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: disconnect from www2.domain.com[xx.xx.xx.xx] ## For comparison, this is what it normally looks like: ## postfix/smtpd[7310]: connect from www2.domain.com[xx.xx.xx.xx] postfix/smtpd[7310]: A406B202D9: client=www2.domain.com[xx.xx.xx.xx], sasl_method=LOGIN, sasl_username=nore...@domain.com postfix/cleanup[7309]: A406B202D9: message- id=7d3559e19e3c13f1aa342b9d5a33a...@www.domain.com postfix/qmgr[9970]: A406B202D9: from=i...@domain.com, size=733, nrcpt=1 (queue active) postfix/smtpd[7310]: disconnect from www2.domain.com[xx.xx.xx.xx] postfix/smtp[7360]: A406B202D9: to=u...@web.de, relay=mx- ha01.web.de[xxx.xx.xxx.xxx]:25, delay=0.21, delays=0.08/0.02/0.05/0.06, dsn=2.0.0, status=sent (250 OK id=1Rg1kQ-0002ax-00) postfix/qmgr[9970]: A406B202D9: removed ## Your posting provides no concrete symptoms (logging!) that would allow the list to help you towards a solution. It is not unusual for people to confuse authentication and encryption. http://www.postfix.org/DEBUG_README.html#mail. DO NOT TURN ON VERBOSE LOGGING until asked to do so. The default Postfix logging may look like useless garbage to you, but it provides a lot of detail that gets drowned out out when you open the firehose. Wietse I've enabled debug logging only for the affected hosts, so that my log files don't get overwhelmed with useless noise. Like I said, it's weird. If the affected clients could not send any mail it would be one thing, but why they seem to work fine for weeks and then once in a while simply refuse to authenticate properly, is beyond me. Could it have something to do with smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination which I have in my main.cf? The affected hosts are in my mynetworks list. As far as I understand it, this would mean that the hosts which are listed in mynetworks do not HAVE to authenticate. The phpmailer clients in this case are configured to try and authenticate with the proper username and password. Is there a possibility that there is a race condition of some sort? We have 4 webservers. www1, www2, www3, www4. They all use the same username and password to authenticate and send mail via the same account. Could there be a problem if they try to authenticate simultaneously? Or would it be better to remove the permit_mynetworks line, so that they are forced to authenticate properly? Whats weird is that the problem gets fixed by simply restarting the services.
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 09:08:03 Wietse Venema wrote: Fortunately, the Postfix SMTP server is a short-lived process that runs for a few minutes at a time without ever changing the system configuration. Every new Postfix SMTP server process is like a new-born with a blank memory of its past. Therefore, if SASL logins fail, especially when they fail persistently, then either the SASL client has changed, or the SASL server infrastructure **outside POSTFIX** has changed. But thats just it, they don't fail persistently. I mean, it all works fine, until all of a sudden it doesn't anymore and only for these accounts. The other accounts continue to work fine. This would be a good time to provide configuration information about how Postfix interfaces to the SASL server infrastructure **outside POSTFIX**. There are two such possible infrastructures: Dovecot or Cyrus SASL. This choice is made with the smtpd_sasl_type parameter. Examine the output from: # postconf smtpd_sasl_type smtpd_sasl_type = cyrus If this is cyrus, you need to report what's in the smtpd.conf file, whose location depends on how your distributor has tweaked the details of the SASL server infrastructure **outside POSTFIX**. This file could be located in /usr/local/lib/sasl2, in /etc/postfix, or any number of other places. /usr/lib/sasl2/smtpd.conf ## pwcheck_method: saslauthd mech_list: plain login saslauthd_path: /var/run/saslauthd/mux log_level: 7 ## /etc/authlib/authmysqlrc ### MYSQL_SERVER localhost MYSQL_PORT 3306 MYSQL_USERNAME postfix_user MYSQL_PASSWORD postfixpassword MYSQL_DATABASE postfix_db MYSQL_USER_TABLEmailbox MYSQL_CRYPT_PWFIELD password MYSQL_UID_FIELD 5000 MYSQL_GID_FIELD 5000 MYSQL_LOGIN_FIELD username MYSQL_HOME_FIELD/home/vmail MYSQL_NAME_FIELDname MYSQL_MAILDIR_FIELD maildir MYSQL_QUOTA_FIELD quota ### /etc/authlib/authdaemonrc ### authmodulelist=authmysql authmodulelistorig=authuserdb authpam authpwd authshadow authpgsql authldap authmysql authcustom authpipe daemons=5 authdaemonvar=/var/spool/authdaemon DEBUG_LOGIN=2 DEFAULTOPTIONS= LOGGEROPTS= ### /etc/conf.d/saslauthd ### SASLAUTHD_OPTS=-m /var/run/saslauthd -r -a pam ### By the way, I'm running Arch Linux, in case thats relevant. (You never know)
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 10:15:19 Wietse Venema wrote: Some accounts fail persistently, if I recall correctly. Sorry, I think you misunderstood me. Let me explain again. Our 4 webservers CONSTANTLY send registration emails to new users via a local php-mailer on each webserver instance which connects to our central postfix mail server. This works, except on rare occasions when it fails without explanation. This is what I find so puzzling. It's not consistent behaviour, and I haven't yet found what causes it, or been able to reproduce it. It seems to happen at random. Sometimes it can be weeks before it happens again. Once it happens, only THAT account is unable to authenticate until I restart all relevant daemons. So, a user registers on our website via one of our webservers. In this case www1, www2, www3 or www4. All our webservers use the same account to send a registration confirmation email to the new user. In this case nore...@example.com This happens via a local phpmailer instance on each webserver. The phpmailer simply sends the registration mail via smtp to our postfix server using the nore...@example.com account. Either way, I'll try what you suggested and see if I can't find anymore clues. On our postfix server, we have lots of other accounts and domains. But the weirdest thing is, when THAT account stops working, all others still continue to work as normal. That's what makes it so difficult to catch that there is a problem. If the mail server itself suddenly completely stopped working, we would notice this immediately. But as it is, it's only the webservers trying to send registration emails via that one account.
Re: Strange SASL Authentication Issue
On Wednesday 11 January 2012 11:38:13 Wietse Venema wrote: You have a problem that starts at some unpredictable moment, and that causes SOME ACCOUNTs to fail PERSISTENTLY after it starts. This is typical of one PERSISTENT process (like saslauthd or mysqld) having some corruption of some kind, that PERSISTS until you restart that PERSISTENT process. The Postfix SMTP server is not a persistent process. It is just the messenger of the bad news. I am done helping you. Good luck. Wietse Sorry, didn't mean to sound rude or ungrateful. I think I simply misunderstood you the first time. Anyways, thanks you for help.
Strange SASL Authentication Issue
I've got a weird issue on one of my postfix installations that I can't explain. My postfix setup uses MySQL as an authentication backend, and the accounts are managed via Postfixadmin. All of our webservers use phpmailer to send out registration notices to users who register on our site. Now, there are plenty of other accounts on this mail server. Once in a while what happens, and ONLY with this one mail account which is used to send out registration emails, is that for no apparent reason SASL Authentication will stop working, but ONLY for that one account. All other accounts are happy to go about their business. It's really weird. I have no idea how to reproduce it, or what is causing it. Needless to say, it is very annoying since we only notice it a day or two later, when we see a lot of user waiting for email registration messages in the admin section of our website. Restarting postfix, saslauthd and authdaemon seems to get it working again, at least for a while. This has me totally baffeled. I've turned on detailed debug logging in postfix for just our webservers, so it might be a while before this hits me again. But how weird. So far the only message in the Logs that appears whenever this happens is: warning: www1.domain.com[xx.xxx.xxx]: SASL LOGIN authentication failed: authentication failure It's the same message for all our webservers which act as clients to this postfix server. What I don't understand is, how can authentication suddenly stop working for only this account, while all the other ones still keep working and authenticating? Like I've said, I've enabled debug logging for specific hosts. But that might take a while to produce some insightful results. In the meantime, does anyone have the faintest idea what might be causing a problem here?
sender_bcc, recipient_bcc, double messages: Need some help
Hi guys. I need some help. I've setup postfix to use sender_bcc_maps and recipient_bcc_maps so that only one of the virtual domains which we host, is forwarded to a backup account. The sender_bcc and recipient_bcc statements are in the main.cf The problem, as so many have posted before, is that the backup mailbox receives every mail twice. I realize this has to do with our external filters in our postfix queue, however Im totally lost as to where exactly to insert the options that have been posted in this newsgroup as a solution. I've have tried various options before, but either BCC gets disabled completely, or postfix refuses to accept smtp connections. I'm aware of the recieve_override_options=no_address_mappings setting. But if I put in the main.cf then no mails get sent via BCC to the backup mailbox. I have experimented with placing the sender_bcc_maps and recipient_bcc_maps at several different places within my master.cf. But whenever I do that, postfix stops working properly and refuses smtp connections. In other words, I can't send out email. Some additional info about our postfix setup: We use mysql as a user database in combination with postfixadmin. Secondly we filter emails via postgrey, amavisd, spamassassin and maildrop. The configuration wasn't entirely done by me, different admins added and modified different things, so I've lost the overview a bit. Can anyone help me? Below is the output of my postconf -n and my master.cf Thanks. broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib64/postfix data_directory = /var/lib/postfix debug_peer_level = 1 default_destination_concurrency_limit = 20 home_mailbox = .maildir/ html_directory = /usr/share/doc/postfix-2.2.9/html inet_interfaces = 1.1.1.1, mail.com, localhost local_destination_concurrency_limit = 4 mail_owner = postfix mailbox_size_limit = 102400 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 102400 mydestination = $myhostname myhostname = mail.com mynetworks = 1.1.1.1, 127.0.0.0/8 mynetworks_style = host myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.2.9/readme recipient_bcc_maps = hash:/etc/postfix/recipient_bcc sample_directory = /etc/postfix sender_bcc_maps = hash:/etc/postfix/sender_bcc sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_tls_note_starttls_offer = yes smtpd_client_connection_rate_limit = 10 smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination check_policy_service inet:127.0.0.1:10030 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/ssl/demoCA/cacert.pem smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_cert_file = /etc/postfix/ssl/server-crt.pem smtpd_tls_key_file = /etc/postfix/ssl/server-key.pem smtpd_tls_loglevel = 3 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid_maps = static:207 virtual_mailbox_base = /var/vmail/ virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domain_maps.cf virtual_mailbox_limit = 10240 virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 207 virtual_transport = maildrop virtual_uid_maps = static:207 ### smtp inet n - n - 8 smtpd #-o content_filter=scan:[127.0.0.1]:10024 -o content_filter=spamchk:dummy -o recieve_override_options=no_address_mappings # #Mail transport used above. scan unix - - n - 4 lmtp -o disable_dns_lookup=yes -o lmtp_send_xforward_command=yes -o lmtp_data_done_timeout=1200 #Injecting mail back into Postfix after content filter localhost:10025 inet n - n - 4 smtpd -o content_filter= -o myhostname=localhost.mail.com -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelope=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 smtps inet
