On Thursday 29 March 2007 00:24, Matthew Byng-Maddick wrote:
> On Wed, Mar 28, 2007 at 02:44:43PM -0400, Bob Johnson wrote:
> [snip correct diagnosis of problem that is extensively discussed in the
> RFCs for SMTP]
>
> > I think the sending system should have a timeout longer than 60 seconds,
> > but even so, this is a bug in Exim. At the moment I can't find a log
> > entry that illustrates it, though.
>
> No, this is not a bug in Exim. Remember that the timing of a TCP stream
> isn't entirely synchronous, based on the fact that you have a certain
> window of "in flight" data. As I say in my note above, there is extensive
> discussion of this issue, and the RFC (and IETF standard) mandated
> minimum timeout for a response to the final dot is 10 minutes, and has been
> since 1980.
Even if it's not a bug in Exim, I think it's something that could be improved.
Exim should be able to check if the sender has gone away before sending the
final OK. Not in all cases, but at least in the case described.
What happens if Exim takes more than ten minutes to respond, for some reason?
Will it notice that fact, assume that the sender has given up and trash the
message ("554 Sorry, I took too long time.")?
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
