Re: patch-1.1.1.me.pgpsearchtext.1

[Dirk Pirschel]

Hi,

On Wed, 05 Jan 2000, Michael Elkins wrote:

 NOTE: this should only be used as
 a last resort if you absolutely can't use procmail to rewrite your messages
 as suggested in doc/PGP-notes.txt.

The procmail rule only works if the mail is text/plain.
I sometimes get mails like

multipart/*
text/plain (cleartext signed)
other parts (not signed)

Are there any suggestions to handle these mails with procmail?

CU
Dirk

-- 
Dirk Pirschel  EMail: [EMAIL PROTECTED]
(PGP key on request)  [EMAIL PROTECTED]
   WWW: http://pirschel.de
"If Microsoft can change and compete on quality, I've won." -- Linus Torvalds

patch-1.1.1.me.pgpsearchtext.1

[Michael Elkins]

Though controversial, I feel that this patch is in the best interest of
promoting the use of PGP with Mutt.

This patch adds a new boolean variable $pgp_search_text which will cause Mutt
to search for the first non-blank line in every text/plain message to see if
it is a mislabeled old-style PGP message.  NOTE: this should only be used as
a last resort if you absolutely can't use procmail to rewrite your messages
as suggested in doc/PGP-notes.txt.

I only tested this with Mutt 1.1.1i, but it should work with the 1.0 series
as well.

me
-- 
pgp key available from http://www.cs.hmc.edu/~me/elkins-pgp-key.asc


diff -durp mutt-1.1.1/doc/manual-6.html mutt-1.1.1.pgpsearchtext/doc/manual-6.html
--- mutt-1.1.1/doc/manual-6.htmlMon Nov  8 10:03:16 1999
+++ mutt-1.1.1.pgpsearchtext/doc/manual-6.html  Wed Jan  5 00:59:47 2000
@@ -1617,6 +1617,21 @@ variable is only used if ``mime_forward'
 ``mime_forward_decode'' is EMunset/EM.
 P
 P
+H3A NAME="pgp_search_text"/A pgp_search_text/H3
+
+PType: booleanBR
+Default: no
+P
+PControls whether Mutt will search text/plain messages for old style
+PGP message which are not properly labled using MIME header fields.
+If the first non-blank line in a message contains quot;-BEGIN PGPquot;
+it will be assumed that it is an aplication/pgp content-type.
+NOTE: this option should only be used as a last resort when procmail
+is not available on your system. See doc/PGP-notes.txt for the
+recommended way to handle old-style messages.  Using this option may
+lead to longer time required to parse your mailbox.
+P
+P
 H3A NAME="pipe_split"/A pipe_split/H3
 
 PType: booleanBR
diff -durp mutt-1.1.1/doc/manual.sgml mutt-1.1.1.pgpsearchtext/doc/manual.sgml
--- mutt-1.1.1/doc/manual.sgml  Mon Nov  8 10:01:46 1999
+++ mutt-1.1.1.pgpsearchtext/doc/manual.sgmlWed Jan  5 00:59:34 2000
@@ -4249,6 +4249,22 @@ variable is only used if ``mimelowbar;f
 ``mimelowbar;forwardlowbar;decode'' is emunset/em.
 
 
+sect2pgplowbar;searchlowbar;textlabel id="pgp_search_text"
+p
+Type: booleannewline
+Default: no
+
+p
+Controls whether Mutt will search text/plain messages for old style
+PGP message which are not properly labled using MIME header fields.
+If the first non-blank line in a message contains dquot;-BEGIN PGPdquot;
+it will be assumed that it is an aplication/pgp content-type.
+NOTE: this option should only be used as a last resort when procmail
+is not available on your system. See doc/PGP-notes.txt for the
+recommended way to handle old-style messages.  Using this option may
+lead to longer time required to parse your mailbox.
+
+
 sect2pipelowbar;splitlabel id="pipe_split"
 p
 Type: booleannewline
diff -durp mutt-1.1.1/doc/muttrc.man mutt-1.1.1.pgpsearchtext/doc/muttrc.man
--- mutt-1.1.1/doc/muttrc.man   Mon Nov  8 10:01:47 1999
+++ mutt-1.1.1.pgpsearchtext/doc/muttrc.man Wed Jan  5 00:59:48 2000
@@ -2226,6 +2226,23 @@ variable is only used if \(lqmime_forwar
 
 
 .TP
+.B pgp_search_text
+.nf
+Type: boolean
+Default: no
+.fi
+.IP
+Controls whether Mutt will search text/plain messages for old style
+PGP message which are not properly labled using MIME header fields.
+If the first non-blank line in a message contains \(rq-BEGIN PGP\(rq
+it will be assumed that it is an aplication/pgp content-type.
+NOTE: this option should only be used as a last resort when procmail
+is not available on your system. See doc/PGP-notes.txt for the
+recommended way to handle old-style messages.  Using this option may
+lead to longer time required to parse your mailbox.
+
+
+.TP
 .B pipe_split
 .nf
 Type: boolean
diff -durp mutt-1.1.1/init.h mutt-1.1.1.pgpsearchtext/init.h
--- mutt-1.1.1/init.h   Sun Nov  7 13:15:24 1999
+++ mutt-1.1.1.pgpsearchtext/init.h Wed Jan  5 00:58:50 2000
@@ -1276,6 +1276,18 @@ struct option_t MuttVars[] = {
   { "forw_decrypt",DT_SYN,  R_NONE, UL "forward_decrypt", 0 },
   /*
   */
+  { "pgp_search_text", DT_BOOL, R_NONE, OPTPGPSEARCHTEXT, 0 },
+  /*
+  ** .pp
+  ** Controls whether Mutt will search text/plain messages for old style
+  ** PGP message which are not properly labled using MIME header fields.
+  ** If the first non-blank line in a message contains "-BEGIN PGP"
+  ** it will be assumed that it is an aplication/pgp content-type.
+  ** NOTE: this option should only be used as a last resort when procmail
+  ** is not available on your system. See doc/PGP-notes.txt for the
+  ** recommended way to handle old-style messages.  Using this option may
+  ** lead to longer time required to parse your mailbox.
+  */
 #endif /* _PGPPATH */
   
   { "pipe_split",  DT_BOOL, R_NONE, OPTPIPESPLIT, 0 },
diff -durp mutt-1.1.1/mutt.h mutt-1.1.1.pgpsearchtext/mutt.h
--- mutt-1.1.1/mutt.h   Sun Nov  7 13:15:30 1999
+++ mutt-1.1.1.pgpsearchtext/mutt.h Wed Jan  5 00:37:53 2000
@@ -355,6 +355,7 @@ enum
   OPTPGPSTRICTENC,
   OPTFORWDECRYPT,
   OPTPGPSHOWUNUSABLE,
+  OPTPGPSEARCHTEXT,
 #endif
 
   /* pseudo options */
diff -durp mutt-1.1.1/parse.c 

Re: patch-1.1.1.me.pgpsearchtext.1

[Michael Elkins]

I just realized that this patch does not solve the problem which started this
whole thread, which is dealing with an IMAP server.  Unless there is a way
to fetch the first couple of lines of the body of a message with IMAP, I don't
see a clean way to accomplish automatic handling.  The next best option would
be to implement the idea about binding a function to a key which forces a
message to be interpreted as application/pgp.

me

 PGP signature

Re: patch-1.1.1.me.pgpsearchtext.1

[Brendan Cully]

On Wednesday, 05 January 2000 at 01:45, Michael Elkins wrote:
 I just realized that this patch does not solve the problem which started this
 whole thread, which is dealing with an IMAP server.  Unless there is a way
 to fetch the first couple of lines of the body of a message with IMAP, I don't
 see a clean way to accomplish automatic handling.  The next best option would
 be to implement the idea about binding a function to a key which forces a
 message to be interpreted as application/pgp.

I'm fairly sure that IMAP can do that, although it's not in mutt right
now. It might be handy for reducing latency and allowing interruptions
or partial display of large messages, too. The trickier bits are in
getting mutt to understand a partial message, and I expect in
interactions within the pager...

-Brendan

Re: patch-1.1.1.me.pgpsearchtext.1

[Christopher Smith]

On Wed, Jan 05, 2000 at 01:45:33AM -0800, Michael Elkins wrote:
 I just realized that this patch does not solve the problem which started this
 whole thread, which is dealing with an IMAP server.  Unless there is a way
 to fetch the first couple of lines of the body of a message with IMAP, I don't
 see a clean way to accomplish automatic handling.  The next best option would
 be to implement the idea about binding a function to a key which forces a
 message to be interpreted as application/pgp.
I still prefer the key binding, but here's some relevant text (if you
want to go automated) from the IMAP RFC
(http://www.isi.edu/in-notes/rfc2060.txt): 

6.4.5.  FETCH Command

[...stuff deleted...]

  The currently defined data items that can be fetched are:

  ALLMacro equivalent to: (FLAGS INTERNALDATE
 RFC822.SIZE ENVELOPE)

  BODY   Non-extensible form of BODYSTRUCTURE.

  BODY[section]partial
 The text of a particular body section.

[...stuff deleted...]

 It is possible to fetch a substring of the
 designated text.  This is done by appending an open
 angle bracket (""), the octet position of the
 first desired octet, a period, the maximum number
 of octets desired, and a close angle bracket ("")
 to the part specifier.  If the starting octet is
 beyond the end of the text, an empty string is
 returned.

 Any partial fetch that attempts to read beyond the
 end of the text is truncated as appropriate.  A
 partial fetch that starts at octet 0 is returned as
 a partial fetch, even if this truncation happened.

  Note: this means that BODY[]0.2048 of a
  1500-octet message will return BODY[]0
  with a literal of size 1500, not BODY[].

  Note: a substring fetch of a
  HEADER.FIELDS or HEADER.FIELDS.NOT part
  specifier is calculated after subsetting
  the header.

[...stuff deleted...]

  BODY.PEEK[section]partial
 An alternate form of BODY[section] that does not
 implicitly set the \Seen flag.

That should explain the relevant parts.

--Chris
 PGP signature