Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tlug: Another VM question



>>>>> "Kei" == Kei Furuuchi <kfur@example.com> writes:

    Kei> Some e-mails come with no Content-Type header.  VM seems to
    Kei> fail to notice nature of contents without the header.

This is by design.  :-)  According to Kyle Jones (VM author), the VM
policy is that you should scream at your correspondents to get a
properly implemented MIME-capable mailer.

    Kei> Therefore I can't read.  So how do I force to decode MIME?

You don't.  First of all, to be a MIME message, it _must_ have a
"MIME-Version" header.  And if there is no Content-Type, no MIME
decoding can take place.  These messages presumably fail both
conditions.

You can hit 'e', edit the message and put the header in yourself.  You
may as well learn how to do it, because MS mailers put the _wrong_ (or
unnecessarily mysterious Windows-only content-type, when the content
is all ASCII) Content-Type in more often than they leave out the
MIME-Version and Content-Type headers.

Or you can switch to Semi/Gnus or TM/Gnus.  TM and Semi both work
quite well, but they make quite free with your Emacs resources---once
you let one of them in, you will do things the SEMI/TM expects it to
be done, or it won't get done.  This has affected subsystems other
than mail and news in the past, although as far as I know current
versions of SEMI and TM only interfere with mail and news systems (in
particular VM and SEMI/TM do not cooperate well), and that pretty
rarely.

One advantage to the SEMI/TM approach is that they are pretty smart
about the usual forms of brokenness in Japanese messages.  I, like
Kyle, am of the school that you should inform people whose mail is
non-compliant, but you may prefer to be "politely" silent and allow
broken headers to pollute the net.  With SEMI, you won't notice the
most common forms of brokenness.

I believe that both SEMI and TM are still quite dumb about fixing
broken messages in Chinese, Korean, and non-Latin-1 ISO-8859-X
scripts[1]; as long as you don't need to deal with those, this may be a
more convenient approach than VM's rigorous adherence to compliant
behavior.

Footnotes: 
[1]  The author is Japanese.

--------------------------------------------------------------
Next Nomikai: 15 May Fri, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links