Hi Todd, and thanks for your reply. On date Tuesday 2007-05-01 10:37:13 -0400, Todd Zullinger muttered: > Stefano Sabatini wrote: > > Hi mutters, > > > > I'm getting this strange behaviour when I try to verify the integrity > > of a message with mime type multipart/signed and signed with PGP. > > > > In most cases it works just fine, but in some cases I get something > > as: > > > > [-- PGP output follows (current time: Tue 01 May 2007 03:50:24 PM CEST) --] > > gpg: Signature made Tue 01 May 2007 03:34:27 PM CEST using DSA key ID > > XXXXXXXX > > gpg: Good signature from "xxxxxx xxxxxxx <xxxxxxxxxxxxxxxxxxxx>" > > gpg: WARNING: This key is not certified with a trusted signature! > > gpg: There is no indication that the signature belongs to the > > owner. > > Primary key fingerprint: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx > > [-- End of PGP output --] > > The important part is the gpg warning. It means that the key used to > sign the message isn't signed (certified) by your key (or the key of > someone else that you've marked as trusted). > > You can test this by adding a local signature to a key for which this > happens (gpg --lsign-key <keyid>).
I discovered this behaviour is dependant on the folder I'm exploring. There happens to be "good" folders and "bad" folders, in the good ones I can see the "s" flag right just when I open them in the index and the verify mechanism works as expected (that is good signatures results in a "S" flag), in the bad ones I can't see the "s" when opening them in the index, but it appears when I display the corresponding mail in the pager, and the "s" doesn't become "S" after I verify them even if they are good (according to the gpg output). I tried to figure out some relevant difference between the good and bad folders (I'm using maildir formats), but without success... very puzzling, so I have to conclude this is a rather strange bug. Anyway, apart from the strange "s"/"S" inconsistency, the gnupg output seems correct (I verified ti with corrupt signatures), so it means I don't have to blindly trust stupid flags ;-). Kind regards -- mutt tip #4 You can improve the modularity of your mutt configuration using the source command. Usage: source <filename>
