On Fri 02 Oct 2020 at 13:18:29 (+0200), Linux-Fan wrote:– > > OT: The hints about the details of e-mail encoding and signing are > appreciated. Some other notes are here: > https://sourceforge.net/p/courier/mailman/courier-cone/?viewmonth=202010
I took a look at that thread. > From: Linux-Fan <Ma_Sys.ma@we...> - 2020-10-02 11:30:16 > > I discovered that the workaround is exactly to use some 8-bit > > characters which will avoid the re- encoding throughout transmission. Exactly what I would suggest, and the opposite of my advice in https://lists.debian.org/debian-user/2020/06/msg00598.html where the problem was reversed. So you could hit all your replies by modifying your attribution (as I have, above), but better would be the hyphen in your sign–off (← as here) particularly if it's automated, like mine. (I don't make my sign-off into a syntactical signature.) I don't know how entirely 7bit attachments would be treated. > From: Sam Varshavchik <mrsam@co...> - 2020-10-02 11:21:44 > > Cone already uses quoted-printable when the message contains 8-bit > > characters. I'd use base64, myself, with a signed message. > > There is no valid reason whatsoever to reencode 7-bit only mail > > content. I cannot find any documentation that specifies any > > restrictions on signed mail, other than to avoid 8-bit content. Note that you have been using Content-Type: … charset="UTF-8" RFC 3156 says "many existing mail gateways will detect if the next hop does not support MIME or 8-bit data and perform conversion to either Quoted-Printable or Base64". > > Trying to work around someone else's bugs is a major waste of > > time. The correct solution is for someone else to fix the bug. … which, of course, is nonsense. Since mid-August, I have been using a different email smarthost for posts to just this list because two MTAs are currently unable to cooperate successfully. Should I stay silent until that bug is fixed? (Don't answer that!) They obviously haven't read the RFC: "Implementor's note: It cannot be stressed enough that applications using this standard follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer- encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly." So my guess is that your mailer is sending *potentially* 8bit content without encoding it, and an MTA is encoding it because it's not expected to check for solely 7bit content just because Content-Transfer-Encoding is set to 7bit. Sorry that I can't check whether your signing is successful as I don't maintain any personal keyring. Cheers, David.
