On 10/12/21 10:26, Brandon Long via mailop wrote:
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.
Ah, that's the piece I was missing, explains why no one encodes it and sends
long lines :) Thanks!
Definitely hairy.
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.
Sure, I suppose my question was more about who in the line to a mailing list here should have done
better - obviously the original sender's MUA should have not encoded a plaintext email as plain text
with a 1300-character line, but aside from that what's best-practice.
Should a MTA accepting mail from its own users for sending block the sending MUA from sending
bogusly-long encodings so that the user gets immediate feedback and it can ensure delivery?
Should a mailing list (in this case vger.kernel.org - probably one of the highest traffic MLs
around) reject mail that it cannot guarantee delivery of in the hopes the sender will get a more
immediate notification, or are there enough MTAs that don't reject long lines that its not worth it?
I presume most of us agree that a receiving MTA should probably mostly just accept such a thing,
given there's no serious technical limitation on long lines anymore (lol), though last I checked
exim's default configuration does not do this and will bounce such mail. I believe postfix doesn't
insert !s but instead just a space and a newline.
Matt
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
