patch-1.1.1.me.pgpsearchtext.1
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: Y100 (was: mutt y2k)
On 2000-01-04 10:40:46 +0100, Martin Schröder wrote: The year 100 is converted by date_format="%Y-%m-%d %H:%M:%S %Z" to 2000. Problem of mutt or of strftime? I wouldn't really consider this a problem - after all, it cought quite a bit of y2k-related nonsense emitted by other software, and, in addition, year numbers less then 1978 (?) can't legitimately appear in RFC 822 messages. ;-) -- http://www.guug.de/~roessler/
Re: patch-1.1.1.me.pgpsearchtext.1
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: send-hook, personalities and reply
Mikko Hänninen [[EMAIL PROTECTED]] wrote: Mat [EMAIL PROTECTED] wrote on Thu, 30 Dec 1999: set reverse_name# reply as the user to whom the mail was sent to This is what you want. If it doesn't work, make sure you don't have any "my_hdr From:" definitions. Also, be sure to make sure your alternates setting is correct. (I'm not sure if that's needed for $reverse_name, but it's a good idea to have it set up properly anyway.) For example, this is (part of) what I use: It is needed. It's the only way Mutt knows which mails are to you when you have multiple addresses. set alternates=^([EMAIL PROTECTED]|[EMAIL PROTECTED]|mikko@.*dna.fi)$ -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Default delete
Okay, back on the default delete question. In order to automatically save all messages to archive instead of deleting them, I made a macro for key "d." Unfortunately, this is still not the action that I want because it forces me to hit enter for every file. I'm on a large number of lists, and I like the ability of holding down the "d" key and having the delete function scroll down through 50 messages. Having to hit "d"enter for every message is a pain in the butt. Half the reason I love UNIX is that I don't *have* to do things a certain way if I don't want to. Any suggestions from the gurus? If not, I'll be forced to read the code. It's C right? I'm warning you, there may not be much to dig out of the roach-ridden rubble if I go through the code :-) -- Windows users awaken! The Matrix has you! Jonathan Pennington | -Wannabe Geologist/Anthropologist Charleston, SC | -Linux Advocate FreeBSD User Email at jwp(at)awod.com| '83 V45 Magna "The Lighter Side" AOL Instant Messenger: Kuthu| '71 Triumph Pile of Rust: For Sale See: http://www.marko.net/gaim | (Space Available for V65 Sabre) -
Re: Default delete
Jonathan Pennington [[EMAIL PROTECTED]] wrote: Okay, back on the default delete question. In order to automatically save all messages to archive instead of deleting them, I made a macro for key "d." Unfortunately, this is still not the action that I want because it forces me to hit enter for every file. I'm on a large number of lists, and I like the ability of holding down the "d" key and having the delete function scroll down through 50 messages. Having to hit "d"enter for every message is a pain in the butt. Half the reason I love UNIX is that I don't *have* to do things a certain way if I don't want to. Add enter to the end of your macro body. -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Collapsed threads and pattern tagging
Hi, If I have my threads collapsed in a mailbox, and tag them with T*, not all messages are selected; only the ones visible in the index! The messages that are hidden in the collapsed threads are NOT selected. How can I solve this apart from first expanding the threads? Ray -- Raymond A. Meijer True Bit BV
Re: Collapsed threads and pattern tagging
Raymond A. Meijer [[EMAIL PROTECTED]] wrote: If I have my threads collapsed in a mailbox, and tag them with T*, not all messages are selected; only the ones visible in the index! The messages that are hidden in the collapsed threads are NOT selected. How can I solve this apart from first expanding the threads? To my knowledge you can't. Operations act only on messages that are non-hidden. This is consistent with this being true when you apply a limit to messages, and then expect operations to only act inside the limit you gave. It was decided messages hidden by thread collapsing should be treated the same way as those hidden by a limit. If you find yourself needing this often, a workaround would be a macro to do collapse-all,tag all,collapse-all. The display isn't updated til the end of a macro, so you wouldn't really see them uncollapse at all. Note this isn't optimal, as it will only work if you start with *all* threads collapsed, because of the way collapse-all works as a toggle. -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: Collapsed threads and pattern tagging
Jeremy Blosser [EMAIL PROTECTED] wrote on Wed, 05 Jan 2000: To my knowledge you can't. Operations act only on messages that are non-hidden. This is consistent with this being true when you apply a limit to messages, and then expect operations to only act inside the limit you gave. Maybe there should be an operator which will match all messages, hidden or not? Since ~A is all, it could be ~a (but this is a bit un-intuitive, ~a should be "all visible" and ~A "all, visible and non-visible". Maybe ~H for "hidden" would be a better choice... Or possibly just make a ~H operator that will match only hidden messages, so that ~A ~H will match everything? Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Did you know that 7/5 people don't know how to use fractions?
Re: patch-1.1.1.me.pgpsearchtext.1
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
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
[MAILER-DAEMON@trib.com: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA]
I get the following message from my ISP. I see it on Mutt and Eudora. I am using Fetchmail and IMAP to fetch mail from the ISP. Is this anything I need to worry about? - Forwarded message from Mail System Internal Data - Date: Tue, 4 Jan 2000 18:17:08 -0700 (MST) From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. - End forwarded message - -- -- C^2 No windows were crashed in the making of this email. Looking for fine software and/or web pages? http://w3.trib.com/~ccurley
Re: áccented characters
On Wed, Jan 05, 2000 at 04:33:36AM -0700, shawn å. wrote: Hi, I have a weird problem with accented charactures... Mutt won't display them. All I get are ?? instead of àáâãäå. I know they are there, 'cause when I do a reply, vim shows the ?'s as à's. I have 'set allow_8bit' in my .muttrc, but it doesn't seem to help. Is there anything else I should set to get them umlauts? Make sure that your $LANG environment variable is set properly. For example, I use export LANG=en_US if that still doesn't work, try configuring Mutt with --enable-locales-fix which assumes an ISO-8859-1 charset. me -- pgp key available from http://www.cs.hmc.edu/~me/elkins-pgp-key.asc PGP signature
Re: Passing arguments to the Print_Commands Variable
At 11:18 PM 01/04/00 , Mikko Hänninen wrote: John Verel [EMAIL PROTECTED] wrote on Tue, 04 Jan 2000: I'm trying to print using enscript. If I set the print_command variable to enscript, it prints fine. However, if I use any of the arguments available for enscript, such as the -f variable to change font, I always get an "unknown variable" message upon opening Mutt (version 1.0pre3i). I'm guessing you're trying this: set print_command=enscript -f font Yep When you probably should be using: set print_command="enscript -f font" Does that help? I'll give it a try right after dinner ;) and write back to let you know...in Mutt, not Eudora! Thanks again, Mikko! Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / "Do you have a backup of the data you used to have on this disk?"
mac-binhex40 encoding
Can anyone tell me how to handle a MIME attachment that was encoded
using BinHex 4.0? I received an e-mail containing several JPEG photos
that were attached as follows:
--=_947052952==_
Content-Type: application/mac-binhex40; name="putin4.jpg"
Content-Disposition: attachment; filename="putin4.jpg"
(This file must be converted with BinHex 4.0)
:#R"eG'PZ0#jUF'F!5P"4dT@9e)!%Ld!X)Mrf2rJ!""+4NP'!!%"!!!
"!!%!!2rE!%-!#!B'"`B#!F("`N*#!S-!d-#`X-'4)6$a3G'KmH(4SF(#!N,LF
J)L`M("`S0bNX-$%d0$3I*cNp1$)m,M-d-[rE!%-"#3N*$!X-'!d0'$)K(#%b-M)
...
Is there any way of configuring the mailcap file to handle such an
attachment automatically? And where does one find a BinHex 4.0 decoder
that runs on Solaris and/or Linux? Is uudeview the best bet (I found
it on freshmeat.net)?
Furthermore, does anybody have any idea why somebody would send photos
this way? The message includes the following header line:
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
The sender of the message is not a sophisticated user. Does anybody
know why Windows Eudora would send the file this way? Or perhaps he
was just forwarding it from somebody else...
I'm sorry if this has been asked already.
Thanks,
Andy
Re: Passing arguments to the Print_Commands Variable
On Wed, Jan 05, 2000 at 06:18:13AM +0200, Mikko Hänninen wrote: John Verel [EMAIL PROTECTED] wrote on Tue, 04 Jan 2000: I'm trying to print using enscript. If I set the print_command variable to enscript, it prints fine. However, if I use any of the arguments available for enscript, such as the -f variable to change font, I always get an "unknown variable" message upon opening Mutt (version 1.0pre3i). I'm guessing you're trying this: set print_command=enscript -f font When you probably should be using: set print_command="enscript -f font" Does that help? Yes, that did the trick! My printed mail is just as spiffy as Eudora ever was :)) Thanks! Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / "Do you have a backup of the data you used to have on this disk?"
Re: mac-binhex40 encoding
At 09:09 PM 1/5/00 -0500, Andrew J. Schorr wrote: Can anyone tell me how to handle a MIME attachment that was encoded using BinHex 4.0? I received an e-mail containing several JPEG photos that were attached as follows: [snip] Content-Type: application/mac-binhex40; name="putin4.jpg" Content-Disposition: attachment; filename="putin4.jpg" (This file must be converted with BinHex 4.0) :#R"eG'PZ0#jUF'F!5P"4dT@9e)!%Ld!X)Mrf2rJ!""+4NP'!!%"!!! [snip] Is there any way of configuring the mailcap file to handle such an attachment automatically? And where does one find a BinHex 4.0 decoder that runs on Solaris and/or Linux? Is uudeview the best bet (I found it on freshmeat.net)? Furthermore, does anybody have any idea why somebody would send photos this way? The message includes the following header line: X-Mailer: Windows Eudora Light Version 1.5.4 (32) The sender of the message is not a sophisticated user. Does anybody know why Windows Eudora would send the file this way? OK, at the moment I am sending this from Eudora 2.2 (32) which is vintage 1995 or so. Still works, Y2K and all. Under "options", for attachments, there are three: MIME BinHex Uuencode as well as a separate choice for whether to include the "attachment" within the message or not. Testing, the MIME choice yields octet-stream, using BASE64 encoding, probably the stuff you can easily handle. BinHex gives exactly the type of stuff that you showed, including the "mac-binhex40". Or perhaps he was just forwarding it from somebody else... Or perhaps he has an options menu and never bothered (or knew) to set it to something else. (I say "perhaps" because Eudora Light is the free version, lacking some features.) Hopefully, you can get him to set it more usefully. Can't help you with how to de-BinHex stuff on Solaris though. Cheers, Stan
ANNOUNCE: getmail v.0.95, a 'fetchmail' replacement
Slightly off-topic (flames in private mail, please), but applicable to
mutt:
getmail 0.95 is now available from
http://www.qcc.sk.ca/~charlesc/software/getmail/
getmail is intended as a simple replacement for fetchmail, for those who
don't need all of its various features, configuration options, and bugs.
It retrieves mail only from POP3 servers, and delivers reliably to Maildirs.
mbox delivery has been added as of v.0.94.
It is written in Python and released under the GPL version 2.
It can retrieve all mail, or only unread messages, from an unlimited number
of POP3 mailboxes on one or more POP3 servers. Configuration and usage is
straightforward and simple. getmail does not yet support delivery to
different users per message from a single POP3 mailbox ('domain mailbox'
or 'multidrop mailbox').
Changes since version 0.94:
-getmail now uses a simpler, more flexible .getmailrc configuration file
format.
-some cleanups in the code.
-getmail now requires at least version 1.5.2 of the Python standard libraries.
This was necessary for future features.
Any questions, feedback, etc, is greatly appreciated, but should be done
in private email.
Charles Cazabon
--
---
Charles Cazabon [EMAIL PROTECTED]
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
My opinions are just that -- my opinions.
---
Re: mac-binhex40 encoding
Andrew J. Schorr [EMAIL PROTECTED] wrote on Wed, 05 Jan 2000: Is there any way of configuring the mailcap file to handle such an attachment automatically? And where does one find a BinHex 4.0 decoder that runs on Solaris and/or Linux? Is uudeview the best bet (I found it on freshmeat.net)? I think uudeview is probably indeed your best bet. For me, it took ages to find even *one* unix program that decodes BinHex, and uudeview was it. As for setting up a mailcap entry, I think you may be able to do something like this: application/mac-binhex40; uudeview %s But that will only save the content(s) to a file when invoked, you can't make it automatically handle the content based on the extension (eg. to show an image if it's a .jpg). You might want to experiment... Furthermore, does anybody have any idea why somebody would send photos this way? It's probably the default setting for that mailer, or at least that installation of the mailer. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / I'm a shareware signature! Send $2 if you use me, $10 for a manual.
Re: mutt y2k problem?
Sitaram Iyer [EMAIL PROTECTED] wrote on Wed, 05 Jan 2000: I'm confused. Does mutt need fixing or does USA.NET or do both? Both. The Y2K problem with 2-digit years (which are legal according to the RFC, but are also pretty stupid and shouldn't be used...) has been reported already several times, and there's a patch been committed to the current development sources. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Have you rebooted your Windows today? Linux! No more reboots.
Re: mutt y2k problem?
Mikko Hänninen [EMAIL PROTECTED] wrote on Thu, 06 Jan 2000: Both. The Y2K problem with 2-digit years (which are legal according to snip Sorry, that went to the wrong place, when I was munging about the recipient headers. :-( Apologies for the extra post (and this one too). Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / We're not surrounded, we're in a target-rich environment!
