On 2021-04-21 03:32:07+0000, "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > 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)? I think replace "SMTP servers" with "mailing list managers" is correct. I don't feel comfortable to call it out, since I don't know if other managers do it that way or not. > > > 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. Make sense, this patch was sent mostly for some discussion first. Would you mind suggest something for the option. I'm thinking about --quoted-cr=<nowarn|warn|fix>, mimicking the --whitespace option. -- Danh
