On Wed, Mar 07, 2001 at 07:02:53PM +0300, Alex Povolotsky wrote:
> On Wed, Mar 07, 2001 at 04:37:01PM +0100, Peter van Dijk wrote:
> > > it tries to deliver mail to the first MX only.
> > How about you show us an example? I never see this behaviour.
SNIP OK MX records etc.
> And now:
>
> [19:00] runaway:~/pictures/mpg > tail /var/log/maillog
> Mar 7 18:43:18 runaway qmail: 983979798.644869 delivery 66: deferral:
>Connected_to_194.67.23.42_but_greeting_failed./Remote_host_said:_421_mx6.port.ru:_Too_many_concurrent_SMTP_connections;_please_try_again_later./
SNIP more logs.
It seems to me that qmail will only try the other MXs if it cannot
_connect_ to the MX it tries -- an opened but failed connection means
that it will continue to try the best-preference MX (similar to multiple
DNS servers in /etc/resolv.conf). Masters of the qmail Source (tm) can
probably confirm this for us. Not sure if this is covered in the RFCs or
not, but is seems reasonable behaviour to me -- if this host is
overloaded, why accept the connection at all? Opening up a new TCP
connection in an attempt to defer mail seems to me to defeat the purpose
of deferring it in the first place. ;) tcpserver, at its connection
limit, does not open a connection at all, neither does inetd.
Try black-holing or firewalling port 25 on the best-preference MX and
see if I'm right -- I'll bet if you can't reach SMTP on that host at
all, mail will go to the next MX and all will be well.
--
Greg White
Those who make peaceful revolution impossible will make violent
revolution inevitable.
-- John F. Kennedy
