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