Re: Signing emails, was Re: General-Purpose Server for Debian Stable
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.
Reply to: