Gnus and metamail.el

[Roland Winkler]

This bug report will be sent to the Free Software Foundation,
 not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

In GNU Emacs 20.4.1 (i686-pc-linux-gnu, X toolkit)
 of Fri Oct 29 1999 on tfkp02
configured using `configure  --prefix=/nfs/common --libexecdir=/nfs/common/lib 
--bindir=/nfs/common/lib/emacs/bin/i686-Linux --with-gcc --with-pop --with-x 
--with-x-toolkit=athena'


When reading news with Gnus it happens occassionally that I get a
message (let's say at the very bottom of a long article)

This message contains raw digital data,
which is being decoded and written to the file named "/tmp/mm.2cdvg8".
If you do not want this data, you probably should delete that file.
Wrote file /tmp/mm.2cdvg8

I think this message is from metamail (invoked by Gnus via
metamail.el). The point is: I feel rather uncomfortable by this
default (!) behavior of Gnus/metamail, that it is writing files in
my /tmp directory when I do not know anything about the content of
these files. (It happens quite easily that I overlook completely the
message that I `received' a file on /tmp.)

I'd like to suggest that at least it should be possible to configure
METAMAIL_TMPDIR. (Why does it say in the docstring of
metamail-environment, that this variable is not expected to be
altered globally by `set' or `setq'?? Of course, one can set this
environment variable also in .bashrc.) 

However, I'd prefer a default behavior where metamail does not write
silently any files anywhere (at least for situations like reading
news where it can easily happen that I receive something I do not
want to have anywhere in my file system). According to the manpage
of metamail this seems to be possible:

       For unrecognized types, metamail simply removes all header
       and encoding information from the data, and writes it  out
       to  a  temporary file.  (If running interactively, it will
       give you more alternatives -- writing it  to  a  temporary
       file,  viewing  it as text, or jus skipping it.)  It is up
       to the user to delete such files when he or she is through
       with them.

Roland