Re: Rmail and headers in other than US-ASCII (RFC2047 encoded words)

[Paul Michael Reilly <pmr@pajato.com>]

 > I have a question about where (Rmail, or an add-on MIME-package) the
 > feature of decoding RFC2047 (MIME Part Three) "encoded words" in
 > headers belongs.  Example:
 > 
 > Subject: =?iso-8859-1?q?sm=F6rg=E5s?=
 > 
 > Currently, Rmail does not support decoding of RFC2047 "encoded words"
 > in headers.

I've been doing some work on Rmail (converting to mbox format) and I
have a goal to make Rmail handle MIME in some first class fashion.
But I don't have a concrete plan on how I'm going to do that.

I'm not familiar with RFC2047 but I will take a look at it.

My gut feel is that decoding headers should be tied to some existing
mime support flag, possibly `rmail-enable-mime', or creating a new
variable `rmail-enable-mime-headers'.  But it is not high on my
priority list right now.  Feel free to create a patch if you so
desire.

FWIW, my priorities are to overhaul `unrmail' so that it deals with
mbox format, then I'm going to focus on full imap support, doing it
such that there is a clear delineation between an Rmail front end and
multiple back ends.

 > I understand (and support) motives for keeping Rmail simple, but as
 > Rmail currently supports decoding quoted-printable-encoded message
 > bodies, maybe supporting decoding of headers in Rmail wouldn't be
 > inappropriate.
 > 
 > Would Rmail want to support this?

If you send me a patch, I'll certainly try it out and integrate it
into the mbox branch.

 > It's possible to decode the headers with
 > 
 > (add-hook 'rmail-show-message-hook
 >           (lambda ()
 >             (save-restriction
 >               (let ((inhibit-read-only t))
 >                 (rmail-narrow-to-non-pruned-header)
 >                 (require 'mail-parse)
 >                 (mail-decode-encoded-word-region (point-min) (point-max))))))
 > 
 > but it has a dependency on mail-parse found in the gnus subdirectory.
 > I'm not sure if mail-parse is to be considered independent of Gnus
 > (though it seems to be documented as such in the Emacs MIME info
 > documentation), and even then it's questionable if it's appropriate to
 > have Rmail depend on it.
 > 
 > There's always the option of implementing the functionality in Rmail
 > itself, if the dependency is undesirable.

It seems to me that the function has general use.  I'm not sure where
it belongs, but it seems pretty clear that it should not be homed in
gnus for general consumption.  Maybe Richard will have some insight
here.

 > So far my experiences with the MIME packages for Rmail floating around
 > unfortunately haven't been satisfying.  I like Rmail and would like it
 > to be even more usable out-of-the-box, while keeping it simple.

I'll second that.  :-)

-pmr