On 2021-04-21 at 01:34:04, Đoàn Trần Công Danh wrote: > When an SMTP server receives an 8-bit email message, possibly with only > LF as line ending, some of those servers decide to change said LF to > CRLF. > > Some other SMTP servers, when receives an 8-bit email message, decide to > encoding such message in base64 and/or quoted-printable instead. This really isn't an SMTP server. It's mailing list software, namely mailman, and I would argue it's a bug, even though we may want to work around it. For example, re-encoding the message breaks DKIM signatures, which means that mailman is likely to cause mail to be needlessly rejected. 8BITMIME is now so common with SMTP that I'd argue that we should just write off servers that don't support it (especially in the context of SMTPUTF8 existing), but this isn't the case of an SMTP server being stuck in the last century. Can we say more accurately that this is mailing list software (or just call it out by name)? > If an email is transfered through those 2 email servers in order, the > final recipients will receive an email contains a patch mungled with > CRLF encoded inside another encoding. Thus, such CR couldn't be dropped > by mailsplit. Such accidents have been observed in the wild [1]. > > Let's guess if such CR was added automatically and strip them in > mailinfo. > > [1]: https://nmbug.notmuchmail.org/nmweb/show/m2lf9ejegj.fsf%40guru.guru-group.fi > > Signed-off-by: Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> > --- > > I'm not sure if guessing the heuristic to strip CR is a good approach. > I think it's better to pass --keep-cr down from git-am. > Let's say --keep-cr=<yes|no|auto> I think we may want a separate option here. When I send a 7bit or 8bit body, I expect text canonicalization on the line endings. However, when I send a base64 or quoted-printable body, I don't expect my data to be modified at all, and absent a compelling reason, doing so is incorrect. In most cases, using base64 or quoted-printable is going to mean that the sender knew that the body shouldn't be modified, not that mailman modified it, so we should make line munging in this case opt-in. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
