Re: What should go into 1.5.7?
On Thu, Jan 27, 2005 at 12:54:06PM -0500, John J. Foster wrote:
[...]
> My reasons for still looking for a different client have been stated
> in both this thread, and the mutt-ng fork thread. I have'nt noticed much
> in the way of comments from folks like myself (just plain users), so
> here's what I'd like that would keep me from evaluating other packages
> for awhile
>
> basic SMTP services
> support for IMAP IDLE
> inclusion of the IMAP header cache
> a decent addressbook
>
> I do not know the difficulty in implementing any of these, but they have
> remained the reasons for a few years that I keep looking.
There's another one that makes me considering switching to another mailclient:
The S/MIME support is... improvable, to put it mildly.
1) Suddenly recipients couldn't read encrypted emails I sent them anymore. It
turned out their certificates were expired but mutt used them anyway. (I
consider it a defect of their mailclient that it cannot use private keys
associated with an expired certificate. But that's besides the point: The
sender's MUA *must never* use an expired certificate to get the encryption
key, at least not without a strong warning.)
2) Now I have two certificates for each of those communication partners: An
expired and a current one. (I need the expired one to verify their
signatures on old mails.) Now mutt lets me choose which certificate to
use. But all information about the certificates in question it provides me
with is their hash value! Am I supposed to remember the hashes of all
certificates of my email partners and which hash belongs to an old and
which to a current certificate??? (Of course, I usually want to be given a
choice only if there is more than one *valid* certificate.)
3) I want my mailclient to search the directories (typically LDAP) of one or
more trustcenters if the certificate of a recipient is not found in the
local database of trusted certificates. I expect my mailclient to
doublecheck the certificates used against the trustcenters' CRLs (or check
them via OCSP where available).
Of course, you can brush aside all these complaints with the argument these
are not mutt's failures but failures of the external program(s) the certificate
handling and crypto operations are delegated to, i.e. deficiencies of openssl
and
the smime_keys script. But I don't buy that argument. Mutt claims S/MIME
support and S/MIME support implies proper certificate handling.
As a user I don't care how mutt achieves this goal. Mutt can call a
library linked in, it can open some kind of plug-in, it can fork another
process and use IPC. That's all fine with me as long as mutt get's the job
done - which it currently does not.
I don't know any applications that I can easily drop in as replacement for
openssl and smime_keys that solve these problems. If there are such
applications then they need to be mentioned in smime-notes.txt. As long as
there are no such applications mutt's S/MIME support is incomplete.
EOR (End of Rant... :-)
Regards
Christoph
--
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html