Re: New thread about PGP sigs, part 1: Mutt disagrees with g…

On 2016-09-22 20:01, Claus Assmann wrote:

> You can debug what mutt does:
>
> set pgp_verify_command="/tmp/v %s %f"
>
> where /tmp/v is some simple script like:
>
> cat "$1" >/tmp/sig
> cat "$2" >/tmp/body
>
> so now you have what mutt considers the body and the signature and
> you can invoke gpg on it yourself, e.g.,
>
> gpg --verify /tmp/sig /tmp/body
>
> and you can compare these files with those that you used as input
> for your gpg check.

Thanks, this helped, if only indirectly :P

I have to declare mutt innocent in this instance. What happened was
that something in the transit or delivery path applied the following
transformations:

1. Where a leading dot was QP-encoded as =2E, unapplied the encoding and
changed it into a literal dot.

2. Reflowed binary base-64 encoded parts from 72 chars per line to 60.

It is not surprising that the signature no longer matches after these
changes :-)

Of course I'd love to hear tips on what software (MTA or MDA) can do
this, but I recognize such talk will be OT.

Unless it _is_ mutt doing this when moving the mail from the new/
maildir subdirectory to cur/. Possible? How may I eliminate this possibility?

--
Please *no* private Cc: on mailing lists and newsgroups
Why does the arrow on Hillary signs point to the right?