Re: lost connection after CONNECT / SSL_accept error from errors / network_biopair_interop: no inbound mail
On 9/8/2009 3:07 AM, Paul Beard wrote: I am getting no inbound email after locking down the requirements of users to authenticate before sending. I dropped back from current (2.7.*) to 2.6.5. Not having any success getting tcpdump output. The version I have differs from the example in the DEBUG instructions. Complete error messages. Please use cut-and-paste, or use attachments, instead of reciting information from memory. Sep 8 00:45:33 shuttle postfix/smtpd[56335]: lost connection after CONNECT from mail-pz0-f204.google.com[209.85.222.204] Looks like the client disconnected. Test your TLS implementation with openssl s_client -connect IP:port -starttls smtp If you get a 250 DSN or similar message after all the SSL handshake goop, then it worked. maps_rbl_domains = blackholes.mail-abuse.org maps_rbl_domains parameter is deprecated. See the reject_rbl_client command instead. smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit You need permit_sasl_authenticated right after permit_mynetworks. smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated This is a no-op, you can remove it. I don't see an smtpd_recipient_restrictions here. You will need at least: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_tls_loglevel = 3 Everything you may need should be logged at level 1. strict_rfc821_envelopes = yes This may reject legit mail. --master.cf-- smtp inet n - n - 200 smtpd -o content_filter=filter: -o smtpd_tls_wrappermode=yes Ouch! Don't do that! This is likely why the client disconnected; your server was speaking SSL and the client was speaking normal SMTP. It looked like garbage to the client. Wrappermode should only be used on a dedicated port, typically 465 smtps. -o smtpd_sasl_auth_enable=yes Since smtpd_sasl_auth_enable is set in main.cf, no reason to set it here. -- Noel Jones
Re: lost connection after CONNECT / SSL_accept error from errors / network_biopair_interop: no inbound mail
On Tue, Sep 8, 2009 at 8:01 AM, Noel Jones njo...@megan.vbhcs.org wrote: Looks like the client disconnected. Test your TLS implementation with openssl s_client -connect IP:port -starttls smtp If you get a 250 DSN or similar message after all the SSL handshake goop, then it worked. OK, all is well here. maps_rbl_domains = blackholes.mail-abuse.org maps_rbl_domains parameter is deprecated. See the reject_rbl_client command instead. smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit You need permit_sasl_authenticated right after permit_mynetworks. smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated This is a no-op, you can remove it. I don't see an smtpd_recipient_restrictions here. You will need at least: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_recipient_restrictions was there, as specified. So that's alright. smtpd_tls_loglevel = 3 Everything you may need should be logged at level 1. strict_rfc821_envelopes = yes This may reject legit mail. OK, I fixed those. I cranked logging up in vain hope of finding something indicative. --master.cf-- smtp inet n - n - 200 smtpd -o content_filter=filter: -o smtpd_tls_wrappermode=yes Ouch! Don't do that! This is likely why the client disconnected; your server was speaking SSL and the client was speaking normal SMTP. It looked like garbage to the client. Wrappermode should only be used on a dedicated port, typically 465 smtps. Hmm, that's been here forever, but I guess it was obsoleted by the recent authentication changes. Well, it looks like I am seeing some deliveries being logged, so maybe it's fixed. Any idea if I should care about this? Sep 8 08:06:57 shuttle postfix/smtpd[61994]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer I see it's a warning but the only mention I found in the Google was that it was fixed in the next release and that was some time ago. -- Paul Beard / www.paulbeard.org/
Re: lost connection after CONNECT / SSL_accept error from errors / network_biopair_interop: no inbound mail
On Tue, Sep 08, 2009 at 08:20:19AM -0700, paul beard wrote: Any idea if I should care about this? Sep 8 08:06:57 shuttle postfix/smtpd[61994]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer After you turned-off wrapper mode and reloaded or restarted Postfix? In your original report this was a client-server deadlock because you had TLS wrapper mode on port 25, and so the client was waiting for a 220 banner, http://tools.ietf.org/html/rfc5321#section-3.1 while the server was waiting for an SSL client hello. http://tools.ietf.org/html/rfc4346#section-7.4.1.2 -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: lost connection after CONNECT / SSL_accept error from errors / network_biopair_interop: no inbound mail
On 9/8/2009 10:20 AM, paul beard wrote: I don't see an smtpd_recipient_restrictions here. You will need at least: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_recipient_restrictions was there, as specified. So that's alright. Did I miss it in your postconf -n output? If it's not listed in postconf -n, then postfix doesn't see it either. Usually a typo in the parameter name. Any idea if I should care about this? Sep 8 08:06:57 shuttle postfix/smtpd[61994]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer This is logged by the openssl library when a client aborts the SSL handshake. As long as mail (usually) works from clients you want mail from, you can ignore this message. -- Noel Jones
