Thx for the suggestions.
I found about the IDENT possibility somewhere before, but tried it with no
success.
I snooped the public side of the machine while flushing those messages, and I
must say "no" to the possibility of lame DNS lookups.
Blacklists are not an issue, because my connection would be refused much
eralier than when it happens: it usually timeouts during the send of DATA or at
the end of the DATA chunk.
Last but not least, any of these options seem to be the case, because the queue
instantly flushes correctly if I temporarily disable ipfilter and run
"postqueue -f".
I see it more possible what Ken Jones said: bugs in the distribution of latest
Solaris 10.
Infact, I noticed that the machines having those problems are the ones I
recently upgraded to new hardware and consequentely coming with newer releases
of Solaris 10.
What I'd like to know, is if there is some way to remove the original packages
and replace them with compiled binaries from the distribution, without having
to reboot the machines.
I have complete instructions for this, but they force me to reboot a couple of
times.
Thanx for any help
Gabriele.
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
----------------------------------------------------------------------------------
Da: Jefferson Ogata <[EMAIL PROTECTED]>
A: Ipfilter <[email protected]>
Data: 21 gennaio 2008 20.27.44 CET
Oggetto: Re: Postfix timeouts
[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
