[For some reason this response I sent back on 2008-01-18 was directed to
the list owner address rather than the list. Wonder how I miffed that.]
On 2008-01-18 15:57, Gabriele Bulfon wrote:
These configurations worked fine for many years, and it started to have
some timout problems
only with some destination MTA (e.g. mail.register.it).
What may be confusing the transmission?
Timeouts usually occurs during mail body transfer (DATA chunk), or at
the end of this.
A few possibilities:
Sometimes remote MTAs initiate an IDENT connection back to the
transmitting MTA on 113/tcp; if you are generically blocking inbound TCP
without return-rst, this causes a delay while the remote retries the
connection. Possibly this added delay is pushing past your Postfix
timeout. The solution in that case is to block inbound TCP with
return-rst on port 113 (or all ports).
DNS lookups also can increase delays with remote MTAs. Make sure both
forward and inverse DNS are working correctly and that you have no lame
delegations. Also check DNS to see if SPF or DKIM records exist for your
source domain, and if so, whether they are correct.
A third possibility is that your MTA's IP is in a real-time blacklist,
and some remote MTAs are refusing mail with a long timeout as a kind of
honeypot behaviour. Check RBLs for your MTA's IP, especially Spamhaus.
Try sending one of the problem messages manually (verbatim) and see if
you ultimately get a 4xx or 5xx response. Since Postfix is giving up on
a timeout, you may not be seeing the remote MTAs ultimate response code.
If you can see the response code, it may also indicate what blacklist is
responsible.
The latter possibility is the one that most readily explains why this
problem would have started occurring only recently.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
