How to make mutt NOT add a PGP/GPG signature to a specific email address

If you use the awesomely versatile and lightening fast mutt email client and you have it set to cryptographically sign each outgoing message by default using PGP or the free and rock solid GPG, then you probably have one friend or colleague who complains that they can't read your messages. This is a maddening problem if you don't know how to solve it.

The core problem is that certain email clients, for example the new(ish) "Microsoft Mail" in Vista, and its direct ancestor Outlook Express, do not follow the MIME RFCs as closely as most other email clients. Consequently, when encountering an attached GPG or PGP email signature, they behave in a strange way: the message body appears to be blank and has the dreaded ATT file listed as an attachment to the message. The user will not be able to read the ATT file to view your message. But if she opens the same message in (for example) a webmail client, the message body is viewable just like any other message. Further proof pointing to your PGP/GPG signature being the problem is the fact that when you send her an unsigned email message she can read it without problems. Your Windowsy friend is frustrated. You're frustrated. And mutt, GPG, and Unix are looking bad.

Mutt's endlessly configurable settings come to the rescue. I found that you can automatically NOT sign messages to particular users. You use the familiar send-hook directive in mutt. But the magic is that you have to tell it to also DO sign messages if they are NOT addressed to that particular user. So, in your ~/.mutt/gpg file, at the top you must add the following:

## The following three parameters must be set 
## in this order inyour ~/.mutt/gpg file:

# pgp sign messages by default
set pgp_autosign=yes

# but don't sign messages to janedoe
send-hook janedoe 'set nopgp_autosign'

# but do sign messages to anyone who is NOT janedoe
send-hook !janedoe 'set pgp_autosign=yes'

## End of stuff that must be in a certain order 

Now your friend will be able to view your messages in her favorite (though non-RFC-compliant) email client program. But alas, as with anything that changes security settings for the sake of user convenience, there is a downside to this hack: the messages you send to janedoe will never be cryptographically signed. Worse, if you send a message to her and ten other people, her settings take precedence, and your message to all eleven people will not be cryptographically signed.

If you require provable integrity and non-repudiation of your messages to janedoe then this hack is not the right one for you.