On Fri, 31 Dec 1999, Shannon Lee wrote:
> J> > Open your eyes, there are normal users out there, which don't
> J> > want or aren't allowed/able to use procmail and which
> J> > communicate with Windows
> nobody here can help those organizations or individuals who have
> chosen to limit themselves to "easy" software;
So you think, that every company and organization should install shell
accounts with access to a ~/.procmail for every user in the network on
their IMAP server? You know the security risks of procmail with a
"problematic" ~/.procmailrc?
Or do you mean, that we should remove the IMAP support from mutt,
because IMAP is evil?
> all we can do is make sure that when they step into the light
> there's a sane alternative ;)
Please stop the holy war! I don't want to discussion the pros and
cons of Unix vs. Windows or good software vs. bad software.
All I want is to think about the PGP reception of Mutt. Fact is, that
there is mail software (including many Unix mail readers), that
doesn't support RFC 2015 or the application/pgp thing (don't know,
whether there is a RFC or whether it is a de facto standard created by
elm). I want to be able to read these messages using Mutt. I think,
that there should be much discussion until here.
Now the question is, how we want to make these messages readable by
Mutt. At the moment Mutt doesn't have support for those messages.
The work around for this (it's not a solution, but only a work
around!) is to use procmail with the rules given in PGP-Notes.txt.
This works most of the time but has many disadvantages:
- Every Mutt user needs procmail to be installed on the mail server
- Every Mutt user needs a shell account on the mail server to create a
~/.procmailrc
- Every Mutt user has to understand how procmail works
- procmail has to manipulate the mail. I personally think, that a MTA
or MDA should not change any mail except from adding a Received
header.
- The procmail rules from PGP-Notes.txt strip (or rename) the original
Content-Type header, which may include information (for example the
charset). Don't tell me, that this is a feature, it's a bug.
- The procmail rules from PGP-Notes.txt only work for text/plain
messages, if there is some PGP-signature or PGP encryption in a
multipart mail. I didn't see a working procmail rule for those
message. Instead of this I have to edit the mail by hand to change
the Content-Type of the MIME part which includes PGP. This is not
the behavior which I like in a mail reader.
Maybe you will accept at least some of these disadvantages. And don't
forget the old rule: "Be liberal in what you accept and restrictive in
what you create."
That's why I still propose to add a mutt function (bound on a special
key), that scans the actual message for PGP and temporarily change the
PGP flags for this message accordingly until the user changes the
folder. Please note, that I don't want every mail to be scanned for
PGP every time. I also don't want the non-MIME PGP mails to be
automatically detected. If you or Jeremy don't like this feature,
simply unbind the key and you will never notice, that this feature is
available.
> J> > users, which send out PGP without MIME headers but instead of
> J> > this with vcards (multipart/mixed). If you want Mutt to become
> J> > widely used,
> i don't believe that microsoft (or anybody) should be allowed to set
> *yet another* de-facto standard
I don't talk about MS software. I'm talking about software like pine,
which simply create PGP messages as in the good old days, when nobody
used MIME and a message body (or parts of it) could simply be piped
through pgp -feast or similar. This is no new de-facto standard but
only the old way to use PGP.
And don't forget that the "Content-Type: application/pgp" (created by
elm and the procmail rules from PGP-Notes.txt) is not much better than
the old style PGP without MIME header. It implies the same problems
with characters other than 7bit ASCII etc. So why does Mutt support
application/pgp and not the same without MIME headers? You cannot
argue with de-facto standards etc. here. The only good solution is
RFC 2015, but we cannot change the world to only use RFC 2015 from now
on. And backward compatibility (only for reading, not for creation!)
means, that we need some technique in Mutt to decrypt PGP without
correct MIME headers. This is not the job of some filter but it's the
job of the mail reader to do this.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
