Also, there is a tension in the rfc's here, because you aren't allowed to encode message/rfc822, so you would have to edit the attached file.
We used to base64 encode the message/rfc822 anyways, but we had enough receivers not able to handle that, so we had to revert. We debated just using message/global instead, but I think even fewer receivers understood that. Of course, we also will happily use BDAT if the remote server supports it, which doesn't have the line length limitation. Brandon On Mon, Oct 11, 2021 at 10:46 PM John via mailop <mailop@mailop.org> wrote: > Hello Matt, > > The answer is yes, it's not good practice to block messages containing > long lines in emails. That will likely cause problems at either the sender > or recipient. Senders may receive non-delivery notifications, recipients > may miss mails. > > RFC5322 (2008) advises to handle long lines at least up to 998 characters. > However, there is no pressing technical need to filter. The 1000 character > rule appeared in rfc821 (1982), probably because it was believed that it > was a good idea to limit the format to the capacity of hardware and > software at the time. We've moved on, systems have sufficient memory and > mail readers have been smart enough to wrap long lines for a long time > already. > > Some mail servers insert exclamation marks if the lines get too long > around 998 characters, that's what Sendmail and Postfix did. Editing > content is destructive and it can cause real world problems. On a technical > level, rewriting content can cause malware and other unwanted mails not be > recognized by mail scanners. Downstream, mail servers may attempt to > reconstruct the mail, and then it could have bypassed perimiter filters. > Also, rewriting mails can cause signatures to break. So it's generally a > bad idea to rewrite messages, except for prepending headers. Mailing lists > often rewrite mails, and that pracice is well known to cause authentication > problems, but sometimes it cannot be avoided. > > I do think that we should keep the current format in this version of SMTP. > Developers who want to send long text lines can do so using methods > available such as MIME and base64 or quoted printable encoding. > > John > > On 10/12/2021 03:06 AM, Matt Corallo via mailop wrote: > > Today I was trying to help debug an email list that wasn't properly > filtering mail by the > > 1000-character SMTP line-length limit. This required attaching the > original, SMTP-invalid .eml to > > send to the postmaster there. > > > > However, it seems MUAs nearly-universally do not handle this correctly. > Specifically, at least > > GMail's Web UI, Apple iOS Mail, and local Thunderbird all happily attach > the original .eml as-is in > > plaintext and create mails which violate the SMTP limit. > > > > Is the 1000-character limit just old hat these days and ignored enough > places that its not worth > > bothering with? > > > > Matt > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
