I'm setting up some Exim boxes to relay mail coming in to/out from a
cluster of Netscape Messaging servers. These are somewhat brain-dead,
as they gleefully send error messages during the DATA when they're
receiving messages over SMTP. Before receiving the terminating ".",
that is. This becomes a real problem when Exim is sending very long
lines during DATA. The Messaging server seem to have a fixed limit of
16384 characters per line, and if that limit is exceeded, it
immediately spits out a 550. Exim seems to handle this well enough in
most cases, and creates a bounce á la:
SMTP error from remote mailer after end of data: host foo [1.2.3.4]
550 DATA line too long (Max 16384)
However, if the line is atrociously long (I tried with 91940 chars),
a broken pipe occurs instead. When this happens, Exim notes that the
host is unavailable in its retry databases. That is what is causing me
headaches - all incoming mail ends up getting stalled at the relays,
and as soon as the retry timer hits zero, the problematic message
ensures that the retry hint is added back.
As the Messaging servers aren't under my administration, I need to fix
this on the relays. The possible solutions I can think of are:
- Make Exim somehow not receive SIGPIPE, instead bounce the message
just as would if the line is just slightly over 16384 chars.
- Make Exim enforce a max line length on incoming messages, refusing
DATA if a long line is found.
- Have the smtp transport fail if a long line is found in the message
that is about to be sent.
- Make Exim use a specific retry rule with a very low/no timeout for
the SIGPIPE error (and that error alone).
Sadly, I can't figure out if any of these approaches are at all
possible. Is that the case? If so, are there any other approaches I
can take to ensure that the problematic messages are kept off my queue?
RFC 2821 4.5.3.1 seems to mandate that the lines must have a max
length of 1000 chars, so the Messaging servers are well within their
rights to refuse handling the problematic messages. I only wish they
did so in a more, um, eloquent manner..
--
Tore Anderson
