#38 should wrap recipient addresses in <>

Martins Krikis

Just stumbled on the following problem.
I was sending to "Joe Simple <simple@foo.com>",
so mailcrypt ran it through rfc822-addresses and
asked me
Recipients: simple@foo.com
I accepted this without suspecting anything and
it encrypted. Turns out it encrypted for
bill.simple@foo.com, Joe's sibling.

So this is what I think (and it may be GPG-specific,
I have no idea how PGP works).
Because it does strip the actual email addresses
out of the To, CC, BCC lines, they should be used
with exact matching, i.e., the gpg command line
should have had "--recipient <simple@foo.com>",
not the substring-matching "--recipient simple@foo.com"
which allowed gpg to encrypt it for bill.simple@foo.com.

In other words, the following patch for mailcrypt.el
seems to fix the problem for me (and I did verify it for
multiple addresses, too):

--- mailcrypt.el.orig 2005-04-07 10:41:20.000000000 -0400
+++ mailcrypt.el 2005-04-07 10:41:49.000000000 -0400
@@ -408,7 +408,7 @@

(defsubst mc-strip-address (addr)
"Strip everything from ADDR except the basic Email
- (car (rfc822-addresses addr)))
+ (concat "<" (car (rfc822-addresses addr)) ">"))

(defun mc-strip-addresses (addr-list)
"Strip everything from the addresses in ADDR-LIST
except the basic


  • nega

    • assigned_to: nobody --> nega
    • status: open --> pending-remind
  • nega

    Logged In: YES
    Originator: NO

    Make sure this isn't addressed in the dev branch

    • status: pending-remind --> closed-remind
  • Logged In: YES
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • Logged In: NO

    I'm very impressed with the bug-fixing policy of this project.
    First 2 years and 8 months go buy until a bug is looked at, then
    the submitter is given an order to check the "dev branch" (which
    he/she may not and need not really know about), and then the bug
    is closed if the submitter doesn't report back in 2 weeks. Pretty
    convenient and way easier than evaluating whether a single-line
    fix that was submitted with the bug actually has some merit.