Moin,
what about '| pgp | less' (or '| gpg | less').
Matthias
On Fri, Dec 31, 1999 at 07:53:05PM +0100, Roland Rosenfeld wrote:
> 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/ *
>
--
Matthias Teege -- [EMAIL PROTECTED] -- http://emugs.de
make world not war
PGP-Key auf Anfrage
