sendmail_fix_line_length enhancement request

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

sendmail_fix_line_length enhancement request

Dominic Raferd
I understand the reason for smtp_line_length_limit and for its default
value of 998, which is of course good.

But it is an occasional problem for me that this wrapping action is
only applied at smtp stage and not earlier; in particular it is after
any (open)dkim milter adds its key, because smtp's wrapping means that
the key then becomes invalid.

The standard answer would be that it is the responsibility of an MUA
to ensure that emails do not break the RFC, so then smtp would not
have to fix a problem that is not of its own making.

But postfix's sendmail does not honour the RFC or the
smtp_line_length_limit value and happily submits emails with overlong
lines, and this is where my problem occasionally arises, say when
emailing output from a cron job.

I have various workarounds, and can imagine more. But the elegant
solution would be to make postfix's sendmail program honour and
enforce the smtp_line_length_limit parameter, or (better, and
backwards-compatible) to create another parameter dictating whether
sendmail would do this (e.g. sendmail_fix_line_length as
yes/no[default]). Obviously the limit should be applied after any
sendmail_fix_line_endings setting has been processed. Or an entirely
independent sendmail_line_length_limit parameter could be created (if
it is awkward to have sendmail honouring an smtp_ parameter).

Is that possible or is it a bad idea?
Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

@lbutlr
On 18 Jun 2020, at 05:38, Dominic Raferd <[hidden email]> wrote:
> I understand the reason for smtp_line_length_limit and for its default
> value of 998, which is of course good.
>
> But it is an occasional problem for me that this wrapping action is
> only applied at smtp stage and not earlier; in particular it is after
> any (open)dkim milter adds its key, because smtp's wrapping means that
> the key then becomes invalid.

No, wrapping header lines does not affect DKIM if it is configured properly. The correct setting is c=relaxed which means that white space changes in headers are ignored. Setting it to simple instead will result in breaking because it makes DKIM reject RFC complain folding of long headers.

I don't even know why that setting exists, honestly.

(Your own message to the list used c=relaxed)\, which makes me think that perhaps your DKIM breaking is caused by something other than folding the header line?)

> But postfix's sendmail does not honour the RFC or the
> smtp_line_length_limit value and happily submits emails with overlong
> lines,

I believe the is because that is how sendmail works?

> and this is where my problem occasionally arises, say when
> emailing output from a cron job.

There is no reason to use sendmail to do that, especially if it causes a problem.



--
Slab: Jus' say 'AarrghaarrghpleeassennononoUGH'. --Feet of Clay


Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

Wietse Venema
In reply to this post by Dominic Raferd
Dominic Raferd:
> I understand the reason for smtp_line_length_limit and for its default
> value of 998, which is of course good.

It breaks DKIM signatures, it is needed only for mail that is sent
via SMTP, and worse, it breaks lines in the middle of a multibyte
character (and of course in the middle of a word, in the middle of
an HTML tag, and so on). So it really shuod not be considered a
reliable solution.

The main reason smtp_line_length_limit exists is to prevent other
MTAs from breaking MIME-formatted mail, where one huge message
header could cause all message content to become exposed in the
underlying encoding (base64 or quoted-printable).

If your problem is with cron job outputs that aren't sent across
the Internet, you could just disable this behavior by setting the
limit to zero, and by configuring other MTAs similarly.

Alternatively, as these cron jobs are under local control, you could
massage their output through a program that fixes long lines.

The sendmail command is a bad place for doing this, why not the
cleanup daemon?

        Wietse

-----

> But it is an occasional problem for me that this wrapping action is
> only applied at smtp stage and not earlier; in particular it is after
> any (open)dkim milter adds its key, because smtp's wrapping means that
> the key then becomes invalid.
>
> The standard answer would be that it is the responsibility of an MUA
> to ensure that emails do not break the RFC, so then smtp would not
> have to fix a problem that is not of its own making.
>
> But postfix's sendmail does not honour the RFC or the
> smtp_line_length_limit value and happily submits emails with overlong
> lines, and this is where my problem occasionally arises, say when
> emailing output from a cron job.
>
> I have various workarounds, and can imagine more. But the elegant
> solution would be to make postfix's sendmail program honour and
> enforce the smtp_line_length_limit parameter, or (better, and
> backwards-compatible) to create another parameter dictating whether
> sendmail would do this (e.g. sendmail_fix_line_length as
> yes/no[default]). Obviously the limit should be applied after any
> sendmail_fix_line_endings setting has been processed. Or an entirely
> independent sendmail_line_length_limit parameter could be created (if
> it is awkward to have sendmail honouring an smtp_ parameter).
>
> Is that possible or is it a bad idea?
>
Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

Wietse Venema
In reply to this post by @lbutlr
@lbutlr:
> No, wrapping header lines does not affect DKIM if it is configured =
> properly. The correct setting is c=3Drelaxed which means that white =

smtp_line_length_limit breaks DKIM relaxed mode, because it does
not wrap lines. That would require an understanding of header
or body contant that the code simply does not have.

Instead it just inserts <CR><LF><SPACE> in the middle of a string.
That's sufficient to preserve the structure of MIME and other
headers.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

@lbutlr
On 18 Jun 2020, at 09:24, Wietse Venema <[hidden email]> wrote:
> @lbutlr:
>> No, wrapping header lines does not affect DKIM if it is configured =
>> properly. The correct setting is c=3Drelaxed which means that white =
>
> smtp_line_length_limit breaks DKIM relaxed mode, because it does
> not wrap lines. That would require an understanding of header
> or body contant that the code simply does not have.

Ah. That's good to know then.




--
"Are you pondering what I'm pondering?"
"I think so, Brain, but couldn't the constant use of a henna rinse
        lead to premature baldness?"


Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

Dominic Raferd
In reply to this post by Wietse Venema
On Thu, 18 Jun 2020 at 15:03, Wietse Venema <[hidden email]> wrote:

>
> Dominic Raferd:
> > I understand the reason for smtp_line_length_limit and for its default
> > value of 998, which is of course good.
>
> It breaks DKIM signatures, it is needed only for mail that is sent
> via SMTP, and worse, it breaks lines in the middle of a multibyte
> character (and of course in the middle of a word, in the middle of
> an HTML tag, and so on). So it really shuod not be considered a
> reliable solution.
>
> The main reason smtp_line_length_limit exists is to prevent other
> MTAs from breaking MIME-formatted mail, where one huge message
> header could cause all message content to become exposed in the
> underlying encoding (base64 or quoted-printable).
>
> If your problem is with cron job outputs that aren't sent across
> the Internet, you could just disable this behavior by setting the
> limit to zero, and by configuring other MTAs similarly.
>
> Alternatively, as these cron jobs are under local control, you could
> massage their output through a program that fixes long lines.
>

Thanks for your answer and explanation.

Your second suggestion is what I do, but it is difficult to catch all
instances. I have now followed your first and set the limit to zero
(which I believe is undocumented as a way to turn off automatic
line-breaking). Actually I am relaying into Gmail so it will be
interesting to see if it copes with overlong lines.

> The sendmail command is a bad place for doing this, why not the
> cleanup daemon?

Answering that question is way above my pay grade.
Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

Dominic Raferd
On 18/06/2020 17:17, Dominic Raferd wrote:

> On Thu, 18 Jun 2020 at 15:03, Wietse Venema <[hidden email]> wrote:
>> Dominic Raferd:
>>> I understand the reason for smtp_line_length_limit and for its default
>>> value of 998, which is of course good.
>> It breaks DKIM signatures, it is needed only for mail that is sent
>> via SMTP, and worse, it breaks lines in the middle of a multibyte
>> character (and of course in the middle of a word, in the middle of
>> an HTML tag, and so on). So it really shuod not be considered a
>> reliable solution.
>>
>> The main reason smtp_line_length_limit exists is to prevent other
>> MTAs from breaking MIME-formatted mail, where one huge message
>> header could cause all message content to become exposed in the
>> underlying encoding (base64 or quoted-printable).
>>
>> If your problem is with cron job outputs that aren't sent across
>> the Internet, you could just disable this behavior by setting the
>> limit to zero, and by configuring other MTAs similarly.
>>
>> Alternatively, as these cron jobs are under local control, you could
>> massage their output through a program that fixes long lines.
>>
> Thanks for your answer and explanation.
>
> Your second suggestion is what I do, but it is difficult to catch all
> instances. I have now followed your first and set the limit to zero
> (which I believe is undocumented as a way to turn off automatic
> line-breaking). Actually I am relaying into Gmail so it will be
> interesting to see if it copes with overlong lines.
For information: setting smtp_line_length_limit = 0 works, however
having such a long line (in the mail body) still breaks the DKIM
signature. There must be something else going on (presumably unrelated
to postfix).
Reply | Threaded
Open this post in threaded view
|

Re: sendmail_fix_line_length enhancement request

Wietse Venema
Dominic Raferd:

> On 18/06/2020 17:17, Dominic Raferd wrote:
> > On Thu, 18 Jun 2020 at 15:03, Wietse Venema <[hidden email]> wrote:
> >> Dominic Raferd:
> >>> I understand the reason for smtp_line_length_limit and for its default
> >>> value of 998, which is of course good.
> >> It breaks DKIM signatures, it is needed only for mail that is sent
> >> via SMTP, and worse, it breaks lines in the middle of a multibyte
> >> character (and of course in the middle of a word, in the middle of
> >> an HTML tag, and so on). So it really shuod not be considered a
> >> reliable solution.
> >>
> >> The main reason smtp_line_length_limit exists is to prevent other
> >> MTAs from breaking MIME-formatted mail, where one huge message
> >> header could cause all message content to become exposed in the
> >> underlying encoding (base64 or quoted-printable).
> >>
> >> If your problem is with cron job outputs that aren't sent across
> >> the Internet, you could just disable this behavior by setting the
> >> limit to zero, and by configuring other MTAs similarly.
> >>
> >> Alternatively, as these cron jobs are under local control, you could
> >> massage their output through a program that fixes long lines.
> >>
> > Thanks for your answer and explanation.
> >
> > Your second suggestion is what I do, but it is difficult to catch all
> > instances. I have now followed your first and set the limit to zero
> > (which I believe is undocumented as a way to turn off automatic
> > line-breaking). Actually I am relaying into Gmail so it will be
> > interesting to see if it copes with overlong lines.
> For information: setting smtp_line_length_limit = 0 works, however
> having such a long line (in the mail body) still breaks the DKIM
> signature. There must be something else going on (presumably unrelated
> to postfix).

DKIM requires well-formatted email, and that includes respecting
any limits for transmission protocols. Again, there must be better
ways to do this than Postfix's line breaking of last resort: inserting
<CR><LF><SPACE> in a string in the middle of some multibyte character
or word.

Perhaps attaching the cronjob's output with 'mailx -a file.type'
is an option (where the filename suffix matches a rule in a MIME
type file; hopefully it will base64 encode the content). There is
a lot more about MIME in the Heirloom mailx manpage.

        Wietse