Prev: what's happening here? and is there something I can tweak to fix?
Next: Sendmail 8.14.3 on fedora 12 64 bits
From: alf on 7 Jun 2010 11:55
Following up to myself, but somebody may find this useful.

On May 26, 3:22 pm, alf <alessandro.forghi...(a)gmail.com> wrote:
[....]
> The problem:
> messages sent to atom.it are permanently associated to one of the two
> highest priority MXs and get stuck in the queue - forever (a log for
> sendmail -q -v -d is appended). The messages are stuck on a 440
> connection timed out condition. The third MX is never considered. This
> is  in violation of the following segment of the docs (sendmail.org):

NOT. (Not the problem, that is). Symptoms are as explained, however
the actual culprits are:

> setoption Timeout (r).connect=1m
> setoption Timeout (r).aconnect=2m

and especially the second one, brought about by (myself) sticking the
following in sendmail.mc:

define(`confTO_ACONNECT', `2m')dnl

The docs state:

confTO_ACONNECT: Timeout.aconnect

[0] The overall timeout waiting for all connection
for a single delivery attempt to succeed.
If 0, no overall limit is applied.

So, in the delivery trace above, sendmail tries the first MX, times
out in a minute, tries the second MX, times out in aminute , then
gives up because the overall delivery time (2 minutes) is expired....
dandy, except it does so while failing to say anything about it -
which methinks is a bug, because it then appears as if the delaying TO
is MX related (when it is in fact config related).

Cheers,
alf
 | 
Pages: 1
Prev: what's happening here? and is there something I can tweak to fix?
Next: Sendmail 8.14.3 on fedora 12 64 bits