[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

less than optimal behaviour on read/write timeout in smtp transport agent?



This is just a "heads up" for any of you who deal with sites that have less
than stellar SMTP implementations -- (e.g., a Novell SMTP gateway)

(1) in the old (very! 2.2 of a long way back) smtp transport i'm using it will
wait forever (a day) when it has sent the terminating "." of the transfer.

RFC 1123 suggests that a minimum wait time at this point is 10 minutes but if
you go as high as a day you can end up with your transport agents wedged.

I updated my copy to timeout at that point in 20m -- a compromise, I sure
*hope* that the destination can respond in under 20m, and if it can't, well,
we'll just deliver it again later.

(2) it looks as though (with about 5 minutes examination of some processes on
my gateway): if you have a transport agent which has been scheduled to deliver
a large number of messages, and near the beginning of the list it gets a
timeout in "smtpwrite", it will send the RSET, which times out, and then it
tries to deliver the next message, which is likely to time out, so it does the
RSET, and ... you get the picture.

I believe that if you have a problem with a timeout on one of the messages you
should probably give up on that SMTP connection, and mark  all the remaining
addresses as "timed out", and let the reschedule take care of it.  Otherwise it
can take a rather long time to time out each address (say, 10m per address plus
10m per RSET, and, say 50 messages queued = 16h before you'll have given up)

					\nick