Roman Maeder | 2 Feb 22:35 2004
Picon

KDE integration?

can I make exmh my email component for KDE (3.1.4)? What configurations
are needed for this (mailto: urls in particular)?

Roman Maeder
Hal DeVore | 3 Feb 00:36 2004
Picon

Re: KDE integration?


>>>>> 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
Rick Baartman | 3 Feb 02:06 2004
Picon

Re: KDE integration?

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
Delmar R Jensen | 6 Feb 20:30 2004
Picon

Unseen not updating

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)

Joel Hatton | 10 Feb 01:10 2004
Picon
Picon

Application/pgp signed interpretation

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
Neil W Rickert | 10 Feb 01:57 2004

Re: Application/pgp signed interpretation

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
Hal DeVore | 10 Feb 03:53 2004
Picon

Re: Application/pgp signed interpretation


>>>>> 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)

Joel Hatton | 10 Feb 04:50 2004
Picon
Picon

Re: Application/pgp signed interpretation

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
Rick Baartman | 1 Mar 20:01 2004
Picon

pdf vs. octet-stream

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
Dave Tweten | 1 Mar 20:43 2004
Picon

Re: pdf vs. octet-stream

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!

Gmane