On Monday 08 December 2008, Wietse Venema wrote: > Michael Brennen: > > The mail from puremail was sent from ip address 66.81.101.50, which > > reverses to 'mx.puremail.com'. A forward lookup on 'mx.puremail.com' > > results in a truncated DNS result and TCP retry, returning 23 ip > > addresses. > > > > From the remote end's view the 220 return message is delayed by minutes; > > that is how I isolated it to a DNS resolution problem. Running postfix > > debug on that ip address results in the log entries at the end of this > > mail. The only redaction in the log is to remove the specific matches > > for my local networks. > ... > > > Dec 4 18:18:27 bilbo postfix/smtpd[3919]: connect from > > mx.puremail.com[66.81.101.50] > > This line is logged AFTER the DNS delays. There is no useful > information in what gets logged from here onwards. > > You should be able to reproduce DNS delays with Postfix's own > getaddrinfo and getnameinfo utilities, part of the Postfix source > code distribution. > > ./getnameinfo 66.81.101.50 > ./getaddrinfo mx.puremail.com
Excellent, thank you. The problem is fixed. I found the source in the 2.5.5 tree and built the utilities. They turned up that one of the name servers, in this case the first one listed for the outward facing mail servers, had a long timeout on one of the checks; the other name server resolved both immediately. On both dns servers nslookup worked immediately on both forward and reverse lookup, so I was not seeing the problem from the postfix point of view. I compared the configurations of the two name servers, made a few adjustments to the slow one, and now both are responding immediately. I still don't know why the name server config changes made any difference, as the changes were only in logging, but that is another investigation. Again, thank you. -- -- Michael
signature.asc
Description: This is a digitally signed message part.
