Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
lost connection with ]server] while receiving the initial server greeting
2,264 views
Skip to first unread message
pos...@nisny.com
May 2, 2014, 7:35:49 PM5/2/14
to
I recently moved out mail operations to a new server. The old server is
running Postfix 2.8 and the new server 2.10.
We had some initial problems with some private blacklists and the new IP
but those were resolved. However, I had a curious problem sending mail
to icloud.com addresses. Postfix was reporting:
lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
receiving the initial server greeting
to all MX servers for adadns.net.
To get around this initial problem I began relaying outbound mail thru
the old server until the blacklisting was all resolved. However, I am
still unable to send to the adadns.net servers, still getting dropped
connections. They were no help at all resolving the issue.
Finally I tried to send an email by telnet to port 25 at the above IP
from the new server and sure enough the email went through without
issue.
I've looked through the release notes for 2.9 and 2.10 and didn't see
anything related concerning configuration that might explain this.
Any ideas of what I can try next?
postconf -n (irrelevant lines removed/edited):
broken_sasl_auth_clients = yes
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
inet_interfaces = all
local_transport = virtual
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
master_service_disable =
message_size_limit = 50000000
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = xxx.xxx.xxx
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname,
reject_invalid_hostname, permit
smtpd_recipient_restrictions = check_recipient_access
hash:/usr/local/etc/postfix/reject_recipients, reject_unauth_pipelining,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
check_recipient_maps, permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain,
permit
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/xxxxx.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tcp_windowsize = 1400
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
running Postfix 2.8 and the new server 2.10.
We had some initial problems with some private blacklists and the new IP
but those were resolved. However, I had a curious problem sending mail
to icloud.com addresses. Postfix was reporting:
lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
receiving the initial server greeting
to all MX servers for adadns.net.
To get around this initial problem I began relaying outbound mail thru
the old server until the blacklisting was all resolved. However, I am
still unable to send to the adadns.net servers, still getting dropped
connections. They were no help at all resolving the issue.
Finally I tried to send an email by telnet to port 25 at the above IP
from the new server and sure enough the email went through without
issue.
I've looked through the release notes for 2.9 and 2.10 and didn't see
anything related concerning configuration that might explain this.
Any ideas of what I can try next?
postconf -n (irrelevant lines removed/edited):
broken_sasl_auth_clients = yes
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
inet_interfaces = all
local_transport = virtual
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
master_service_disable =
message_size_limit = 50000000
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = xxx.xxx.xxx
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname,
reject_invalid_hostname, permit
smtpd_recipient_restrictions = check_recipient_access
hash:/usr/local/etc/postfix/reject_recipients, reject_unauth_pipelining,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
check_recipient_maps, permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain,
permit
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/xxxxx.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tcp_windowsize = 1400
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
Wietse Venema
May 2, 2014, 8:06:54 PM5/2/14
to
pos...@nisny.com:
or A lookups are taking too long when the remote SMTP server is
trying to determine your server's hostname.
Wietse
> I recently moved out mail operations to a new server. The old server is
> running Postfix 2.8 and the new server 2.10.
>
> We had some initial problems with some private blacklists and the new IP
> but those were resolved. However, I had a curious problem sending mail
> to icloud.com addresses. Postfix was reporting:
>
> lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
> receiving the initial server greeting
>
> to all MX servers for adadns.net.
What is your servers's public IP address? I suspect that PTR
> running Postfix 2.8 and the new server 2.10.
>
> We had some initial problems with some private blacklists and the new IP
> but those were resolved. However, I had a curious problem sending mail
> to icloud.com addresses. Postfix was reporting:
>
> lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while
> receiving the initial server greeting
>
> to all MX servers for adadns.net.
or A lookups are taking too long when the remote SMTP server is
trying to determine your server's hostname.
Wietse
pos...@nisny.com
May 2, 2014, 8:12:16 PM5/2/14
to
It doesn't seem to be taking long (from 3rd party location 191 msec) and
wouldn't that have affected as well dong a telnet?
Wietse Venema
May 2, 2014, 8:40:13 PM5/2/14
to
pos...@nisny.com:
You haven't said if this is a persistent problem. One telnet may
work now, but that does not exclude the possibility of an eralier
problem.
What does Postfix log with "delay=a/b/c/d" when a connection is lost?
Are you going through a stateful firewall/NAT that drops sessions
to soon?
I can speculate until the cows come home, but I prefer not to.
Wietse
work now, but that does not exclude the possibility of an eralier
problem.
What does Postfix log with "delay=a/b/c/d" when a connection is lost?
Are you going through a stateful firewall/NAT that drops sessions
to soon?
I can speculate until the cows come home, but I prefer not to.
Wietse
Message has been deleted
Wietse Venema
May 3, 2014, 7:47:05 AM5/3/14
to
pos...@nisny.com:
> There is NO NAT or firewall.
>
> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
> connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving
> the initial server greeting)
0.3 = No congestion within the Postfix queue.
0.01 = TCP completes immediately.
177 = Postfix waits for the 220 greeting until the connection is dropped.
I suggest that you take Postfix out of the loop, and diagnose this
further with plain old telnet.
Wietse
> There is NO NAT or firewall.
>
> relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177,
> delays=0.3/0.01/177/0, dsn=4.4.2, status=deferred (lost
> connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving
> the initial server greeting)
0.3 = No congestion within the Postfix queue.
0.01 = TCP completes immediately.
177 = Postfix waits for the 220 greeting until the connection is dropped.
I suggest that you take Postfix out of the loop, and diagnose this
further with plain old telnet.
Wietse
pos...@nisny.com
May 3, 2014, 8:54:47 AM5/3/14
to
new:
Trying 17.172.34.70...
Connected to st11p00mm-mx006.me.com.
Escape character is '^]'.
220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
As you can see, I'm getting an immediate 220 from them which postfix
apparently is not getting. I can, of course, continue the telnet
session and send a complete email which is received by the recipient.
Message has been deleted
Message has been deleted
Wietse Venema
May 3, 2014, 8:27:06 PM5/3/14
to
pos...@nisny.com:
to proceed just as well.
Wietse
> Wietse, thank you for your efforts. Telnet isn't telling me anything
> new:
>
> Trying 17.172.34.70...
> Connected to st11p00mm-mx006.me.com.
> Escape character is '^]'.
> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
>
> As you can see, I'm getting an immediate 220 from them which postfix
> apparently is not getting. I can, of course, continue the telnet
> session and send a complete email which is received by the recipient.
And so can Postfix. One SINGLE SMTP connection from Postfix is likely
> new:
>
> Trying 17.172.34.70...
> Connected to st11p00mm-mx006.me.com.
> Escape character is '^]'.
> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
>
> As you can see, I'm getting an immediate 220 from them which postfix
> apparently is not getting. I can, of course, continue the telnet
> session and send a complete email which is received by the recipient.
to proceed just as well.
Wietse
pos...@nisny.com
May 3, 2014, 8:48:32 PM5/3/14
to
from Postfix to multiple servers over multiple emails over multiple days
and not ONE has successfully connected. Yet telnet to all of those same
multiple servers from the same host that is running Postfix, that is
unable to connect, succeed, multiple times, without a single failure.
Meanwhile, a separate box running Postfix 2.8.7 can connect to those
same servers without failure.
Wietse Venema
May 3, 2014, 9:17:28 PM5/3/14
to
pos...@nisny.com:
What system did YOU make the connection from?
> >> As you can see, I'm getting an immediate 220 from them which postfix
> >> apparently is not getting. I can, of course, continue the telnet
> >> session and send a complete email which is received by the recipient.
> >
> > And so can Postfix. One SINGLE SMTP connection from Postfix is likely
> > to proceed just as well.
>
Your telnet test was today, making one connection.
You may learn more by capturing a few failed SMTP sessions with
tcpdump.
Wietse
> >> Trying 17.172.34.70...
> >> Connected to st11p00mm-mx006.me.com.
> >> Escape character is '^]'.
> >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
> >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
I made a telnet connection from my own machine without trouble.
> >> Connected to st11p00mm-mx006.me.com.
> >> Escape character is '^]'.
> >> 220 st11p00mm-smtpin012.mac.com -- Server ESMTP (Oracle Communications
> >> Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013))
What system did YOU make the connection from?
> >> As you can see, I'm getting an immediate 220 from them which postfix
> >> apparently is not getting. I can, of course, continue the telnet
> >> session and send a complete email which is received by the recipient.
> >
> > And so can Postfix. One SINGLE SMTP connection from Postfix is likely
> > to proceed just as well.
>
> Why do you think it's a single connection?
> It's multiple connections from Postfix to multiple servers over
> multiple emails over multiple days
Indeed, the problem is making multiple connections in the past.
> It's multiple connections from Postfix to multiple servers over
> multiple emails over multiple days
Your telnet test was today, making one connection.
You may learn more by capturing a few failed SMTP sessions with
tcpdump.
Wietse
pos...@nisny.com
May 3, 2014, 9:49:49 PM5/3/14
to
I say no test via Postfix were run today.
pos...@nisny.com
May 3, 2014, 10:48:22 PM5/3/14
to
>
> You may learn more by capturing a few failed SMTP sessions with
> tcpdump.
>
> Wietse
You are correct, I learned more but not enough for me, at least, to
figure out what it means.
Clarification, thru all this I've talked about connecting to icloud.com
mx. For the purposes of this test I did a tcpdump for the subnet that
all the mx servers reside on. The PTR records return a different result
(xxx.me.com) but are the same servers.
There were several attempts from postfix to connect to 6 different mx
servers to deliver one email. They all have the same result so I'm only
including the dump of the first here:
reading from file postfix.cap, link-type EN10MB (Ethernet)
2014-05-03 22:29:50.755792 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0], length 0
E..<.e@.@..........r.d.....:.......x...............
/W.....
2014-05-03 22:29:50.803327 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
33304, options [nop,nop,TS val 803912023 ecr 170874802,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@$b@.2..p...r.......d2......;.....V.....
/..W
/W.............
2014-05-03 22:29:50.803385 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
[nop,nop,TS val 170874848 ecr 803912023], length 0
E..4.o@.@..........r.d.....;2..............
/W./..W
2014-05-03 22:29:51.926871 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
33304, options [nop,nop,TS val 803912136 ecr 170874802,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@$c@.2..o...r.......d2......;...........
/...
/W.............
2014-05-03 22:29:51.926896 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
[nop,nop,TS val 170875972 ecr 803912136], length 0
E..4..@.@..........r.d.....;2..............
/\D/...
2014-05-03 22:29:54.195922 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
33304, options [nop,nop,TS val 803912362 ecr 170874802,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@$d@.2..n...r.......d2......;...........
/...
/W.............
2014-05-03 22:29:54.195953 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
[nop,nop,TS val 170878242 ecr 803912362], length 0
E..4..@.@..c.......r.d.....;2..............
/e"/...
2014-05-03 22:29:58.713053 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
33304, options [nop,nop,TS val 803912814 ecr 170874802,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@$e@.2..m...r.......d2......;.....?.....
/..n
/W.............
2014-05-03 22:29:58.713079 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
[nop,nop,TS val 170882759 ecr 803912814], length 0
E..4..@.@..........r.d.....;2..............
/v./..n
2014-05-03 22:30:07.717105 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [S.], seq 851616152, ack 3314275387, win
33304, options [nop,nop,TS val 803913715 ecr 170874802,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@$f@.2..l...r.......d2......;...........
/...
/W.............
2014-05-03 22:30:07.717136 IP smtp.bestwny.com.36708 >
nk11p00mm-mx006.me.com.smtp: Flags [.], ack 1, win 21, options
[nop,nop,TS val 170891763 ecr 803913715], length 0
E..4!.@.@..........r.d.....;2..............
/../...
2014-05-03 22:30:25.735938 IP nk11p00mm-mx006.me.com.smtp >
smtp.bestwny.com.36708: Flags [R.], seq 1, ack 1, win 33304, length 0
E(.($g@.2......r.......d2......;P....Y..
2014-05-03 22:30:25.736215 IP smtp.bestwny.com.59558 > 17.158.8.71.smtp:
Flags [S], seq 3843436255, win 1400, options [mss 1460,nop,wscale
6,sackOK,TS val 170909782 ecr 0], length 0
E..<%g@.@..........G...............x...............
/.V....
As you can see, no 220 was returned to Postfix
I then did a capture of a telnet session to the same server on port 25:
reading from file telnet.cap, link-type EN10MB (Ethernet)
2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win 65535,
options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr 0], length 0
E..<t.@.@.C........2.....o.1.......................
4I.....
2014-05-03 22:35:14.869697 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [S.], seq 1071218802, ack 3396279602, win
33304, options [nop,nop,TS val 406558553 ecr 171198862,mss
1460,nop,wscale 1,nop,nop,sackOK], length 0
E(.@`.@.2.em...2........?..r.o.2.....H.....
.;.Y
4I.............
2014-05-03 22:35:14.869751 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 1, win 1040, options
[nop,nop,TS val 171198912 ecr 406558553], length 0
E..4t.@.@.C........2.....o.2?..s...........
4I..;.Y
2014-05-03 22:35:14.931907 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [P.], seq 1:139, ack 1, win 33304, options
[nop,nop,TS val 406558560 ecr 171198912], length 138
E(..`.@.2.d....2........?..s.o.2.....'.....
.;.`
4I.220 nk11p00mm-smtpin017.mac.com -- Server ESMTP (Oracle
Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug
22 2013))
2014-05-03 22:35:15.025661 IP smtp.bestwny.com.58803 >
22 2013))
nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 139, win 1040, options
[nop,nop,TS val 171199072 ecr 406558560], length 0
E..4t.@.@.C........2.....o.2?..............
4J`.;.`
2014-05-03 22:35:21.434234 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [P.], seq 1:24, ack 139, win
1040, options [nop,nop,TS val 171205472 ecr 406558560], length 23
E..Kv`@.@.A........2.....o.2?..............
4c`.;.`EHLO smtp.bestwny.com
2014-05-03 22:35:21.482488 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [.], ack 24, win 33304, options
[nop,nop,TS val 406559215 ecr 171205472], length 0
E(.4`.@.2.ew...2........?....o.I...........
.;..
4c`
2014-05-03 22:35:21.483075 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [P.], seq 139:395, ack 24, win 33304,
options [nop,nop,TS val 406559215 ecr 171205472], length 256
E(.4`.@.2.dv...2........?....o.I.....>.....
.;..
4c`250-nk11p00mm-smtpin017.mac.com
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-DSN
250-ENHANCEDSTATUSCODES
250-EXPN
250-HELP
250-XADR
250-XSTA
250-XCIR
250-XGEN
250-XLOOP 5FD8A7158C627CE6C2DD92D78FDB33EF
250-ETRN
250-NO-SOLICITING
250 SIZE 0
2014-05-03 22:35:21.575676 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 395, win 1040, options
[nop,nop,TS val 171205622 ecr 406559215], length 0
E..4vk@.@.A........2.....o.I?..............
4c..;..
2014-05-03 22:35:27.584480 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [F.], seq 24, ack 395, win 1040,
options [nop,nop,TS val 171211622 ecr 406559215], length 0
E..4w.@.@.@Q.......2.....o.I?..............
4{f.;..
2014-05-03 22:35:27.632735 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [.], ack 25, win 33304, options
[nop,nop,TS val 406559830 ecr 171211622], length 0
E(.4`.@.2.eu...2........?....o.J...........
.;.V
4{f
2014-05-03 22:35:27.633216 IP nk11p00-smtp-mx003.mac.com.smtp >
smtp.bestwny.com.58803: Flags [F.], seq 395, ack 25, win 33304, options
[nop,nop,TS val 406559830 ecr 171211622], length 0
E(.4`.@.2.et...2........?....o.J...........
.;.V
4{f
2014-05-03 22:35:27.633248 IP smtp.bestwny.com.58803 >
nk11p00-smtp-mx003.mac.com.smtp: Flags [.], ack 396, win 1040, options
[nop,nop,TS val 171211672 ecr 406559830], length 0
E..4w.@.@.@J.......2.....o.J?..............
4{..;.V
I am clueless as to why telnet would receive a correct response but
Postfix not.
I know see this is not necessarily a Postfix issue but not sure what the
next step would be, so if anyone can offer guidance it would be
appreciated.
Stan Hoeppner
May 4, 2014, 4:02:36 AM5/4/14
to
On 5/3/2014 9:48 PM, pos...@nisny.com wrote:
...
> We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses...
The problem is exclusive, as far as we know, to this Akamai hosted MX
farm. Wietse is obviously correct. Your telnet sessions work because
they are a single connection. When you allow Postfix to deliver, it is
making parallel connections to the farm because sufficient mail is
queued for domains at that MX farm. You have two options to resolve this:
1. Create relay transports for the problem domains and limit
concurrency to those domains, until your sender reputation with Akamai
has increased to the point they allow parallel deliveries.
2. Contact the Akamai hostmaster and inquire as to what that threshold
is, and when you may expect to surpass it.
This problem is not new. The list archives are littered with threads
dealing with ISPs who limit concurrency or delivery rate of "fresh" IP
addresses. Those threads also contain instructions on how to do what I
describe above to limit Postfix concurrency.
Cheers,
Stan
...
> I am clueless as to why telnet would receive a correct response but
> Postfix not.
>
> I know see this is not necessarily a Postfix issue but not sure what the
> next step would be, so if anyone can offer guidance it would be
> appreciated.
The answer to your problem is in your first post:
> Postfix not.
>
> I know see this is not necessarily a Postfix issue but not sure what the
> next step would be, so if anyone can offer guidance it would be
> appreciated.
> We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses...
The problem is exclusive, as far as we know, to this Akamai hosted MX
farm. Wietse is obviously correct. Your telnet sessions work because
they are a single connection. When you allow Postfix to deliver, it is
making parallel connections to the farm because sufficient mail is
queued for domains at that MX farm. You have two options to resolve this:
1. Create relay transports for the problem domains and limit
concurrency to those domains, until your sender reputation with Akamai
has increased to the point they allow parallel deliveries.
2. Contact the Akamai hostmaster and inquire as to what that threshold
is, and when you may expect to surpass it.
This problem is not new. The list archives are littered with threads
dealing with ISPs who limit concurrency or delivery rate of "fresh" IP
addresses. Those threads also contain instructions on how to do what I
describe above to limit Postfix concurrency.
Cheers,
Stan
Stan Hoeppner
May 4, 2014, 4:10:38 AM5/4/14
to
On 5/4/2014 3:02 AM, Stan Hoeppner wrote:
...
I forgot the simplest solution:
Give the new server the IP address and forward/reverse DNS name of the
old Postfix server, same HELO hostname, etc. That should fix this
instantly, assuming this problem did not exist before. Your use of the
term "old" implies you decommissioned the old box, which makes this the
optimal solution.
Cheers,
Stan
...
> 1. Create relay transports for the problem domains and limit
> concurrency to those domains, until your sender reputation with Akamai
> has increased to the point they allow parallel deliveries.
>
> 2. Contact the Akamai hostmaster and inquire as to what that threshold
> is, and when you may expect to surpass it.
...
> concurrency to those domains, until your sender reputation with Akamai
> has increased to the point they allow parallel deliveries.
>
> 2. Contact the Akamai hostmaster and inquire as to what that threshold
> is, and when you may expect to surpass it.
I forgot the simplest solution:
Give the new server the IP address and forward/reverse DNS name of the
old Postfix server, same HELO hostname, etc. That should fix this
instantly, assuming this problem did not exist before. Your use of the
term "old" implies you decommissioned the old box, which makes this the
optimal solution.
Cheers,
Stan
Stefan Foerster
May 4, 2014, 6:24:07 AM5/4/14
to
> nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
> options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
> length 0
> E..<.e@.@..........r.d.....:.......x...............
[...]
> options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
> length 0
> E..<.e@.@..........r.d.....:.......x...............
> I then did a capture of a telnet session to the same server on port 25:
>
> reading from file telnet.cap, link-type EN10MB (Ethernet)
> 2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
> nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win
> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr
> 0], length 0
> E..<t.@.@.C........2.....o.1.......................
configuration (do not forget to issue a "postfix reload" afterwards!)?
Stefan
Wietse Venema
May 4, 2014, 8:23:43 AM5/4/14
to
pos...@nisny.com:
SYN: Initial client window 1400 (scale 6), options [mss 1460,nop,wscale
6,sackOK,TS]
SYN|ACK: Initial server window 33304 (scale 1), options [nop,nop,TS,mss
1460,nop,wscale 1,nop,nop,sackOK].
Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
the server sends a RESET. The TCP handshake never completes. And
someone may already have posted the solution.
For the telnet connection we have a successful handhake.
SYN: Initial client window 65535 (scale 6), same TCP options as
SMTP client. SYN|ACK: Same initial server window and TCP options
as STMP server.
The only difference I see is the initial 1400 client TCP window
size.
As someone already suggested in one of the first follow-ups:
"Would you mind trying to remove "tcp_windowsize = 1400" from
> There were several attempts from postfix to connect to 6 different mx
> servers to deliver one email. They all have the same result so I'm only
> including the dump of the first here:
We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.
> servers to deliver one email. They all have the same result so I'm only
> including the dump of the first here:
SYN: Initial client window 1400 (scale 6), options [mss 1460,nop,wscale
6,sackOK,TS]
SYN|ACK: Initial server window 33304 (scale 1), options [nop,nop,TS,mss
1460,nop,wscale 1,nop,nop,sackOK].
Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
the server sends a RESET. The TCP handshake never completes. And
someone may already have posted the solution.
For the telnet connection we have a successful handhake.
SYN: Initial client window 65535 (scale 6), same TCP options as
SMTP client. SYN|ACK: Same initial server window and TCP options
as STMP server.
The only difference I see is the initial 1400 client TCP window
size.
As someone already suggested in one of the first follow-ups:
"Would you mind trying to remove "tcp_windowsize = 1400" from
you configuration (do not forget to issue a "postfix reload"
afterwards!)?"
Wietse
afterwards!)?"
pos...@nisny.com
May 4, 2014, 9:55:49 AM5/4/14
to
On , Stefan Foerster wrote:
>> nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
>> options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
>> length 0
>> E..<.e@.@..........r.d.....:.......x...............
>
> [...]
>
>> I then did a capture of a telnet session to the same server on port
>> 25:
>>
>> reading from file telnet.cap, link-type EN10MB (Ethernet)
>> 2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
>> nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win
>> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr
>> 0], length 0
>> E..<t.@.@.C........2.....o.1.......................
>
> Wound you mind trying to remove "tcp_windowsize = 1400" from you
>> nk11p00mm-mx006.me.com.smtp: Flags [S], seq 3314275386, win 1400,
>> options [mss 1460,nop,wscale 6,sackOK,TS val 170874802 ecr 0],
>> length 0
>> E..<.e@.@..........r.d.....:.......x...............
>
> [...]
>
>> I then did a capture of a telnet session to the same server on port
>> 25:
>>
>> reading from file telnet.cap, link-type EN10MB (Ethernet)
>> 2014-05-03 22:35:14.821306 IP smtp.bestwny.com.58803 >
>> nk11p00-smtp-mx003.mac.com.smtp: Flags [S], seq 3396279601, win
>> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 171198862 ecr
>> 0], length 0
>> E..<t.@.@.C........2.....o.1.......................
>
> configuration (do not forget to issue a "postfix reload" afterwards!)?
>
>
> Stefan
>
>
Stefan,
Thank you! Of course that worked!
pos...@nisny.com
May 4, 2014, 10:01:27 AM5/4/14
to
On , wie...@porcupine.org wrote:
> pos...@nisny.com:
>> There were several attempts from postfix to connect to 6 different mx
>> servers to deliver one email. They all have the same result so I'm
>> only
>> including the dump of the first here:
>
> We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.
>
> SYN: Initial client window 1400 (scale 6), options [mss
> 1460,nop,wscale
> 6,sackOK,TS]
>
> SYN|ACK: Initial server window 33304 (scale 1), options
> [nop,nop,TS,mss
> 1460,nop,wscale 1,nop,nop,sackOK].
>
> Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
> the server sends a RESET. The TCP handshake never completes. And
> someone may already have posted the solution.
>
> For the telnet connection we have a successful handhake.
>
> SYN: Initial client window 65535 (scale 6), same TCP options as
>
> SMTP client. SYN|ACK: Same initial server window and TCP options
> as STMP server.
>
> The only difference I see is the initial 1400 client TCP window
> size.
>
> As someone already suggested in one of the first follow-ups:
>
> "Would you mind trying to remove "tcp_windowsize = 1400" from
> pos...@nisny.com:
>> There were several attempts from postfix to connect to 6 different mx
>> servers to deliver one email. They all have the same result so I'm
>> only
>> including the dump of the first here:
>
> We see SYN, SYN|ACK, ACK, and a bunch of retransmissions.
>
> SYN: Initial client window 1400 (scale 6), options [mss
> 1460,nop,wscale
> 6,sackOK,TS]
>
> SYN|ACK: Initial server window 33304 (scale 1), options
> [nop,nop,TS,mss
> 1460,nop,wscale 1,nop,nop,sackOK].
>
> Then we see SYN|ACK retransmitted, ACK retransmitted, etc., until
> the server sends a RESET. The TCP handshake never completes. And
> someone may already have posted the solution.
>
> For the telnet connection we have a successful handhake.
>
> SYN: Initial client window 65535 (scale 6), same TCP options as
>
> SMTP client. SYN|ACK: Same initial server window and TCP options
> as STMP server.
>
> The only difference I see is the initial 1400 client TCP window
> size.
>
> As someone already suggested in one of the first follow-ups:
>
> you configuration (do not forget to issue a "postfix reload"
> afterwards!)?"
>
> Wietse
> afterwards!)?"
>
Wietse,
Thank you for your patience with me. I tried way too long trying to
resolve this on my own.
I totally forgot that was in main.cf (from months ago trying to resolve
a separate issue and missed it in postconf -n output. (the issue in
question is a networking problem at the provider and the main reason for
the move).
The funny thing is that directive is on the old server as well, which
had no problems connecting to akamai,
At any rate, removing the directive and a reload, postqueue -f resolved
the issue completely.
Again, my thanks.
Stan Hoeppner
May 4, 2014, 10:29:37 PM5/4/14
to
Scratch my previous suggestion as it was obviously not the correct
solution. Read on.
Are both the old and new server in the new provider's network at this
point. It would be informative to compare SMTP session capture of both
systems when "tcp_windowsize = 1400" is configured. I.e. test the old
system and compare to the capture you already have for the new system.
At this point you know what Postfix setting caused the problem on the
new server, but you don't know why it caused a problem, you don't know
the root cause. Knowing that root cause may be very useful in the future.
> At any rate, removing the directive and a reload, postqueue -f resolved
> the issue completely.
Cheers,
Stan
solution. Read on.
point. It would be informative to compare SMTP session capture of both
systems when "tcp_windowsize = 1400" is configured. I.e. test the old
system and compare to the capture you already have for the new system.
At this point you know what Postfix setting caused the problem on the
new server, but you don't know why it caused a problem, you don't know
the root cause. Knowing that root cause may be very useful in the future.
> At any rate, removing the directive and a reload, postqueue -f resolved
> the issue completely.
Stan
0 new messages