I use compose-mail and mml-secure-message-sign to send signed email.
For messages that contain cyrillic characters Emacs by default uses
utf-8 charset and base64 encoding. For such messages some MUAs (Mutt,
Notmuch) report good signature and some (Sylpheed, Evolution) show bad
signature for the same message.
When quoted-printable encoding is used all MUAs show good signature
(workaround: add (utf-8 . quoted-printable) to
mm-body-charset-encoding-alist).
When base64 encoding is used, the encoded data is separated from part
boundary delimiter by a single <CR><LF> (which is part of the delimiter)
missing an additional <CR><LF> to terminate the last line of the encoded
data. I verified by manually editing raw email files and appropriately
updating signatures that mentioned MUAs handle messages with a single
<CR><LF> between signed data and delimiter differently. This seems to
be the cause of the problem.
From RFC 2015 "MIME Security with PGP", page 4:
When the PGP digital signature is generated:
[skip]
(2) An appropriate Content-Transfer-Encoding is then applied. Each
line of the encoded data MUST end with the canonical <CR><LF>
sequence.
From RFC 3156 "MIME Security with OpenPGP", page 5:
When the OpenPGP digital signature is generated:
[skip]
(2) An appropriate Content-Transfer-Encoding is then applied; see
section 3. In particular, line endings in the encoded data
MUST use the canonical <CR><LF> sequence where appropriate
(note that the canonical line ending may or may not be present
on the last line of encoded data and MUST NOT be included in
the signature if absent).
[skip]
Note: The accepted OpenPGP convention is for signed data to end
with a <CR><LF> sequence. Note that the <CR><LF> sequence
immediately preceding a MIME boundary delimiter line is considered
to be part of the delimiter in [3], 5.1. Thus, it is not part of
the signed data preceding the delimiter line. An implementation
which elects to adhere to the OpenPGP convention has to make sure
it inserts a <CR><LF> pair on the last line of the data to be
signed and transmitted (signed message and transmitted message
MUST be identical).
So it seems to be correct and better for compatibility with other email
clients to terminate the last line of base64 encoded data with <CR><LF>.
--
Mikhail
In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.6.4)
of 2013-04-19 on home
Windowing system distributor `Fedora Project', version 11.0.11303000
Configured using:
`configure '--host=x86_64-redhat-linux-gnu'
'--build=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
'--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
'--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g''
Important settings:
value of $LANG: ru_RU.utf8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
pgpzS5YZc79WR.pgp
Description: PGP signature
--- End Message ---