--
On Sat, 2003-01-18 at 07:54, Dr Andrew C Aitchison wrote:
> Ian Jackson has pointed me at RFC1123, section 5.3.1.1 Sending Strategy
> The sender MUST delay retrying a particular destination
> after one attempt has failed.
On a related note, I've disabled delaying the entire queue for the host
when the connection drops, for our site. It was causing messages to our
main mail server to be delayed.
Exim is secondary MX for a Netscape Messaging Server (4.15p7).
Messaging Server outputs the 550 message and drops the connection
immediately after any message data line that is longer than 1024
characters. Exim was then delaying all messages to the server, as per
the RFC, because it didn't seem to notice the 550 but did notice the
dropped connection. When the message with the long line is retried, the
entire queue for that host is delayed again. This caused large delivery
delays for messages going through the secondary (which was also our
default outbound server, so local messages where being delayed).
My patch for delaying the message that was being sent when the
connection dropped, rather than the whole queue for that host, is
attached. A better way to handle this would be to notice the 550 and
bounce the message, or to have a configurable limit on envelope and data
line lengths in Exim.
As for NS Messaging Server, the recommended method for increasing the
max line length actually appears to cause long lines to be truncated
(could be my mail client). I prefer no messages to truncated messages.
We are in the process of upgrading to a more recent version.
--
Sean Burford
Systems Specialist
Adelaide University
--
[ exim-4.10.which-rfc1123.patch of type text/x-patch deleted ]
--
