Re: Relay host auth not working
On 2011-07-12 07:12, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: No. Include the FULL output from postconf -n, or, even better, the postfinger tool. We can only guess what you're doing wrong now. -- J.
Re: Relay host auth not working
On 7/12/2011 12:12 AM, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: relayhost = secure.genesisgroup.info smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Here is a log excerpt from my server from a successful login from a different client (python smtplib): Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], sasl_method=LOGIN, sasl_username=XXX and here's the same thing when Postfix tries to connect between the same two machines: Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 ron.gar...@gmail.com: Relay access denied; from=r...@sunfire-offices.com to=ron.gar...@gmail.com proto=ESMTP helo=mail.sunfire-offices.com As you can see, postfix is not even attempting to authorize. What am I doing wrong? You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: When you specify relayhost you're telling Postfix to forward all non local outbound mail to a gateway instead of delivering it directly to internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. You're showing smtpd logging, but the relayhost parameter applies to smtp, not smtpd. Your logging shows a host connecting to your Postfix server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. Ok, now the logging snippets make sense. I'm guessing you simply need to add permit_sasl_authenticated to your smtpd_client_restrictions on host secure.genesisgroup.info, or if you use the everything under smtpd_recipient_restrictions main.cf style you'd do: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination ... You provided 'postconf -d' instead of 'postconf -n', so it's impossible for me to tell what your parameters actually are. -d simply shows the Postfix defaults. Please provide 'postconf -n' so we can wrap this thread up, assuming permit_sasl_authenticated doesn't fix the problem. -- Stan
Re: Relay host auth not working
On Jul 11, 2011, at 11:03 PM, Jeroen Geilman wrote: On 2011-07-12 07:12, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: No. Include the FULL output from postconf -n, [ron@domU-12-31-39-00-E6-ED:~]$ postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost mydomain = sunfire-offices.com myhostname = mail.sunfire-offices.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = secure.genesisgroup.info sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = unknown_local_recipient_reject_code = 550 or, even better, the postfinger tool. Postfinger - Postfix Configuration on Tue Jul 12 06:08:45 UTC 2011 $Revision: 1.25 $ Warning: Postfinger output may show private configuration information, such as ip addresses and/or domain names which you do not want to show to the public. If this is the case it is your responsibility to modify the output to hide this private information. [Remove this warning with the --nowarn option.] --System Parameters-- mail_version = 2.6.6 hostname = domU-12-31-39-00-E6-ED uname = Linux domU-12-31-39-00-E6-ED 2.6.35.11-83.9.amzn1.x86_64 #1 SMP Sat Feb 19 23:42:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux --Packaging information-- looks like this postfix comes from a RPM package: postfix-2.6.6-2.8.amzn1.x86_64 --main.cf non-default parameters-- alias_maps = hash:/etc/aliases inet_interfaces = localhost inet_protocols = all mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydomain = sunfire-offices.com myhostname = mail.sunfire-offices.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = secure.genesisgroup.info sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = --master.cf-- smtp inet n - n - - smtpd pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scacheunix - - n - 1 scache -- end of Postfinger output -- We can only guess what you're doing wrong now. I did include the output from postconf at the end of my original message. rg
Re: Relay host auth not working
On 7/12/2011 1:09 AM, Ron Garret wrote: On Jul 11, 2011, at 11:03 PM, Jeroen Geilman wrote: On 2011-07-12 07:12, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: No. Include the FULL output from postconf -n, relayhost = secure.genesisgroup.info Wrong box. This output is from the EC2 box. We need to see 'postconf -n' from the box secure.genesisgroup.info. The permit_sasl_authenticated needs to be added to main.cf on secure.genesisgroup.info to allow the EC2 box to relay through it. But we'd like to confirm your current allowed relay settings, aka mynetworks, etc. -- Stan
Re: Relay host auth not working
On Jul 11, 2011, at 11:07 PM, Stan Hoeppner wrote: On 7/12/2011 12:12 AM, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: relayhost = secure.genesisgroup.info smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Here is a log excerpt from my server from a successful login from a different client (python smtplib): Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], sasl_method=LOGIN, sasl_username=XXX and here's the same thing when Postfix tries to connect between the same two machines: Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 ron.gar...@gmail.com: Relay access denied; from=r...@sunfire-offices.com to=ron.gar...@gmail.com proto=ESMTP helo=mail.sunfire-offices.com As you can see, postfix is not even attempting to authorize. What am I doing wrong? You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: When you specify relayhost you're telling Postfix to forward all non local outbound mail to a gateway instead of delivering it directly to internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. You're showing smtpd logging, but the relayhost parameter applies to smtp, not smtpd. Your logging shows a host connecting to your Postfix server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. Ok, now the logging snippets make sense. I'm guessing you simply need to add permit_sasl_authenticated to your smtpd_client_restrictions on host secure.genesisgroup.info, or if you use the everything under smtpd_recipient_restrictions main.cf style you'd do: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination ... No, that's not the problem. I already have exactly that on secure.genesisgroup.info. (See below.) And I have multiple clients successfully using that host for authenticated SMTP, including a python client running on the same machine that the non-working (in this respect) postfix is running on. You provided 'postconf -d' instead of 'postconf -n', so it's impossible for me to tell what your parameters actually are. -d simply shows the Postfix defaults. Please provide 'postconf -n' so we can wrap this thread up, assuming permit_sasl_authenticated doesn't fix the problem. Actually, it was postconf with no arguments. Here is postconf -n: [ron@domU-12-31-39-00-E6-ED:~]$ postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost mydomain = sunfire-offices.com myhostname = mail.sunfire-offices.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = secure.genesisgroup.info sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = unknown_local_recipient_reject_code = 550 And just for completeness, here it is for secure.genesisgroup.info: [ron@vm1:/etc/postfix]$ /usr/sbin/postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases
Re: strange behaviour : incoming queue
On 2011-07-12 07:49, Tom Kinghorn wrote: On 11/07/2011 15:01, Wietse Venema wrote: Rule number one: present actual evidence of the problem. In this case, present actual evidence that mail stays in the Postfix queue. Wietse Apologies It was in the queues/incoming directory So show us those mails. Man postqueue, man postcat. Include relevant logging as well, to show any delivery attempts - grep the logs for the Queue ID. # perl qshape.pl T 5 10 20 40 80 160 320 640 1280 1280+ TOTAL 8 2 1 0 0 0 0 0 05 0 vodamail.co.za 7 2 1 0 0 0 0 0 04 0 mx1.vodamail.co.za 1 0 0 0 0 0 0 0 01 0 16 messages in the incoming + active queues. I don't know where you get the 384 figure from, but it's not postfix. Run it for message distribution instead: # qshape -s incoming One message could have 100 recipients for all we know. What would cause the old files in the queues directory not to be cleared out. That situation is unlikely to occur, if ever. If they are not picked up, they were not sent either. -- J.
Re: Relay host auth not working
On 07/11/2011 10:12 PM, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: relayhost = secure.genesisgroup.info smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Here is a log excerpt from my server from a successful login from a different client (python smtplib): Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], sasl_method=LOGIN, sasl_username=XXX and here's the same thing when Postfix tries to connect between the same two machines: Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 ron.gar...@gmail.com: Relay access denied; from=r...@sunfire-offices.com to=ron.gar...@gmail.com proto=ESMTP helo=mail.sunfire-offices.com As you can see, postfix is not even attempting to authorize. What am I doing wrong? You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: When you specify relayhost you're telling Postfix to forward all non local outbound mail to a gateway instead of delivering it directly to internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. You're showing smtpd logging, but the relayhost parameter applies to smtp, not smtpd. Your logging shows a host connecting to your Postfix server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. Either you don't understand the relayhost parameter, or I simply don't understand your goal here, or probably both. Well, I'm clearly missing something. But I don't think it's the relayhost parameter. rg As stated by Jeroen, supplying the list with the output of 'postconf -n' would be much more preferred than sending the entire output of 'postconf'. There is no need for people to wade through hundreds of lines that are configured for default values. The server at secure.genesisgroup.info only advertises AUTH support after STARTTLS. Therefore, in order to successfully authenticate with that server from the client at 184.73.65.10, the following configuration changes will need to be made on 184.73.65.10: Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at least a setting of 'may'. This will allow the SMTP client to attempt STARTTLS connections with remote hosts. Set smtp_sasl_security_options = noanonymous (or whatever is appropriate). The remote server at secure.genesisgroup.info advertises the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN Read the TLS_README and SASL_README files for more information. -Mike
Re: Relay host auth not working
On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: On 07/11/2011 10:12 PM, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: relayhost = secure.genesisgroup.info smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Here is a log excerpt from my server from a successful login from a different client (python smtplib): Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], sasl_method=LOGIN, sasl_username=XXX and here's the same thing when Postfix tries to connect between the same two machines: Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 ron.gar...@gmail.com: Relay access denied; from=r...@sunfire-offices.com to=ron.gar...@gmail.com proto=ESMTP helo=mail.sunfire-offices.com As you can see, postfix is not even attempting to authorize. What am I doing wrong? You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: When you specify relayhost you're telling Postfix to forward all non local outbound mail to a gateway instead of delivering it directly to internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. You're showing smtpd logging, but the relayhost parameter applies to smtp, not smtpd. Your logging shows a host connecting to your Postfix server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. Either you don't understand the relayhost parameter, or I simply don't understand your goal here, or probably both. Well, I'm clearly missing something. But I don't think it's the relayhost parameter. rg As stated by Jeroen, supplying the list with the output of 'postconf -n' would be much more preferred than sending the entire output of 'postconf'. There is no need for people to wade through hundreds of lines that are configured for default values. Sorry, I'm still kinda new at this. The server at secure.genesisgroup.info only advertises AUTH support after STARTTLS. Therefore, in order to successfully authenticate with that server from the client at 184.73.65.10, the following configuration changes will need to be made on 184.73.65.10: Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at least a setting of 'may'. This will allow the SMTP client to attempt STARTTLS connections with remote hosts. Ah. I thought SASL implied TLS, but I guess it doesn't. So I tried adding: smtp_sasl_security_options = auth smtp_tls_security_level = may And now I get unknown mail transport error on the client side, and this on the server side: Jul 11 23:30:51 vm01 postfix/smtpd[22169]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: lost connection after EHLO from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: disconnect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Set smtp_sasl_security_options = noanonymous (or whatever is appropriate). The remote server at secure.genesisgroup.info advertises the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN Read the TLS_README and SASL_README files for more information. Will do. At least now I know where to look to make further progress. Thanks! rg
Re: Relay host auth not working
On 7/12/2011 1:37 AM, Ron Garret wrote: On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at least a setting of 'may'. This will allow the SMTP client to attempt STARTTLS connections with remote hosts. Ah. I thought SASL implied TLS, but I guess it doesn't. So I tried adding: smtp_sasl_security_options = auth smtp_tls_security_level = may And now I get unknown mail transport error on the client side, and this on the server side: Jul 11 23:30:51 vm01 postfix/smtpd[22169]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: lost connection after EHLO from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: disconnect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Set smtp_sasl_security_options = noanonymous (or whatever is appropriate). The remote server at secure.genesisgroup.info advertises the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN Read the TLS_README and SASL_README files for more information. Will do. At least now I know where to look to make further progress. Thanks! Since this is a server to server relay of known/trusted systems, and assuming that 184.73.65.10 is static and won't change any time soon, why not simply add 184.73.65.10 to $mynetworks on secure.genesisgroup.info and forget the sasl auth junk? This should get the relaying working instantly with little or no pitfalls. -- Stan
Re: Forcing postfix to check the MX entry
Mark Goodge wrote: On 11/07/2011 15:02, Бак Микаел wrote: Easy! Fix the software that your trusted users use to add their domain. Make THAT software check that the domain's MX record points to the right place BEFORE you actually add it to the database. That's not actually helpful, because if you want to avoid any interruption to mail delivery you have to add the domain to the new destination server before you alter the MX to point it there. Yep, that's right. Didn't think of existing domains with mail traffic getting transferred to his server. Nevermind. This is not a postfix problem anyway. M.
Re: strange behaviour : incoming queue
Tom Kinghorn: On 11/07/2011 15:01, Wietse Venema wrote: Rule number one: present actual evidence of the problem. In this case, present actual evidence that mail stays in the Postfix queue. Wietse Apologies It was in the queues/incoming directory #ls -la queues/incoming/ | wc -l 384 How many times per week do you execute postfix stop? Wietse
Re: strange behaviour : incoming queue
On 12/07/2011 08:16, Jeroen Geilman wrote: What would cause the old files in the queues directory not to be cleared out. That situation is unlikely to occur, if ever. If they are not picked up, they were not sent either. Hi List On further investigation, I noticed that the files which remain in the /queues/incoming directory are zero byte in size. The logs show the following: Jul 12 12:05:29 mx1 postfix/smtpd[27176]: 461D2412E34: client=localhost[127.0.0.1] Jul 12 12:05:29 mx1 postfix/master[1687]: warning: process /usr/lib/postfix/cleanup pid 16159 killed by signal 6 This leaves behind the aforementioned file, as below. queues/incoming # ls -la total 18448 drwx-- 2 postfix postfix4096 Jul 12 13:01 . drwxr-xr-x 16 rootroot 4096 Jul 4 14:45 .. -rw--- 1 postfix postfix 1024000 Jul 12 13:01 038F24DDED4 -rw--- 1 postfix postfix 0 Jul 12 12:22 1BBD2584CBD -rw--- 1 postfix postfix 0 Jul 12 12:46 1F39558688A -rw--- 1 postfix postfix 0 Jul 12 12:08 21B08584CAE -rw--- 1 postfix postfix 1998848 Jul 12 13:01 3081C5868D6 -rw--- 1 postfix postfix 0 Jul 12 11:59 41CE31D7DFB -rw--- 1 postfix postfix 2035712 Jul 12 13:01 43DA15868D4 -rw--- 1 postfix postfix 0 Jul 12 12:05 461D2412E34 -rw--- 1 postfix postfix 0 Jul 12 12:24 4B309587ECE /snip
Re: strange behaviour : incoming queue
On 12/07/2011 13:03, Wietse Venema wrote: How many times per week do you execute postfix stop? Wietse I myself very rarely do, but I am unsure how many times the other admin's do. They love writing scripts to do all sorts of things. restarting postfix is probably one of them. But then, they will never admit to it.
Re: strange behaviour : incoming queue
Tom Kinghorn: Jul 12 12:05:29 mx1 postfix/smtpd[27176]: 461D2412E34: client=localhost[127.0.0.1] Jul 12 12:05:29 mx1 postfix/master[1687]: warning: process /usr/lib/postfix/cleanup pid 16159 killed by signal 6 signal 6 means that the cleanup daemon logged a panic message that specifies the cause for aborting. Apparently, you are using a syslog implementation that logs different severity levels to different files. I suggest that you search for lines with panic in all email-related logfiles. By the way, this means that NO MAIL IS LOST. The SMTP client did not receive an SMTP acknowledgment, and will resend. Wietse
Re: strange behaviour : incoming queue
On Tue, 12 Jul 2011 13:12:29 +0200 Tom Kinghorn articulated: I myself very rarely do, but I am unsure how many times the other admin's do. They love writing scripts to do all sorts of things. restarting postfix is probably one of them. But then, they will never admit to it. Then might I suggest that you launch a clandestine operation to expose such scripts and strip them of their ability to shutdown Postfix. Since your associates have all ready denied creating such scripts, they can not now fault you for taking action against something they claim to have had no knowledge of. A careful study of the various logs should reveal what script(s) are culpable. Nothing like creating a little work place drama. ;) -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Help stamp out and abolish redundancy!
Re: strange behaviour : incoming queue
Wietse Venema: Tom Kinghorn: Jul 12 12:05:29 mx1 postfix/smtpd[27176]: 461D2412E34: client=localhost[127.0.0.1] Jul 12 12:05:29 mx1 postfix/master[1687]: warning: process /usr/lib/postfix/cleanup pid 16159 killed by signal 6 signal 6 means that the cleanup daemon logged a panic message that specifies the cause for aborting. Another possibility is that Postfix is linked with a library that aborts the program. Libraries should never do that, but hey, this is open source, and any idiot can contribute. Apparently, you are using a syslog implementation that logs different severity levels to different files. I suggest that you search for lines with panic in all email-related logfiles. By the way, this means that NO MAIL IS LOST. The SMTP client did not receive an SMTP acknowledgment, and will resend. If it's an abort in a library routine, then these instructions may help to identify the culprit. http://www.postfix.org/DEBUG_README.html#gdb Wietse
Re: strange behaviour : incoming queue
On 12/07/2011 14:28, Wietse Venema wrote: Wietse Venema: Tom Kinghorn: Jul 12 12:05:29 mx1 postfix/smtpd[27176]: 461D2412E34: client=localhost[127.0.0.1] Jul 12 12:05:29 mx1 postfix/master[1687]: warning: process /usr/lib/postfix/cleanup pid 16159 killed by signal 6 signal 6 means that the cleanup daemon logged a panic message that specifies the cause for aborting. Hi Wietse Thanks for the pointers. I have found this in the amavis logs, which could be the culprit amavis[27010]: (27010-01-12) (!!)TROUBLE in check_mail: forwarding FAILED: Error writing to socket: Broken pipe at (eval 97) line 186. Thanks once again to everyone who has offered advice. Time for some investigating on my part. regards Tom
Re: Best method to post master.conf
On 7/12/2011 12:16 AM, jeffrey starin wrote: I am trying to use the smtp_bind_address command so that three seperate ips can be used for 3 separate clients who are using email campaign software as explained in this howto: http://www.kutukupret.com/2010/01/02/postfix-bind-sender-domain-to-dedicated-outgoing-ip-address/ The error logs show the entry: Jul 11 23:46:31 who postfix/master[5309]: fatal: /etc/postfix/master.cf http://master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 which refers to the the entries in the master.cf http://master.cf using that command, smtp_bind_address command. The second problem is even if I comment out those lines that refer to smtp_bind_address in the master.cf http://master.cf, I still receive that error in the logs which is very strange indeed. It's almost as if after commenting them out, postfix has a cached copy or something of the master.cf http://master.cf which it is using. I even restart postfix and postfix reload but to no avail. If someone sees something in the syntax (although I've double checked it so many times) let me know. I even upgraded to postfix 2.8.4 from 2.3.3 because I thought it may have had something to do with the version. master.cf http://master.cf: customer1 unix - - n - - smtp -o smtp_bind_address=174.121.222.21 -o smtp_helo_name=domain1.com http://domain1.com -o syslog_name=postfix-domain1.com http://postfix-domain1.com customer2 unix - - n - - smtp -o smtp_bind_address=174.121.222.22 -o smtp_helo_name=domain2.org http://domain2.org -o syslog_name=postfix-domain2.org http://postfix-domain2.org customer3 unix - - n - - smtp -o smtp_bind_address=174.121.222.23 -o smtp_helo_name=domain3.com http://domain3.com -o syslog_name=postfix-domain3.com http://postfix-domain3.com maillog: Jul 11 23:46:31 who postfix/postfix-script[5308]: starting the Postfix mail system Jul 11 23:46:31 who postfix/master[5309]: fatal: /etc/postfix/master.cf http://master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 Jul 11 23:46:31 who postfix/master[5309]: fatal: /etc/postfix/master.cf http://master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.22 This appears to be a case of no whitespace before -o. If there is a non-whitespace character first on the line, then Postfix will treat it as a new entry. customer1 unix - - n - - smtp -o smtp_bind_address=174.121.222.21 -o smtp_helo_name=domain1.com http://domain1.com -o syslog_name=postfix-domain1.com http://postfix-domain1.com
Re: Relay host auth not working
On Jul 12, 2011, at 12:13 AM, Stan Hoeppner wrote: On 7/12/2011 1:37 AM, Ron Garret wrote: On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at least a setting of 'may'. This will allow the SMTP client to attempt STARTTLS connections with remote hosts. Ah. I thought SASL implied TLS, but I guess it doesn't. So I tried adding: smtp_sasl_security_options = auth smtp_tls_security_level = may And now I get unknown mail transport error on the client side, and this on the server side: Jul 11 23:30:51 vm01 postfix/smtpd[22169]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: lost connection after EHLO from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: disconnect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Set smtp_sasl_security_options = noanonymous (or whatever is appropriate). The remote server at secure.genesisgroup.info advertises the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN Read the TLS_README and SASL_README files for more information. Will do. At least now I know where to look to make further progress. Thanks! Since this is a server to server relay of known/trusted systems, and assuming that 184.73.65.10 is static and won't change any time soon, why not simply add 184.73.65.10 to $mynetworks on secure.genesisgroup.info and forget the sasl auth junk? This should get the relaying working instantly with little or no pitfalls. That's a good idea. The reason I didn't do it this way is that I can't count on the client IP remaining static. Also, I like to understand how things work, and I don't like to admit defeat :-) rg
Re: Iptables stopping smtp_bind_address from working properly
On Fri, Jul 08, 2011 at 11:42:51PM +0200, Ansgar Wiechers wrote: is perfectly fine. And unless you have rather strict security requirements (in which case your ruleset would allow far less protocols to begin with), you can simply accept everything in the OUTPUT chain: iptables -P OUTPUT ACCEPT Also, when posting your tables somewhere, use iptables -nL rather than just iptables -L. I always felt that output of iptables-save is a more nice way to check things out, and it can be also useful then to use it directly to build ruleset (with iptables-restore). But maybe it's only my taste ...
Re: Relay host auth not working
On Jul 11, 2011, at 11:37 PM, Ron Garret wrote: On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: On 07/11/2011 10:12 PM, Ron Garret wrote: On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: On 7/11/2011 8:12 PM, Ron Garret wrote: I'm trying to set up a relay host with authentication according to these instructions: http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ but it's not working. I know my SMTP server is set up properly because I can send mail using various other clients, but postfix is apparently not even attempting to authorize. Here are the relevant lines from main.cf: relayhost = secure.genesisgroup.info smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Here is a log excerpt from my server from a successful login from a different client (python smtplib): Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], sasl_method=LOGIN, sasl_username=XXX and here's the same thing when Postfix tries to connect between the same two machines: Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 ron.gar...@gmail.com: Relay access denied; from=r...@sunfire-offices.com to=ron.gar...@gmail.com proto=ESMTP helo=mail.sunfire-offices.com As you can see, postfix is not even attempting to authorize. What am I doing wrong? You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: When you specify relayhost you're telling Postfix to forward all non local outbound mail to a gateway instead of delivering it directly to internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. You're showing smtpd logging, but the relayhost parameter applies to smtp, not smtpd. Your logging shows a host connecting to your Postfix server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. Either you don't understand the relayhost parameter, or I simply don't understand your goal here, or probably both. Well, I'm clearly missing something. But I don't think it's the relayhost parameter. rg As stated by Jeroen, supplying the list with the output of 'postconf -n' would be much more preferred than sending the entire output of 'postconf'. There is no need for people to wade through hundreds of lines that are configured for default values. Sorry, I'm still kinda new at this. The server at secure.genesisgroup.info only advertises AUTH support after STARTTLS. Therefore, in order to successfully authenticate with that server from the client at 184.73.65.10, the following configuration changes will need to be made on 184.73.65.10: Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at least a setting of 'may'. This will allow the SMTP client to attempt STARTTLS connections with remote hosts. Ah. I thought SASL implied TLS, but I guess it doesn't. So I tried adding: smtp_sasl_security_options = auth smtp_tls_security_level = may And now I get unknown mail transport error on the client side, and this on the server side: Just for the record, this worked: smtp_sasl_security_options = noanonymous smtp_tls_security_level = may Thanks for all the responses! rg
Re: Relay host auth not working
On 7/12/2011 10:59 AM, Ron Garret wrote: Since this is a server to server relay of known/trusted systems, and assuming that 184.73.65.10 is static and won't change any time soon, why not simply add 184.73.65.10 to $mynetworks on secure.genesisgroup.info and forget the sasl auth junk? This should get the relaying working instantly with little or no pitfalls. That's a good idea. The reason I didn't do it this way is that I can't count on the client IP remaining static. Darn cheap hosting. :( Also, I like to understand how things work, and I don't like to admit defeat :-) Good attitude. That's the spirit. -- Stan
Re: Best method to post master.conf
On Tue, Jul 12, 2011 at 1:03 AM, Stan Hoeppner s...@hardwarefreak.comwrote: On 7/11/2011 11:16 PM, jeffrey starin wrote: I am trying to use the smtp_bind_address command so that three seperate ips can be used for 3 separate clients who are using email campaign software as explained in this howto: http://www.kutukupret.com/2010/01/02/postfix-bind-sender-domain-to-dedicated-outgoing-ip-address/ The error logs show the entry: Jul 11 23:46:31 who postfix/master[5309]: fatal: /etc/postfix/master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 I even upgraded to postfix 2.8.4 from 2.3.3 because I thought it may have had something to do with the version. smtp_bind_address is a new feature as of 2.7, clearly stated at the top of the article you linked. The fact that you receive the error with 2.3.3 and after you upgraded to 2.8.4 suggests that you didn't successfully replace 2.3.3 with 2.8.4. Posting the output of the following shell command will confirm this. ~$ postconf -d|grep 'mail_version =' If it says 2.3.3 you need to thoroughly remove all traces of that package (specifically /etc/init.d entries) and re-install 2.8.4 following these instructions: http://www.postfix.org/INSTALL.html -- Stan running the command at the server prompt: postconf -d|grep 'mail_version' produces: mail_version = 2.8.4 milter_macro_v = $mail_name $mail_version I don't know where you saw 2.3.3 but will nevertheless take your suggestions and re-install.
Re: Best method to post master.conf
On 7/12/2011 4:34 PM, jeffrey starin wrote: I don't know where you saw 2.3.3 but will nevertheless take your suggestions and re-install. I hope you read my comments made 8 hours ago before you do this. It is probably not necessary. (Archive: http://marc.info/?l=postfix-usersm=131047442028765)
Re: Best method to post master.conf
smtp_bind_address is a new feature as of 2.7, clearly stated at the top No, smtp_bind_address is available in all Postfix versions since 2001. If Postfix complains like this: postfix/master[5309]: /etc/postfix/master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 then line 6 in master.cf starts with -o smtp_bind_address=174.121.222.21 without the leading whitespace. No amount of Postfix reinstalling will fix that problem. Wietse
Re: Best method to post master.conf
Le 12/07/2011 06:16, jeffrey starin a écrit : I am trying to use the smtp_bind_address command so that three seperate ips can be used for 3 separate clients who are using email campaign software as explained in this howto: http://www.kutukupret.com/2010/01/02/postfix-bind-sender-domain-to-dedicated-outgoing-ip-address/ The error logs show the entry: Jul 11 23:46:31 who postfix/master[5309]: fatal: /etc/postfix/master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 which refers to the the entries in the master.cf using that command, smtp_bind_address command. The second problem is even if I comment out those lines that refer to smtp_bind_address in the master.cf, I still receive that error in the logs which is very strange indeed. It's almost as if after commenting them out, postfix has a cached copy or something of the master.cf which it is using. I even restart postfix and postfix reload but to no avail. If someone sees something in the syntax (although I've double checked it so many times) let me know. I even upgraded to postfix 2.8.4 from 2.3.3 because I thought it may have had something to do with the version. master.cf: customer1 unix - - n - - smtp -o smtp_bind_address=174.121.222.21 This is wrong. you need spaces at the beginning of the continuation line. you really need to understand postfix syntax. it goes like this: servicename op1 opt2 opt3 program -o option=value -o option2=value2 ... with spaces in the continuation lines (all but the line the starts the definition of the service). [snip]
Re: Best method to post master.conf
On Tue, Jul 12, 2011 at 05:22:03PM -0400, Wietse Venema wrote: smtp_bind_address is a new feature as of 2.7, clearly stated at the top No, smtp_bind_address is available in all Postfix versions since 2001. If Postfix complains like this: postfix/master[5309]: /etc/postfix/master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 then line 6 in master.cf starts with -o smtp_bind_address=174.121.222.21 without the leading whitespace. Indeed. Returning to the original topic though, I have a postmast(1) patch that adds a new utility that does with master.cf what postconf(1) does with main.cf. In particular it supports: postmast- show all entries in a machine-parseable normal form postmast -n - show non-default entries postmast -d - show default entries postmast -e - edit or add master.cf entries via CLI. I don't whether this is of sufficiently broad utility to warrant inclusion in the official release. -- Viktor.
Re: strange behaviour : incoming queue
On Tue, Jul 12, 2011 at 02:38:41PM +0200, Tom Kinghorn wrote: I have found this in the amavis logs, which could be the culprit amavis[27010]: (27010-01-12) (!!)TROUBLE in check_mail: forwarding FAILED: Error writing to socket: Broken pipe at (eval 97) line 186. Symptom not cause. -- Viktor.
Re: Best method to post master.conf
On 7/12/2011 4:22 PM, Wietse Venema wrote: smtp_bind_address is a new feature as of 2.7, clearly stated at the top No, smtp_bind_address is available in all Postfix versions since 2001. Correct. I got in hurry. Apologies. The 2.7 feature in the 'how-to' article he linked was: sender_dependent_default_transport_maps If Postfix complains like this: postfix/master[5309]: /etc/postfix/master.cf: line 6: bad transport type: smtp_bind_address=174.121.222.21 then line 6 in master.cf starts with -o smtp_bind_address=174.121.222.21 without the leading whitespace. No amount of Postfix reinstalling will fix that problem. My troubleshooting mistake was skimming the article, thinking it was relevant to the problem. Seeing that the OP upgraded from 2.3.3 to 2.8.4, my skimming of said article led me to believe it might be an upgrade issue. Note that I did say to upgrade only if mail_version=2.3.3, which it did not. Apologies for the noise as the problem lie elsewhere. -- Stan
Re: Best method to post master.conf
On Tue, 12 Jul 2011 17:35:56 -0400 Victor Duchovni articulated: Indeed. Returning to the original topic though, I have a postmast(1) patch that adds a new utility that does with master.cf what postconf(1) does with main.cf. In particular it supports: postmast - show all entries in a machine-parseable normal form postmast -n - show non-default entries postmast -d - show default entries postmast -e - edit or add master.cf entries via CLI. I don't whether this is of sufficiently broad utility to warrant inclusion in the official release. It gets a Thumbs Up from me. Perhaps a link similar to the postfinger tool might a adequate, although I favor the inclusion concept. Just my 2¢. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: Best method to post master.conf
On Tue, Jul 12, 2011 at 05:56:42PM -0400, Jerry wrote: On Tue, 12 Jul 2011 17:35:56 -0400 Victor Duchovni articulated: Indeed. Returning to the original topic though, I have a postmast(1) patch that adds a new utility that does with master.cf what postconf(1) does with main.cf. In particular it supports: postmast- show all entries in a machine-parseable normal form postmast -n- show non-default entries postmast -d - show default entries postmast -e - edit or add master.cf entries via CLI. I don't whether this is of sufficiently broad utility to warrant inclusion in the official release. It gets a Thumbs Up from me. Perhaps a link similar to the postfinger tool might a adequate, although I favor the inclusion concept. The utility uses various Postfix library functions, and builds properly only within the Postfix source distribution, so if not adopted by Wietse, it would be an unofficial patch, and I don't think that releasing it as a patch makes much sense. If the community feels it's useful, perhaps Wietse will adopt it, otherwise it can quitely disappear... -- Viktor.
Re: Upgrade 2.3.3 to 2.8.4 problems
On Sat, Jul 9, 2011 at 8:32 AM, Jeffrey Starin jeffrey.sta...@gmail.com wrote: On 7/9/2011 10:53 AM, Reindl Harald wrote: Am 09.07.2011 16:40, schrieb Jeffrey Starin: NEVER do any source-install over a installed RPM and i guess yu can not remove the rpm-package beause of dependencies the other option would be using a prebuilt RPM even as fedora user i guess there are some for CentOS 5 but they are not included upstream - so you have to trust the builder Thank you! As I'm relatively new to these things when you say take a src.rpm from centOS6 might you mean this? http://pkgs.org/download/centos-6-rhel-6/epel-i386/spamass-milter-postfix-0.3.1-21.el6.noarch.rpm.html I just want to make extra sure I'm getting the right package. Thanks .SRC.rpm NOT .rpm, what you linked is a binary rpm you have to rebuild (recompile) this with rpmbuil --rebuild file.src.rpm but since you want to download spamass-milter-postfix while search for postfix i would recommend let that do somebody who knows a little bit about administration because we can not learn you basic-knowledges on a mailing-list Thank you. You've been more than helpful already. Cheers. Jeffrey: Have the technician read this: http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/ It will walk him through upgrading from 2.3.3 to 2.8.3 on CentOS (which is what I'm guessing your OS is). The same instructions can be used for 2.8.4. SteveJ
