TLS with openssl-1.0.1a not working with hotmail
FreeBSD-8.2 STABLE Postfix (2.10-20120422) OpenSSL 1.0.1a 19 Apr 2012 I just updated to the latest devel version of Postfix and openssl-1.0.1a. Following the instructions (I think correctly) on this list, I created the following file: cat tls_policy hotmail.com may protocols=!SSLv2:!TLSv1.1:!TLS1.2 I check it as so: postmap -q hotmail.com ./tls_policy may protocols=!SSLv2:!TLSv1.1:!TLS1.2 and placed the following in the main.cf file: smtp_tls_policy_maps = hash:/usr/local/etc/postfix/tls_policy I then rebooted the system. Unfortunately, I am still receiving this error message with hotmail.com Apr 24 08:19:23 scorpio postfix/smtp[7319]: warning: TLS library problem: 7319:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:340: Apr 24 08:19:23 scorpio postfix/smtp[7319]: 3VcNrW1Fdyz2CG4g: to=<**recipient**>, relay=smtp.live.com[65.55.96.11]:587, delay=0.62, delays=0.12/0.14/0.37/0, dsn=4.4.2, status=deferred (lost connection with smtp.live.com[65.55.96.11] while performing the EHLO handshake) I assume I am doing something wrong. This is my compete main.cf file: alias_database = hash:/usr/local/etc/postfix/aliases alias_maps = $alias_database authorized_submit_users = !www, static:all broken_sasl_auth_clients = yes canonical_maps = hash:/usr/local/etc/postfix/canonical command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 12h disable_vrfy_command = yes dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 mail_owner = postfix mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 26214400 milter_default_action = accept mydestination = mydomain = seibercom.net myhostname = scorpio.seibercom.net mynetworks = 127.0.0.0/8 192.168.1.101 mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix recipient_delimiter = + sample_directory = /usr/local/etc/postfix sender_dependent_relayhost_maps = mysql:/usr/local/etc/postfix/mysql-sender_relay sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = mysql:/usr/local/etc/postfix/mysql-sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtp_tls_CApath = /usr/local/etc/postfix/certs/ smtp_tls_note_starttls_offer = yes smtp_tls_policy_maps = hash:/usr/local/etc/postfix/tls_policy smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_tls_session_cache smtpd_authorized_verp_clients = $mynetworks smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_client_restrictions = reject_unauth_pipelining permit_sasl_authenticated reject_unknown_client_hostname smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_recipient_restrictions = reject_unauth_pipelining permit_sasl_authenticated permit_mynetworks reject_unknown_recipient_domain reject_unauth_destination smtpd_reject_footer = For assistance, please provide the following information in your problem report: time ($localtime), client ($client_address) and server ($server_name). smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtpd_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtpd_tls_cert_file = /usr/local/etc/postfix/certs/postfix-cert.pem smtpd_tls_key_file = /usr/local/etc/postfix/certs/postfix-key.pem smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom transport_maps = mysql:/usr/local/etc/postfix/mysql-transport unknown_local_recipient_reject_code = 550 virtual_gid_maps = static:1002 virtual_mailbox_base = /var/mail/vhost virtual_mailbox_domains = mysql:/usr/local/etc/postfix/mysql-domains virtual_mailbox_maps = mysql:/usr/local/etc/postfix/mysql-vmailbox virtual_minimum_uid = 100 virtual_transport = dovecot virtual_uid_maps = static:1002 -- 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: TLS with openssl-1.0.1a not working with hotmail
Jerry: > FreeBSD-8.2 STABLE > Postfix (2.10-20120422) > OpenSSL 1.0.1a 19 Apr 2012 > > I just updated to the latest devel version of Postfix and openssl-1.0.1a. Just to be sure, what is the output from: $ ldd /usr/libexec/postfix/smtp I did the Postfix testing between FreeBSD 8.2 with OpenSSL 1.0.1a from ports, and FreeBSD 9.0 with OpenSSL 1.0.1a statically-linked, and the two installs did speak TLSv1.1 and TLSv1.2 as expected. Wietse
Re: TLS with openssl-1.0.1a not working with hotmail
On Tue, 24 Apr 2012 09:08:16 -0400 (EDT) Wietse Venema articulated: >Jerry: >> FreeBSD-8.2 STABLE >> Postfix (2.10-20120422) >> OpenSSL 1.0.1a 19 Apr 2012 >> >> I just updated to the latest devel version of Postfix and >> openssl-1.0.1a. > >Just to be sure, what is the output from: > >$ ldd /usr/libexec/postfix/smtp > >I did the Postfix testing between FreeBSD 8.2 with OpenSSL 1.0.1a >from ports, and FreeBSD 9.0 with OpenSSL 1.0.1a statically-linked, >and the two installs did speak TLSv1.1 and TLSv1.2 as expected. This doesn't look good: ldd /usr/libexec/postfix/smtp ldd: /usr/libexec/postfix/smtp: No such file or directory However: $ ldd /usr/local/libexec/postfix/smtp /usr/local/libexec/postfix/smtp: libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80069c000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x8007f3000) libpam.so.5 => /usr/lib/libpam.so.5 (0x80090e000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800a16000) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800b2f000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800c93000) libdb-4.8.so.0 => /usr/local/lib/libdb-4.8.so.0 (0x800f54000) libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x8011c3000) libz.so.5 => /lib/libz.so.5 (0x8015fc000) libm.so.5 => /lib/libm.so.5 (0x801711000) libc.so.7 => /lib/libc.so.7 (0x801831000) libthr.so.3 => /lib/libthr.so.3 (0x801a6f000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x801b88000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801d96000) -- 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
Fw: [SPAM] Someone is harassing my smtp.
- Original Message -
From: "Marko Weber"
To: "Olivier Pavilla"
Cc: "Postfix Users"
Sent: Monday, April 23, 2012 11:45 AM
Subject: Re: [SPAM] Someone is harassing my smtp.
Am 23.04.2012 06:50, schrieb Olivier Pavilla:
Hi everyone.
For several months my smtp is harassing by someone located in Taiwan.
This people is using any taiwanese IP.
My logs are ful with this something like this:
Apr 23 06:35:31 corellia postfix/smtpd[26906]: NOQUEUE: reject: RCPT
from unknown[113.116.186.27]: 554 5.7.1 : Recipient
address rejected: Relay access denied; from=
to= proto=ESMTP helo=
Apr 23 06:35:31 corellia postfix/smtpd[26906]: warning: restriction
`reject_unauth_destination' after `check_relay_domains' is ignored
hello,
inetnum:113.112.0.0 - 113.119.255.255
netname:CHINANET-GD
descr: CHINANET Guangdong province network
descr: Data Communication Division
descr: China Telecom
country:CN
i get on whois. so its china not taiwain ?
At least blocking all of Taiwanese IPs. Does anyone has idea to counter
strike this people?
yes maybe,
stevan bajic showd me some ffective way to do this with fail2ban.
You can use "fail2ban" on Postfix, its just some modification:
In /etc/fail2ban/jail.conf do this:
[postfix-attack]
enabled = true
filter = yourdomain-postfix-attack
action = iptables-multiport[name=Postfix-Attacks,
port="smtp,ssmtp", protocol=tcp]
logpath = /var/log/messages
ignoreip= 127.0.0.1 xx.xxx.xxx.xxx/32
bantime = 240
maxretry= 3
In /etc/fail2ban/filter.d/yourdomain-postfix-attack.conf do this:
# Fail2Ban configuration file
#
# Author: Stevan Bajic
#
# $Revision: 1 $
#
[Definition]
# Option: failregex
# Notes.: regex to match various bad conditions for Postfix in the
logfile. The
# host must be matched by a group named "host". The tag ""
can
# be used for standard IP/hostname matching and is only an alias
for
# (?:::f{4,6}:)?(?P\S+)
# Values: TEXT
#
failregex =
postfix/smtpd\[\d+\]:\s+warning:\s+Connection\s+rate\s+limit\s+exceeded:\s+[^\[]+\[\]\s+for\s+service\s+smtp$
postfix/smtpd\[\d+\]:\s+(NOQUEUE:\s+)?reject:\s+(RCPT|HELO|EHLO|MAIL)\s+from\s+[^\[]+\[\]:\s+(55[034]\s+|450\s+.*Client\s+host\s+rejected:\s+cannot\s+find\s+your\s+reverse\s+hostname|451\s+(4\.3\.5\s+)?Server\s+configuration\s+error\;\s+from=<.*>\s+to=<.*>\s+proto=.*\s+e?helo=<.*>\s*$|(55[04]|421)\s+[^:]+:\s+Recipient\s+address\s+rejected:\s+)
postfix/smtpd\[\d+\]:\s+lost\s+connection\s+after\s+\w\s+from\s+[^\[]+\[\]$
postfix/smtpd\[\d+\]:\s+warning:\s+:\s+hostname[^\s]+\s+verification\s+failed:\s+No\s+address\s+associated\s+with\s+hostname$
postfix/smtpd\[\d+\]:\s+lost\s+connection\s+after\s+DATA\s+\(0\s+bytes\)\s+from\s+[^\[]*\[\]$
postfix/smtpd\[\d+\]:\s+too\s+many\s+errors\s+after\s+RCPT\s+from\s+[^\[]*\[\]$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
you have to modify maybe the logpath in the above jail.conf by "logpath".
Further, you can use "sqlgrey" or any other greylisting i think.
Maybe u have a look on "sqlgrey".
U can also use POSTSCREEN at the begin of the chain. Postscreen is very
good documented on postifx.org and well here in the list.
hope this helps you out a bit.
greetz from hamburg
marko
--
Olivier Pavilla
http://www.linux-squad.com
"Les fautes d'orthographes de mes propos sont sous licence Ane bâté 1.0"
Tell me about you're not alone for being swamped by this fools. Once upon
time i ban ip ranges from china, taiwan, romania, czech and brazil. It will
decrease the abuse with about 50% but nor anything i would recommend though.
A more prudent way to get rid of some of this in an early stage is to turn
on reject_unkown_client, and what I've done for a while and it is really
effective. A word of caution due it can cause problems to your clients.
Andreas
Re: TLS with openssl-1.0.1a not working with hotmail
Jerry: > $ ldd /usr/local/libexec/postfix/smtp > /usr/local/libexec/postfix/smtp: ... > libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800b2f000) > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800c93000) That looks like the right OpenSSL version. Can you connect from the same FreeBSD box to the same hotmail server with "openssl s_client"? $ openssl s_client -starttls smtp -connect 65.55.96.11:25 Somewhere in the output will be a protocol version, something like: SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 If "openssl s_client" fails, try adding the protocol: $ openssl s_client -tls1 ... Meanwhile I'll set up openssl-1.01a on a box that has access to remote port 25. Wietse
content filter
hi guys! i have a content filter script that receives _only_ the body part of the message, not the headers. i would like to use it like this: http://www.postfix.org/FILTER_README.html is there a simple way to pass only the body to the script? thanks in advance, evelio vila
Re: content filter
On 4/24/2012 9:33 AM, Evelio VILA wrote: > hi guys! > > i have a content filter script that receives _only_ the body part of the > message, not the headers. i would like to use it like this: > > http://www.postfix.org/FILTER_README.html > > is there a simple way to pass only the body to the script? > > > > thanks in advance, > evelio vila > No, postfix always passes the entire message to a content_filter, there is no option to pass random parts. -- Noel Jones
milter and restriction classes
Is it possible to put the use of a smtpd_milter into a restriction class? From what I've read so far I'm suspect the answer is no. In which case I'll have to put the functionality into the milter itself, MIMEDefang in my case. I'd prefer to keep the restriction classes "centralized" if you will within Postfix, but I want the functionality more than the centralized part. :) Thank you, Chad
Re: TLS with openssl-1.0.1a not working with hotmail
On Tue, 24 Apr 2012 10:21:32 -0400 (EDT) Wietse Venema articulated: >Jerry: >> $ ldd /usr/local/libexec/postfix/smtp >> /usr/local/libexec/postfix/smtp: >... >> libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800b2f000) >> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800c93000) > >That looks like the right OpenSSL version. > >Can you connect from the same FreeBSD box to the same hotmail server >with "openssl s_client"? > >$ openssl s_client -starttls smtp -connect 65.55.96.11:25 > >Somewhere in the output will be a protocol version, something like: > >SSL-Session: > Protocol : TLSv1 > Cipher: RC4-MD5 > >If "openssl s_client" fails, try adding the protocol: > > $ openssl s_client -tls1 ... > >Meanwhile I'll set up openssl-1.01a on a box that has >access to remote port 25. New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA The entire output is: $ openssl s_client -starttls smtp -connect 65.55.96.11:25 CONNECTED(0003) depth=2 CN = Microsoft Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/CN=smtp.live.com i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority 1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority i:/CN=Microsoft Internet Authority 2 s:/CN=Microsoft Internet Authority i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -BEGIN CERTIFICATE- MIIF1DCCBLygAwIBAgIKaFbF6wAIAAIDTDANBgkqhkiG9w0BAQUFADCBizETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIG CgmSJomT8ixkARkWBGNvcnAxFzAVBgoJkiaJk/IsZAEZFgdyZWRtb25kMSowKAYD VQQDEyFNaWNyb3NvZnQgU2VjdXJlIFNlcnZlciBBdXRob3JpdHkwHhcNMTEwMzMw MjIzNDAyWhcNMTMwMzI5MjIzNDAyWjAYMRYwFAYDVQQDEw1zbXRwLmxpdmUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjGxU92NJ0KORM2WGRdd9 nAwQqyRuZT4m1SeNe1Ds4ti9nPCmhcvPDYuWA0BkNLoIXQnVzASHycIeYSbM1iJN lO1btDUUnXh6fZSUZCwHi9D1pVshxrXsJ7n8J3UtHF+Ct3Cg1/6gRL6WfL9hmptE G0k9K6J3xp9rzfIBygtSIYo/nGQwLWRHPJnrR58JHOGXqi98B244n7GbyKXUGyDT WTk4YMHkIVMNIgLOhMaFD9jVhGSvXWdMSwCqpIIrWu9/godYGxqC8U4RkxeEYBOQ GV/hojmn/I8szJyFTqCZAB562WJnqwwEDW82U7BkK7mAdIC1J9gcuaNCjysvz4+o OQIDAQABo4ICqjCCAqYwPwYJKwYBBAGCNxUHBDIwMAYoKwYBBAGCNxUIg8+JTa3y AoWhnwyC+sp9geH7dIFPg8LthQiOqdKFYwIBZAIBCjAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwEwCwYDVR0PBAQDAgSwMCcGCSsGAQQBgjcVCgQaMBgwCgYI KwYBBQUHAwIwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFMn0iI49Zjq0gJYP/6Zh091V 5CeEMB8GA1UdIwQYMBaAFAhC49tOEWbztQjFQNtVfDNGEYM4MIIBCgYDVR0fBIIB ATCB/jCB+6CB+KCB9YZYaHR0cDovL21zY3JsLm1pY3Jvc29mdC5jb20vcGtpL21z Y29ycC9jcmwvTWljcm9zb2Z0JTIwU2VjdXJlJTIwU2VydmVyJTIwQXV0aG9yaXR5 KDgpLmNybIZWaHR0cDovL2NybC5taWNyb3NvZnQuY29tL3BraS9tc2NvcnAvY3Js L01pY3Jvc29mdCUyMFNlY3VyZSUyMFNlcnZlciUyMEF1dGhvcml0eSg4KS5jcmyG QWh0dHA6Ly9jb3JwcGtpL2NybC9NaWNyb3NvZnQlMjBTZWN1cmUlMjBTZXJ2ZXIl MjBBdXRob3JpdHkoOCkuY3JsMIG/BggrBgEFBQcBAQSBsjCBrzBeBggrBgEFBQcw AoZSaHR0cDovL3d3dy5taWNyb3NvZnQuY29tL3BraS9tc2NvcnAvTWljcm9zb2Z0 JTIwU2VjdXJlJTIwU2VydmVyJTIwQXV0aG9yaXR5KDgpLmNydDBNBggrBgEFBQcw AoZBaHR0cDovL2NvcnBwa2kvYWlhL01pY3Jvc29mdCUyMFNlY3VyZSUyMFNlcnZl ciUyMEF1dGhvcml0eSg4KS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAIfSKo0Q3ilH 8I725bZHASbscVaAMB7hnkvhZhfnQirrdKwc121Idj6jiALacSdRy5mQ09OZA3j6 omz1BvHoIx+jxE3zsLeSraHdwA5A1srRc3cXwl7qHbhgZEJsY/wANLLxoZk0nse5 WJI7wBeypAnATgb7DF0++QxOfOj5VV4GrSvcO+lQ0abSCI8gJRAcI58fjFj0yGkE LPSw1QMa5IANfnO7TuTlyBs75qhIew7TFM5Rnu7thW+wuKGLeFpXYsVLeZoWPlfe yTsAqYF5BADhsB+Vc1Lzv2RA6MfrS3UrP1enpXVlNwnB8+LxW9X01gpX2m/Ql/4j 4DeDko8OMGw= -END CERTIFICATE- subject=/CN=smtp.live.com issuer=/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority --- No client certificate CA names sent --- SSL handshake has read 4881 bytes and written 675 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DES-CBC3-SHA Session-ID: 5F0EE79C81128490E44FF015B884CDFBD04609B30BC19813195B3C8ECA84 Session-ID-ctx: Master-Key: 9EF71DE096C86138838E0FE74CA391BBD9579E5F7B577B8061B1351B52996742E2D6916B663BB3DD3A5168C4E166D6E0 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1335280936 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- 250 OK When adding the "-tls1" flag: New, TLSv1/SSLv3, Cipher is RC4-MD5 The entire output: $ openssl s_client -starttls smtp -connect 65.55.96.11:25 -tls1 CONNECTED(0003) depth=2 CN = Microsoft Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/CN=smtp.live.com i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority 1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority i:/CN=Microsoft Internet Authority 2 s:/CN=Mic
Re: TLS with openssl-1.0.1a not working with hotmail
Jerry: > FreeBSD-8.2 STABLE > Postfix (2.10-20120422) > OpenSSL 1.0.1a 19 Apr 2012 > > I just updated to the latest devel version of Postfix and openssl-1.0.1a. > > Following the instructions (I think correctly) on this list, I created the > following file: > > cat tls_policy > hotmail.com may protocols=!SSLv2:!TLSv1.1:!TLS1.2 > > I check it as so: > > postmap -q hotmail.com ./tls_policy > may protocols=!SSLv2:!TLSv1.1:!TLS1.2 TLS1.2 is an invalid protocol name. Postfix will not send STARTTLS, disconnect, and make a plaintext connection if permitted. Apr 24 11:11:27 spike postfix/smtp[19134]: warning: 65.55.96.11[65.55.96.11]:25: Invalid TLS protocol list "!SSLv2:!TLSv1.1:!TLS1.2": aborting TLS session So your logs don't match the configuration. I have verified that Postfix + OpenSSL 1.0.1a fails to communicate with 65.55.96.11 with "default" settings, but succeeds when I disable TLSv1.2 (with smtp_tls_policy_maps or with smtp_tls_protocols). If you can't make it work with the policy table, simply specify in main.cf: smtp_tls_protocols = !SSLv2,!TLSv1.2 smtp_tls_mandatory_protocols = !SSLv2,!TLSv1.2 I don't see STARTTLS support on the MX hosts for hotmail.com, so I wonder why you ended up talking to 65.55.96.11. Wietse
Re: milter and restriction classes
On 4/24/2012 10:20 AM, Chad M Stewart wrote: > > Is it possible to put the use of a smtpd_milter into a restriction class? No, the milter connection happens before postfix knows anything about the client. -- Noel Jones
Re: TLS with openssl-1.0.1a not working with hotmail
On Tue, 24 Apr 2012 11:34:11 -0400 (EDT) Wietse Venema articulated: >Jerry: >> FreeBSD-8.2 STABLE >> Postfix (2.10-20120422) >> OpenSSL 1.0.1a 19 Apr 2012 >> >> I just updated to the latest devel version of Postfix and >> openssl-1.0.1a. >> >> Following the instructions (I think correctly) on this list, I >> created the following file: >> >> cat tls_policy >> hotmail.com may protocols=!SSLv2:!TLSv1.1:!TLS1.2 >> >> I check it as so: >> >> postmap -q hotmail.com ./tls_policy >> may protocols=!SSLv2:!TLSv1.1:!TLS1.2 > >TLS1.2 is an invalid protocol name. Postfix will not send STARTTLS, >disconnect, and make a plaintext connection if permitted. > >Apr 24 11:11:27 spike postfix/smtp[19134]: warning: > 65.55.96.11[65.55.96.11]:25: Invalid TLS protocol list > "!SSLv2:!TLSv1.1:!TLS1.2": aborting TLS session > >So your logs don't match the configuration. I got those setting from your email to the list: However, it may be better to disable the new protocols for broken sites only, with smtp_tls_policy_maps entries. /etc/postfix/main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/postfix/tls_policy: example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2 I did screw it up, I left out the "v"in the "TLSv1.2" protocol name. However, even changing that did not make any difference. >I have verified that Postfix + OpenSSL 1.0.1a fails to communicate >with 65.55.96.11 with "default" settings, but succeeds when I disable >TLSv1.2 (with smtp_tls_policy_maps or with smtp_tls_protocols). > >If you can't make it work with the policy table, simply specify in >main.cf: > >smtp_tls_protocols = !SSLv2,!TLSv1.2 >smtp_tls_mandatory_protocols = !SSLv2,!TLSv1.2 This works fine for me. I fail to understand why the policy map fails however. >I don't see STARTTLS support on the MX hosts for hotmail.com, so I >wonder why you ended up talking to 65.55.96.11. No idea. Thanks for your help. -- 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
Does Cleanup (or something) change message body line endings?
Good afternoon, I've just been troubleshooting an issue with the php mail() function and Postfix. Keeping it short and to the point it appears that DKIM can be broken because something (assuming Cleanup) changes the line endings in the body section of the mail after it has been signed. What I noticed (eventually.) was that text areas in forms submitted to a PHP script contained line endings \r\n. These were passed through to the Postfix sendmail implementation care of the php mail() function where it went: pickup,cleanup,qmgr,smtp,smtpd,smtp before going into: dkimproxy.out Then, after signing it went: cleanup,qmgr,smtp But by the time it arrived with the recipient the body had changed (not apparent to the eye) and this was happening: dkim=neutral (body hash did not verify) Now, if I manually strip the line endings \r\n and replace them a plain newline \n, it works perfectly suggesting something strips the line endings if the are \r\n after it has been signed. Initially I thought 'it won't be Postfix doing this' and I checked: http://www.postfix.org/cleanup.8.html to make sure it was not documented. The only fly in the ointment of that train of thought was another Postfix that I tested against (so I had Postfix to Postfix) where I got: (amavisd-new); dkim=softfail (fail, message has been altered) It's not a big issue, it's easy to filter out the spurious \r coming in from PHP, but I'd just like to know for my own piece of mind that I'm not going mad and that something is doing a little house-keeping here? Thank you, in advance, for any replies.
Re: TLS with openssl-1.0.1a not working with hotmail
Jerry: > /etc/postfix/tls_policy: > example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2 > > > I did screw it up, I left out the "v"in the "TLSv1.2" protocol name. > However, even changing that did not make any difference. This confirms that Postfix never found the entry in your SMTP TLS policy table (otherwise it would have complained about "TLS1.2"). > >smtp_tls_protocols = !SSLv2,!TLSv1.2 > >smtp_tls_mandatory_protocols = !SSLv2,!TLSv1.2 > > This works fine for me. I fail to understand why the policy map fails > however. I used both main.cf and SMTP TLS policy table settings. However, the SMTP TLS policy table "lookup key" field needs to match the "next-hop" destination that is given to the Postfix SMTP client. If you override the destination with transport maps, per-sender relayhost, etc., then the "lookup key" field needs to match the override. Wietse
Re: Does Cleanup (or something) change message body line endings?
Sam Jones: > Now, if I manually strip the line endings \r\n and replace them a plain > newline \n, it works perfectly suggesting something strips the line > endings if the are \r\n after it has been signed. This happens when you use an old Postfix version AND have MIXED line endings (some lines end in , other lines end in ). Two solutions: A) Use consistent line endings: ALL lines end in , or ALL lines end in . B) Upgrade to a Postfix 2.9 or later that strips regardless. as described in the manpage entry below. Wietse sendmail_fix_line_endings (default: always) Controls how the Postfix sendmail command converts email message line endings from into UNIX format (). always Always convert message lines ending in . This setting is the default with Postfix 2.9 and later. strict Convert message lines ending in only if the first input line ends in . This setting is backwards-compatible with Postfix 2.8 and earlier. never Never convert message lines ending in . This setting exists for completeness only. This feature is available in Postfix 2.9 and later.
Re: Does Cleanup (or something) change message body line endings?
On Tue, Apr 24, 2012 at 12:58:29PM -0400, Wietse Venema wrote: > > B) Upgrade to a Postfix 2.9 or later that strips regardless. > as described in the manpage entry below. I'm surprised that such a basic aspect of mail processing is changing at such a late date. What caused you to introduce this change? Thanks, -- Ben Rosengart "Like all those possessing a library, Sendmail, Inc. Aurelian was aware that he was guilty of +1 718 431 3822 not knowing his in its entirety [...]" -- Jorge Luis Borges NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Re: Does Cleanup (or something) change message body line endings?
Ben Rosengart: > On Tue, Apr 24, 2012 at 12:58:29PM -0400, Wietse Venema wrote: > > > > B) Upgrade to a Postfix 2.9 or later that strips regardless. > > as described in the manpage entry below. > > I'm surprised that such a basic aspect of mail processing is changing > at such a late date. What caused you to introduce this change? When Postfix was released, there was no need to accomodate buggy mail applications like there is today. Wietse
Re: TLS with openssl-1.0.1a not working with hotmail
On Tue, 24 Apr 2012 12:51:16 -0400 (EDT) Wietse Venema articulated: >Jerry: >> /etc/postfix/tls_policy: >> example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2 >> >> >> I did screw it up, I left out the "v"in the "TLSv1.2" protocol name. >> However, even changing that did not make any difference. > >This confirms that Postfix never found the entry in your SMTP TLS >policy table (otherwise it would have complained about "TLS1.2"). > >> >smtp_tls_protocols = !SSLv2,!TLSv1.2 >> >smtp_tls_mandatory_protocols = !SSLv2,!TLSv1.2 >> >> This works fine for me. I fail to understand why the policy map fails >> however. > >I used both main.cf and SMTP TLS policy table settings. > >However, the SMTP TLS policy table "lookup key" field needs to match >the "next-hop" destination that is given to the Postfix SMTP client. > >If you override the destination with transport maps, per-sender >relayhost, etc., then the "lookup key" field needs to match the >override. Thanks Wietse. It took me a while before I realized that I had to use: [smtp.live.com] as the key in the "tls_policy" file in order to get it to work. I was not using the "[ ]" brackets and it therefore was not working correctly. That also explains why I never received a warning message since the key was never found. -- 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: Does Cleanup (or something) change message body line endings?
On Tue, 2012-04-24 at 12:58 -0400, Wietse Venema wrote: > Sam Jones: > > Now, if I manually strip the line endings \r\n and replace them a plain > > newline \n, it works perfectly suggesting something strips the line > > endings if the are \r\n after it has been signed. > > This happens when you use an old Postfix version AND have MIXED > line endings (some lines end in , other lines end in ). > > Two solutions: > > A) Use consistent line endings: ALL lines end in , or ALL lines > end in . > > B) Upgrade to a Postfix 2.9 or later that strips regardless. > as described in the manpage entry below. > > Wietse > > sendmail_fix_line_endings (default: always) >Controls how the Postfix sendmail command converts email message line >endings from into UNIX format (). > >always Always convert message lines ending in . This setting is > the default with Postfix 2.9 and later. > >strict Convert message lines ending in only if the first input > line ends in . This setting is backwards-compatible with > Postfix 2.8 and earlier. > >never Never convert message lines ending in . This setting > exists for completeness only. > >This feature is available in Postfix 2.9 and later. Thanks for the response, that's perfect. For a moment I really thought I was going quite mad and at least now I know. Totally agree that this is not a Postfix issue as such. I had clearly failed to spot that the Textarea inputs was giving \r\n and filter it. Again, thank you for your time.
Fw: Does Cleanup (or something) change message body line endings?
- Original Message - From: "Sam Jones" To: Sent: Tuesday, April 24, 2012 6:23 PM Subject: Does Cleanup (or something) change message body line endings? Good afternoon, I've just been troubleshooting an issue with the php mail() function and Postfix. Keeping it short and to the point it appears that DKIM can be broken because something (assuming Cleanup) changes the line endings in the body section of the mail after it has been signed. What I noticed (eventually.) was that text areas in forms submitted to a PHP script contained line endings \r\n. These were passed through to the Postfix sendmail implementation care of the php mail() function where it went: pickup,cleanup,qmgr,smtp,smtpd,smtp before going into: dkimproxy.out Then, after signing it went: cleanup,qmgr,smtp But by the time it arrived with the recipient the body had changed (not apparent to the eye) and this was happening: dkim=neutral (body hash did not verify) Now, if I manually strip the line endings \r\n and replace them a plain newline \n, it works perfectly suggesting something strips the line endings if the are \r\n after it has been signed. Initially I thought 'it won't be Postfix doing this' and I checked: http://www.postfix.org/cleanup.8.html to make sure it was not documented. The only fly in the ointment of that train of thought was another Postfix that I tested against (so I had Postfix to Postfix) where I got: (amavisd-new); dkim=softfail (fail, message has been altered) It's not a big issue, it's easy to filter out the spurious \r coming in from PHP, but I'd just like to know for my own piece of mind that I'm not going mad and that something is doing a little house-keeping here? Thank you, in advance, for any replies. just curious, why you are behind Yahoo with an internal ip?
OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.9.2.html] Postfix stable release 2.9.2, and legacy releases 2.8.10, 2.7.9, 2.6.15 are available. They contains workarounds that are already part of Postfix 2.10. These releases add support to turn off the TLSv1.1 and TLSv1.2 protocols. Introduced with OpenSSL version 1.0.1, these protocols are known to cause inter-operability problems, for example with some hotmail services. The radical workaround is to temporarily turn off problematic protocols globally: /etc/postfix/main.cf: smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 However, it may be better to temporarily turn off problematic protocols for broken sites only: /etc/postfix/main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/postfix/tls_policy: example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2 Notes: * Note the use of ":" instead of comma or space. Also, note that there is NO space around the "=" in "protocols=". * The smtp_tls_policy_maps lookup key must match the "next-hop" destination that is given to the Postfix SMTP client. If you override the next-hop destination with transport_maps, relayhost, sender_dependent_relayhost_maps, or otherwise, you need to specify the same destination for the smtp_tls_policy_maps lookup key. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: OpenSSL 1.0.1 protocol selection support
* Wietse Venema : > Based on input from Victor I'll put out a 2.10 development release > that makes the minimum changes to support the new OpenSSL protocols. > This may then be back-ported to earlier Postfix releases if needed. > > Meanwhile, Victor will start work on future-proofing Postfix, such > that it will be prepared for future OpenSSL releases that introduce > new features that Postfix doesn't know about. That code will most > likely be fielded as a non-production release, followed by regular > development releases. I wonder if that was the reason for my STARTTLS problems (where I couldn't send to several M$ systems, since they always stopped answering after STARTTLS was established): Date: Thu, 12 Apr 2012 12:48:36 +0200 Subject: STARTTLS problems -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: STARTTLS problems
Ralf Hildebrandt:
> @charite were suddenly encountering several domains that don't seem to
> implement STARTTLS properly.
>
> mailq exhibits the following behaviour:
>
> 3VRgn515L4zKg2v 443924 Tue Apr 10 10:01:13 sen...@charite.de
> (lost connection with mail2.trioncology.org[81.252.237.162] while sending
> RCPT TO)
>recipi...@trioncology.org
Fails with OpenSSL 1.0.1a with default setting ("smtp_tls_protocols = !SSLv2"):
Apr 24 19:25:33 spike postfix/smtp[28601]: 3Vcgd83t7Szk2RQ:
to=,
relay=81.252.237.162[81.252.237.162]:25, delay=1.4,
delays=0.2/0.01/1.2/0, dsn=4.4.2, status=undeliverable (lost
connection with 81.252.237.162[81.252.237.162] while sending
MAIL FROM)
Works with OpenSSL 1.0.1a with "smtp_tls_protocols = !TLSv1.2":
Apr 24 19:27:13 spike postfix/smtp[28813]: 3Vcgg33fZ5zk2RQ:
to=,
relay=81.252.237.162[81.252.237.162]:25, delay=1.9,
delays=0.21/0.01/1.2/0.48, dsn=5.7.1, status=undeliverable (host
81.252.237.162[81.252.237.162] said: 550 5.7.1 Unable to relay
for postmaster@[81.252.237.162] (in reply to RCPT TO command))
So, TLSv1.2 is giving trouble.
> 3VRkVt1QCQz1tpC 713456 Tue Apr 10 12:04:06 sen...@charite.de
> (lost connection with mail.seronosymposia.org[77.43.17.211] while sending
> MAIL FROM)
>recipi...@seronosymposia.org
Same result as above.
Fails with OpenSSL 1.0.1a with default setting ("smtp_tls_protocols = !SSLv2"):
Apr 24 19:31:25 spike postfix/smtp[29208]: 3Vcglv1jQVzk2RQ:
to=, relay=77.43.17.211[77.43.17.211]:25,
delay=2, delays=0.21/0.01/1.7/0, dsn=4.4.2, status=undeliverable
(lost connection with 77.43.17.211[77.43.17.211] while sending
MAIL FROM)
Works with OpenSSL 1.0.1a with "smtp_tls_protocols = !TLSv1.2":
Apr 24 19:32:02 spike postfix/smtp[29314]: 3VcgmV6bhxzk2RQ:
to=, relay=77.43.17.211[77.43.17.211]:25,
delay=7.2, delays=0.2/0.01/1.7/5.2, dsn=5.7.1, status=undeliverable
(host 77.43.17.211[77.43.17.211] said: 550 5.7.1 Unable to relay
for postmaster@[77.43.17.211] (in reply to RCPT TO command))
So it is a good thing that I put out those updates today.
Which leaves me wondering how other MTAs deal with this. Given the
way OpenSSL works, there is no way for a program to specify what
TLS protocols it wants to use. Instead, a program can only specify
what TLS protocols it does not want. This means that new code needs
to be added whenever a new protocol is added to OpenSSL, otherwise
that protocol can't be turned off.
Wietse
Re: OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
On Tue, Apr 24, 2012 at 05:01:29PM -0400, Wietse Venema wrote: > [An on-line version of this announcement will be available at > http://www.postfix.org/announcements/postfix-2.9.2.html] > > Postfix stable release 2.9.2, and legacy releases 2.8.10, 2.7.9, > 2.6.15 are available. They contains workarounds that are already > part of Postfix 2.10. > > These releases add support to turn off the TLSv1.1 and TLSv1.2 > protocols. Introduced with OpenSSL version 1.0.1, these protocols > are known to cause inter-operability problems, for example with > some hotmail services. > > The radical workaround is to temporarily turn off problematic > protocols globally: > > /etc/postfix/main.cf: > smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 > smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 > > smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 > smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2 > > However, it may be better to temporarily turn off problematic > protocols for broken sites only: > > /etc/postfix/main.cf: > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > > /etc/postfix/tls_policy: > example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2 > > Notes: > > * Note the use of ":" instead of comma or space. Also, note that > there is NO space around the "=" in "protocols=". > > * The smtp_tls_policy_maps lookup key must match the "next-hop" > destination that is given to the Postfix SMTP client. If you > override the next-hop destination with transport_maps, relayhost, > sender_dependent_relayhost_maps, or otherwise, you need to > specify the same destination for the smtp_tls_policy_maps lookup > key. > > You can find the updated Postfix source code at the mirrors listed > at http://www.postfix.org/. > > Wietse Just tried to compile 2.9.2 and here is what I get: Script started on Tue Apr 24 17:36:38 2012 doctor.nl2k.ab.ca//usr/source/postfix-2.9.2$ less configpf [?1h=[55;1H[Kmake tidy; make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -I/usr/contrib/include/ -I/usr/contrib/include/sasl" AUXLIBS="-L/usr/lib/ -ldb- 5.3 -L/usr/contrib/lib -lsasl2 -lssl -lcrypto" [55;1H[K[7mconfigpf (END)[m[55;1H[K[?1l>doctor.nl2k.ab.ca//usr/source/postfix-2.9.2$ make set -e; for i in src/util src/global src/dns src/tls src/xsasl src/milter src/master src/postfix src/fsstone src/smtpstone src/sendmail src/error src/pickup src/cleanup src/smtpd src/local src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop src/postkick src/postlock src/postlog src/postmap src/postqueue src/postsuper src/qmqpd src/spawn src/flush src/verify src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr src/postmulti src/postscreen src/dnsblog src/tlsproxy; do (set -e; echo "[$i]"; cd $i; make 'CC=gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DUSE_TLS -I/usr/include -I/usr/contrib/include/ -I/usr/contrib/include/sasl -DHAS_PCRE' update MAKELEVEL=) || exit 1; done [src/util] for i in argv.h attr.h attr_clnt.h auto_clnt.h base64_code.h binhash.h chroot_uid.h cidr_match.h clean_env.h connect.h ctable.h dict.h dict_cdb.h dict_cidr.h dict_db.h dict_dbm.h dict_env.h dict_ht.h dict_ni.h dict_nis.h dict_nisplus.h dict_pcre.h dict_regexp.h dict_sdbm.h dict_static.h dict_tcp.h dict_unix.h dir_forest.h events.h exec_command.h find_inet.h fsspace.h fullname.h get_domainname.h get_hostname.h hex_code.h hex_quote.h host_port.h htable.h inet_addr_host.h inet_addr_list.h inet_addr_local.h inet_proto.h iostuff.h line_wrap.h listen.h lstat_as.h mac_expand.h mac_parse.h make_dirs.h mask_addr.h match_list.h msg.h msg_output.h msg_syslog.h msg_vstream.h mvect.h myaddrinfo.h myflock.h mymalloc.h myrand.h name_code.h name_mask.h netstring.h nvtable.h open_as.h open_lock.h percentm.h posix_signals.h readlline.h ring.h safe.h safe_open.h sane_accept.h sane_connect.h sane_fsops.h sane_socketpair.h sane_time.h scan_dir.h set_eugid.h set_ugid.h sigdelay.h sock_addr.h spawn_command.h split_at.h stat_as.h stringops.h sys_defs.h timed_connect.h timed_wait.h trigger.h username.h valid_hostname.h vbuf.h vbuf_print.h vstream.h vstring.h vstring_vstream.h watchdog.h format_tv.h load_file.h killme_after.h edit_file.h dict_cache.h dict_thash.h ip_match.h nbbio.h base32_code.h dict_fail.h warn_stat.h; do cmp -s $i ../../include/$i 2>/dev/null || cp $i ../../include; done cd ../../include; chmod 644 argv.h attr.h attr_clnt.h auto_clnt.h base64_code.h binhash.h chroot_uid.h cidr_match.h clean_env.h connect.h ctable.h dict.h dict_cdb.h dict_cidr.h dict_db.h dict_dbm.h dict_env.h dict_ht.h dict_ni.h dict_nis.h dict_nisplus.h dict_pcre.h dict_regexp.h dict_sdbm.h dict_static.h dict_tcp.h dict_unix.h dir_forest.h events.h exec_command.h find_inet.
Re: OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
The Doctor: > gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DUSE_TLS > -I/usr/include -I/usr/contrib/include/ -I/usr/contrib/include/sasl -DHAS_PCRE > -g -O -I. -I../../include -DBSDI4 -c tls_client.c Are you really building Postfix on BSD/OS 4.x? I should start trimming the list of supported configurations; I have not used BSD/OS for more than 10 years. Wietse
Re: OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
On Tue, Apr 24, 2012 at 08:21:05PM -0400, Wietse Venema wrote: > The Doctor: > > gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL > > -DUSE_TLS -I/usr/include -I/usr/contrib/include/ > > -I/usr/contrib/include/sasl -DHAS_PCRE -g -O -I. -I../../include -DBSDI4 -c > > tls_client.c > > Are you really building Postfix on BSD/OS 4.x? I should start > trimming the list of supported configurations; I have not used > BSD/OS for more than 10 years. > Yes. 2.8.X works nicely same with 2.9.0 and 2.9.1 > Wietse -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Alberta! VOTE!
Timeout after DATA with postfix
Hi, I have a few postfix-2.8.7 systems on fedora15 that connect with another postfix-2.8.7 system. I'm receiving the following messages periodically in the logs: Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA (9832 bytes) from mail02.example.com[68.XXX.YYY.45] Apr 24 16:24:43 mailrelay postfix/smtpd[10106]: timeout after DATA (9716 bytes) from mail02.example.com[68.XXX.YYY.45] Apr 24 17:10:21 mailrelay postfix/smtpd[18050]: timeout after DATA (2894 bytes) from mail01.example.com[64.AAA.BBB.5] Apr 24 17:10:21 mailrelay postfix/smtpd[19315]: timeout after DATA (6801 bytes) from mail01.example.com[64.AAA.BBB.5] Apr 24 17:14:44 mailrelay postfix/smtpd[23281]: timeout after DATA (5528 bytes) from mail02.example.com[68.XXX.YYY.45] Apr 24 17:34:44 mailrelay postfix/smtpd[28649]: timeout after DATA (9832 bytes) from mail02.example.com[68.XXX.YYY.45] Apr 24 17:34:44 mailrelay postfix/smtpd[23281]: timeout after DATA (9716 bytes) from mail02.example.com[68.XXX.YYY.45] mailrelay receives mail from both mail01 and mail02. All three servers are in different parts of the country on 10mbs ethernet links. What could be the cause of such an error? I've checked the network settings, thinking something like MTU could be the issue, but it is the same on both sides. Could this be a kernel or TCP problem on Linux? If so, any suggestions for what parameters may cause such a result? Thanks, Alex
Re: OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
The Doctor: > On Tue, Apr 24, 2012 at 08:21:05PM -0400, Wietse Venema wrote: > > The Doctor: > > > gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL > > > -DUSE_TLS -I/usr/include -I/usr/contrib/include/ > > > -I/usr/contrib/include/sasl -DHAS_PCRE -g -O -I. -I../../include -DBSDI4 > > > -c tls_client.c > > > > Are you really building Postfix on BSD/OS 4.x? I should start > > trimming the list of supported configurations; I have not used > > BSD/OS for more than 10 years. > > > > Yes. 2.8.X works nicely same with 2.9.0 and 2.9.1 If the BSD/OS 4.x compiler dies on #ifdefs in an argument list like this: SSL_set_options(TLScontext->con, ((protomask & TLS_PROTOCOL_TLSv1) ? SSL_OP_NO_TLSv1 : 0L) #ifdef SSL_OP_NO_TLSv1_1 | ((protomask & TLS_PROTOCOL_TLSv1_1) ? SSL_OP_NO_TLSv1_1 : 0L) #endif #ifdef SSL_OP_NO_TLSv1_2 | ((protomask & TLS_PROTOCOL_TLSv1_2) ? SSL_OP_NO_TLSv1_2 : 0L) #endif | ((protomask & TLS_PROTOCOL_SSLv3) ? SSL_OP_NO_SSLv3 : 0L) | ((protomask & TLS_PROTOCOL_SSLv2) ? SSL_OP_NO_SSLv2 : 0L)); then I suppose that is the end of support for this platform. I don't have the time to set up this build environment and develop a workaround for what appears to be a 10-year old compiler bug. You can work around this by removing the #ifdef and #endif shown above. Wietse
Re: Timeout after DATA with postfix
Alex: [ Charset ISO-8859-1 unsupported, converting... ] > Hi, > > I have a few postfix-2.8.7 systems on fedora15 that connect with > another postfix-2.8.7 system. I'm receiving the following messages > periodically in the logs: > > Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA > (9832 bytes) from mail02.example.com[68.XXX.YYY.45] tcpdump will show if this is an MTU problem, mis-handling of TCP window scaling in a buggy firewall, or something else. You can set the MTU with ifconfig commands; and Postfix has tcp_windowsize parameter that allows you to prevent window scaling. Wietse
Re: OpenSSL 1.0.1 workaround: Postfix 2.9.2, 2.8.10, 2.7.9, and 2.6.15
On Tue, Apr 24, 2012 at 08:59:53PM -0400, Wietse Venema wrote: > The Doctor: > > On Tue, Apr 24, 2012 at 08:21:05PM -0400, Wietse Venema wrote: > > > The Doctor: > > > > gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL > > > > -DUSE_TLS -I/usr/include -I/usr/contrib/include/ > > > > -I/usr/contrib/include/sasl -DHAS_PCRE -g -O -I. -I../../include > > > > -DBSDI4 -c tls_client.c > > > > > > Are you really building Postfix on BSD/OS 4.x? I should start > > > trimming the list of supported configurations; I have not used > > > BSD/OS for more than 10 years. > > > > > > > Yes. 2.8.X works nicely same with 2.9.0 and 2.9.1 > > If the BSD/OS 4.x compiler dies on #ifdefs in an argument list > like this: > > SSL_set_options(TLScontext->con, >((protomask & TLS_PROTOCOL_TLSv1) ? SSL_OP_NO_TLSv1 : 0L) > #ifdef SSL_OP_NO_TLSv1_1 > | ((protomask & TLS_PROTOCOL_TLSv1_1) ? SSL_OP_NO_TLSv1_1 : 0L) > #endif > #ifdef SSL_OP_NO_TLSv1_2 > | ((protomask & TLS_PROTOCOL_TLSv1_2) ? SSL_OP_NO_TLSv1_2 : 0L) > #endif > | ((protomask & TLS_PROTOCOL_SSLv3) ? SSL_OP_NO_SSLv3 : 0L) >| ((protomask & TLS_PROTOCOL_SSLv2) ? SSL_OP_NO_SSLv2 : 0L)); > > then I suppose that is the end of support for this platform. I don't > have the time to set up this build environment and develop a > workaround for what appears to be a 10-year old compiler bug. > > You can work around this by removing the #ifdef and #endif shown > above. That works! BTW, gcc being used is 3.2.3 > > Wietse -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Alberta! VOTE!
Re: Timeout after DATA with postfix
Hi, >> I have a few postfix-2.8.7 systems on fedora15 that connect with >> another postfix-2.8.7 system. I'm receiving the following messages >> periodically in the logs: >> >> Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA >> (9832 bytes) from mail02.example.com[68.XXX.YYY.45] > > tcpdump will show if this is an MTU problem, mis-handling of TCP > window scaling in a buggy firewall, or something else. > > You can set the MTU with ifconfig commands; and Postfix has > tcp_windowsize parameter that allows you to prevent window scaling. One of the network admins responsible for an Exchange server which also connects to this relay server and is also having difficulty, has reported the MTU is set correctly to 1500. I've done a little investigation of my own, and I'm finding what I believe are a lot of incorrect checksums? # tcpdump -n -i em1 -v port 25 tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 22:58:47.240297 IP (tos 0x0, ttl 64, id 42727, offset 0, flags [DF], proto TCP (6), length 60) 172.31.1.25.39996 > 65.211.178.22.smtp: Flags [S], cksum 0xa150 (incorrect -> 0x7f01), seq 1065884188, win 14600, options [mss 1460,sackOK,TS val 807651512 ecr 0,nop,wscale 6], length 0 Am I reading that correctly? Is the "mss 1460" the indication of the MTU? If not, how can I have it return the MTU? I've searched quite a bit and really unable to find any reference on how to display that. Thanks again, Alex
