On 16 Oct 2017, at 13:13, Curtis wrote:
Yes, I understand that setting smtp_line_length_limit above 998 is not
recommend.
I agree that for most Postfix installations, where mail is relayed to
the outside world, this recommendation is your best bet for email
deliverability because lines longer than 1000 violates RFC 5321. I
totally agree with this if your Postfix installation is sending
outbound email.
I manage several gateway mail servers that only accept inbound email
and deliver to internal servers. Lately we've been seeing more and
more DKIM signed messages. Most make it though these gateway servers
without issue. However, we've recently seen some messages fail DKIM
checks by the internal mail servers because some Microsoft mail
clients/servers are sending messages all on one line, but after they
come through our gateway servers, these messages are broken up into
several lines (according to the smtp_line_length_limit setting).
I do not have any control over what the senders use to send these
inbound messages and so I would like to allow these messages through
(even if they violate RFC specs) without alteration. Since I have no
idea how long the messages might be, I am experimenting with setting
the smtp_line_length_limit to 9999999 (almost 10MB). I had wondered
if I might run into an internal upper limit that Postfix might not
allow, but it seemed to accept 9999999 without complaint. This has
allowed these DKIM signed messages to come through without issue.
There's a fundamental sender problem here. Nothing should be sending
messages with body lines after being encoded for transfer are anywhere
near the standard limit. It is entirely normal, common, and proper for a
client or the initial MSA to fix the long lines in a line-per-paragraph
message (sadly not limited to MS products) by using Quoted-Printable or
even Base64 to put the message body into a form that won't be re-encoded
or rejected in transit and will be decodable to the pristine original
format on arrival. Decent clients use RFC3676 "format=flowed" text parts
to avoid the problem altogether. Any type of message signature should
only be created and verified in a consistent fashion, i.e. clients
should be submitting messages in a transport-safe form and any MSA that
is creating signatures should do any needed re-encoding before signing.
Mostly this is dealt with correctly, even by MS software.
I am NOT saying that you must not accommodate these broken senders, just
that you will be in a small minority of receivers doing so and they will
have issues with others who will not be willing or able to be so
accommodating. They'll need to fix their systems eventually and having a
few lenient receivers masking the basic problem isn't entirely helpful.
[Viktor answered your direct questions already, more precisely than I
could.]
