2 Feb 2004 22:35
3 Feb 2004 00:36
Re: KDE integration?
Hal DeVore <haldevore <at> acm.org>
2004-02-02 23:36:15 GMT
2004-02-02 23:36:15 GMT
>>>>> On Mon, 2 Feb 2004, "Roman" == Roman Maeder wrote: Roman> can I make exmh my email component for KDE (3.1.4)? Roman> What configurations are needed for this (mailto: urls in Roman> particular)? I don't think anyone has done that. There is a very old "package" named ns-exmh that can be found in the "misc" directory of a full exmh package. The ns-exmh package allowed one to use exmh for mailto: and news: targets in Netscape. A motivated person could probably adapt it to support Konqueror or whatever browser you're using. --Hal
3 Feb 2004 02:06
Re: KDE integration?
Rick Baartman <baartman <at> lin12.triumf.ca>
2004-02-03 01:06:58 GMT
2004-02-03 01:06:58 GMT
I don't know about KDE, but in Opera, I use ExmhComp as my e-mail client. It's
a script I got from Larry Gaffner on this list. Look in archives 23 May 2001.
Here it is:
#!/usr/bin/wish
wm withdraw .
set exmh_path /usr/local/bin
set exmh_bin exmh
# if exmh isn't running , start it up and wait till it's there before continuing
if {[lsearch [winfo interps] $exmh_bin ]==-1} {
exec $exmh_path/$exmh_bin -iconic 2>1 > /dev/null &
while {[lsearch [winfo interps] $exmh_bin ]==-1} {
after 200
}
}
if { 0 == [string length $argv] } {
send exmh Msg_Compose
exit 0
} else {
send exmh Msg_CompTo $argv
exit 0
}
--
--
rick
6 Feb 2004 20:30
Unseen not updating
Delmar R Jensen <jensend1 <at> yahoo.com>
2004-02-06 19:30:16 GMT
2004-02-06 19:30:16 GMT
I have a problem that when I "Inc" mail my Folder Cache and Folder List are not updated to reflect there are new messages in them, ie. their color isn't changing to blue. I'm using pretty much the basic default color scheme. I have several different folders that I post to. I use presort with slocal. I do not have the Inc being done in the background. The folders seem to be okay when I first start exmh but it degrades after that. If I do a manual Flist, they appear but the background flist that I have running does not cause them to update. Are there any issues with SPAM type message or poor rendered messages that could be causing this? Or maybe it's just me. I am using: exmh 2.6.3 FreeBSD 4.8 tcl & tk 8.3.5 (I've tried 8.4.1,1 with same results.) I've search wiki and the archive but wasn't able to find anything about this. Any help would be greatly appreciated. I've used various prior versions of exmh without having this problem. This started when I upgraded to 2.6.3, I was using 2.5 prior. I really like the count of unseen messages in the Folder Cache. Thanks,(Continue reading)
10 Feb 2004 01:10
Application/pgp signed interpretation
Joel Hatton <exmh-users <at> auscert.org.au>
2004-02-10 00:10:12 GMT
2004-02-10 00:10:12 GMT
Hi, I've just noticed that my exmh 2.6.3 can't interpret application/pgp messages. If I remove just this line: Content-type: text/plain; charset=us-ascii; x-action=pgp-encrypted all is ok, but otherwise I get the standard "It might be displayable with metamail" message. Has anyone patched this before, or has a simple workaround? I realise that the MIME-parsing stuff is fairly complex (and I don't expect any major rework for something this trivial and, dare I say, obsolete?), so if this is too hard I'm inclined to just hack out that line each time :) thanks, -- Joel Hatton -- Australian Computer Emergency Response Team | Hotline: +61 7 3365 4417 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert <at> auscert.org.au
10 Feb 2004 01:57
Re: Application/pgp signed interpretation
Neil W Rickert <rickert+exmh <at> cs.niu.edu>
2004-02-10 00:57:28 GMT
2004-02-10 00:57:28 GMT
Joel Hatton <exmh-users <at> auscert.org.au> wrote on Feb 10, 2004: >I've just noticed that my exmh 2.6.3 can't interpret application/pgp >messages. If I remove just this line: I just sent myself an application/pgp message. It worked fine both for sending and reading. >Content-type: text/plain; charset=us-ascii; x-action=pgp-encrypted That's probably outside any standard for pgp messages. Let's hope it does not become commonplace. -NWR
10 Feb 2004 03:53
Re: Application/pgp signed interpretation
Hal DeVore <haldevore <at> acm.org>
2004-02-10 02:53:20 GMT
2004-02-10 02:53:20 GMT
>>>>> On Tue, 10 Feb 2004, "Joel" == Joel Hatton wrote: Joel> I realise that the MIME-parsing stuff is fairly complex Joel> (and I don't expect any major rework for something this Joel> trivial and, dare I say, obsolete?), so if this is too Joel> hard I'm inclined to just hack out that line each time :) Yeah. Either very old or very non-standard. What is generating it? Some googling leads me to believe it might be MUTT: http://www.woolridge.org/mutt/pgp-traditional.html [hint when googling for this: searching for "x-action" alone will not get you pages related to email tools! :) ] A little clever work with procmail and awk would probably be all it would take to change the content-type header to something more standard. If the first non-blank line in the message part is a normal PGP header (----BEGIN PGP...) then all you probably need to hack out is the x-action attribute. From there on the "coercion" code should kick in, detecting the PGP header in the text/plain message and Doing The Right Thing. Or you could change the text/plain to application/pgp when the x-action=pgp* is present. Current best practice (iirc) is RFC 2015 multipart/encrypted --Hal(Continue reading)
10 Feb 2004 04:50
Re: Application/pgp signed interpretation
Joel Hatton <exmh-users <at> auscert.org.au>
2004-02-10 03:50:51 GMT
2004-02-10 03:50:51 GMT
Thanks guys, You're dead right about it being MUTT, Hal, I just rechecked the header again. When I have more than ten minutes (which is how long I just spent trying...) I'll override pgpMain.tcl in the right place and include this dodgy type in the x-action parsing code. And yep, I can send/receive exmh application/pgp messages ok as Neil mentioned, both signed and signed/encrypted. cheers, -- Joel Hatton -- Australian Computer Emergency Response Team | Hotline: +61 7 3365 4417 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert <at> auscert.org.au
1 Mar 2004 20:01
pdf vs. octet-stream
Rick Baartman <baartman <at> lin12.triumf.ca>
2004-03-01 19:01:13 GMT
2004-03-01 19:01:13 GMT
I often get pdf files as attachments, but with Content-Type labelled as application/octet-stream instead of application/pdf. I can still tell it's a pdf by the "filename". The irritating thing is that exmh will then present it with a "decode and save" button instead of a "open application/pdf" button so every time I want to see the message I have to save it and then acroread it. Is there a quick way around this? Currently I edit the mail message to change "octet-stream" to "pdf". -- -- rick
1 Mar 2004 20:43
Re: pdf vs. octet-stream
Dave Tweten <tweten <at> nas.nasa.gov>
2004-03-01 19:43:00 GMT
2004-03-01 19:43:00 GMT
baartman <at> lin12.triumf.ca said: >The irritating thing is that exmh will then present it with a "decode and >save" button instead of a "open application/pdf" button so every time I >want to see the message I have to save it and then acroread it. Is there >a quick way around this? My technique uses a shell script that assumes application/octet-stream means Microsoft/broken and chooses how to display the file based upon the Microsoft file-name suffix. To access the script, I right-click on the attachment and select "Pass ... to Metamail." The "application/octet-stream" entry in ~/.mailcap points at the script. -- -- M/S 258-5 |1024-bit PGP fingerprint:|tweten <at> nas.nasa.gov NASA Ames Research Center | 41 B0 89 0A 8F 94 6C 59| (650) 604-4416 Moffett Field, CA 94035-1000| 7C 80 10 20 25 C7 2F E6|FAX: (650) 604-4377 Not an official NASA position. You can't even be certain who sent this!
RSS Feed