Hi David, David T-G wrote:
> How, however, is the proposed behavior (making $p_c_t generate a
> text/plain instead of an application/pgp message) different from what we
> have now with $p_c_t and $p_o_c? Note that I don't say that it fixes the
> problem you bring up, but it will fix the problem as Cristian wrote --
> for any message that would have been text/plain anyway.
$p_c_t and $p_o_c do exactly what is proposed: Create a clear-signed
message with "Content-Type: text/plain". This way, Outlook users see
the content of the message in the message window and not as two
attachments. This is *good*.
Unfortunately, if the message contains any hi-bit characters (like
German umlauts or most other non-English languages), ie. if the charset
is not us-ascii, $p_c_t and thus $p_o_c never get evaluated. See the
function pgp_protect() in pgp.c for that.
So for mails which are iso-latin-1 or something else, mutt will always
create a message that is PGP/MIME signed. While this might be what the
standard suggests (I don't really know), it breaks for a lot of people
and is not what I call user-friendly.
> Right. Thus there are lots of folks with macros out there, which
> I personally don't like because I think that mutt should be able to
> handle it. As it stands I just whine a really lot and then just make
> my LookOut! users deal with MIME encryption :-)
Exactly. I also have a macro, which re-maps the "y"-key (default for
send-message) and filters the message through `gpg --clearsign`. This
is nearly perfect, as I don't have to remember anything special for
Outlook users. I just always hit "y" and mutt does the right thing. It
has three drawbacks, though:
- I have to enter the passphrase, ie mutt won't use it's
remembered passphrase for those messages. Irritating, esp.
for newbies.
- There is a possibility of data loss. If you exceed all
retry-attempts of gnupg, because of a bad passphrase, the
message is lost, because it is replaced by the output of
gnupg, which is empty in this case. This is not common, but
nonetheless a Bad Thing [tm].
- It's not very aesthetical (sp?). As you have said: mutt
should be able to do that internally.
> % Here's a patch which creates pgp_force_traditional, which if
> % p_c_t is set, will always create a clear-signed PGP messages (not sure
> % for mails of attachments though). That way, p_o_c can do the job it's
> % supposed to do. I haven't tested it a lot since I wrote it, but it
> % appears to do the right thing.
>
> That's a start. I haven't learned about either the workings of mutt or
> the structure of the messages, but does this generate iso-latin-1 or
> text/plain messages?
It generates text/plain messages with a charset different from us-ascii,
eg. iso-latin-1. Ie, the headers look like this:
Content-Type: text/plain; charset=iso-latin-1
Content-Transfer-Encoding: 8bit
BTW, you'll get exactly the same headers if you clear-sign the message
outside of mutt and send it then. Contrast messages that are created
with $p_c_t and $p_o_c, which only have this header:
Content-Type: text/plain
There is no Content-Transfer-Encoding; it would be 7bit though.
I don't really now a lot about e-mail standards, however a message can
be text/plain and have any charset (as indicated above).
BTW, I determine the Content-Type and the Transfer-Encoding by taking
the values from the original, non-signed message. Dunno if that's the
Right Thing [tm], but it appears to me, that clear-signing the message
outside of mutt would do exactly the same. Can someone from mutt-dev
clear that up?
> % Patch is against mutt-1.3.24, I'll test it tomorrow against 1.3.25, and
> % you need to have the pgp_outlook_compat patch applied first.
> %
> % I don't know a lot about the mutt source, so this might break stuff,
> % haven't tested it a lot.
>
> I'll probably wait for you to test more and perhaps wait to see how the
> mutt source itself shakes down, but I like the idea.
The problem is, that I don't know a lot about e-mail, I just use it
daily. :) In fact, I didn't check it with Outlook yet, I went to bed,
when I received a message without data loss (ie äöü did not become ???)
with the right headers.
Also, with this patch $p_c_t will still be ignored, when the message is
not of text/plain, ie any message with attachment. See again
pgp_protect(), why this is so. I don't really know how to do it
differently, ie clear-signing the message and leaving the attachment as
it is or signing everything. I don't know enough about the mutt
workings. :(
Okay, this was long. Could someone with inside knowledge of mutt and
the relevant standards please comment on this patch? BTW, it won't
cause any data loss, the worst thing that can happen is that you receive
a message which signature can't be verified, so it would be nice, if
some people could test it. My access to an Outlook machine is somewhat
limited. :)
Cheers,
Viktor
PS: I resent the patch as yesterday's mail to mutt-dev got dropped,
because I wasn't subscribed.
--
Viktor Rosenfeld
WWW: http://www.informatik.hu-berlin.de/~rosenfel/
diff -ur mutt-1.3.24-outlook+compress/init.h mutt-1.3.24-vrr/init.h
--- mutt-1.3.24-outlook+compress/init.h Thu Jan 3 20:45:04 2002
+++ mutt-1.3.24-vrr/init.h Thu Jan 3 20:39:56 2002
@@ -1311,6 +1311,25 @@
** to generate messages readable by users of MS Outlook using PGP.
*/
+ { "pgp_force_traditional", DT_BOOL, R_NONE, OPT_PGPFORCETRAD, 0},
+ /*
+ ** .pp
+ ** If pgp_create_traditional is defined above, this option will force
+ ** the creation of old-style PGP messages for text/plain messages, even when
+ ** the character set is different from us-ascii.
+ **
+ ** .pp
+ ** This option really only makes sense together with pgp_create_traditional
+ ** and pgp_outlook_compat; when all three are set, Outlook users will be
+ ** able to read any mail, including language-specific characters like
+ ** German umlauts, without problems.
+ **
+ ** .pp
+ ** Note, however, that using the old-style PGP message format is
+ ** \fBdeprecated\fP, and the using the old-style PGP message format with a
+ ** character set other than us-ascii might result in broken signatures.
+ */
+
/* XXX Default values! */
{ "pgp_decode_command", DT_STR, R_NONE, UL &PgpDecodeCommand, 0},
diff -ur mutt-1.3.24-outlook+compress/mutt.h mutt-1.3.24-vrr/mutt.h
--- mutt-1.3.24-outlook+compress/mutt.h Thu Jan 3 20:45:04 2002
+++ mutt-1.3.24-vrr/mutt.h Thu Jan 3 20:30:56 2002
@@ -258,6 +258,7 @@
#ifdef HAVE_PGP
OPT_VERIFYSIG, /* verify PGP signatures */
OPT_PGPTRADITIONAL, /* create old-style PGP messages */
+ OPT_PGPFORCETRAD, /* force old-style PGP messages even for non us-ascii */
OPT_PGPOUTLOOK, /* Create even older broken outlook compatible messages */
#endif
diff -ur mutt-1.3.24-outlook+compress/pgp.c mutt-1.3.24-vrr/pgp.c
--- mutt-1.3.24-outlook+compress/pgp.c Thu Jan 3 20:44:59 2002
+++ mutt-1.3.24-vrr/pgp.c Fri Jan 11 01:21:47 2002
@@ -1646,7 +1646,9 @@
b = mutt_new_body ();
- b->encoding = ENC7BIT;
+ b->parameter = (PARAMETER *) malloc(sizeof(PARAMETER));
+ b->parameter = memcpy(b->parameter, a->parameter, sizeof(PARAMETER));
+ b->encoding = a->encoding;
/* Outlook seems to work by scanning the message itself for PGP information, */
/* not the headers. If the headers are anything but text/plain, it will */
@@ -1710,7 +1712,9 @@
if ((msg->content->type == TYPETEXT) &&
!ascii_strcasecmp (msg->content->subtype, "plain") &&
- ((flags & PGPENCRYPT) || (msg->content->content && msg->content->content->hibin
== 0)))
+ ((flags & PGPENCRYPT) || (msg->content->content &&
+ msg->content->content->hibin == 0) ||
+ option(OPT_PGPFORCETRAD)))
{
if ((i = query_quadoption (OPT_PGPTRADITIONAL, _("Create an application/pgp
message?"))) == -1)
return -1;
msg22969/pgp00000.pgp
Description: PGP signature
