[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] Plaintext passwords IMAP please!
I thought I was going mad!
I agree that a core function like this shouldn't be changed in such an
IMHO this is supposed to be why we use SuSE rather than suffering the random
decisions of package maintainers and even of IETF bodies?
I am totally unfamiliar with SSL, I've resisted it just out of laziness - I
have enough to do with being a Windows dev. and part-time linux sysadmin
All clients will be Outlook Express but I'm guessing that SSL is more of a
shared library thing on Windows, i.e. registry settings, etc. to allow
clients to access a server with SSL where certificate is self-certified.
So anyway it's worth a go; can you give me a quick idea of how I set up SSL
on my linux box, create a certificate and then get imapd to use it?
Alternatively a well-written, simple HOWTO would be fine!
----- Original Message -----
From: "Maarten v d Berg" <maarten@xxxxxxx>
Cc: "Carl Peto" <carl@xxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, January 15, 2004 3:55 PM
Subject: Re: [suse-security] Plaintext passwords IMAP please!
> On Wednesday 14 January 2004 16:15, Carl Peto wrote:
> > I've been struggling with this for hours on end!
> > All I want to do is run an IMAP server to allow my Windows clients to
> > access their unix email with Outlook Express. I tried the imap package
> > that has been modified now so that no POP3 or IMAP login is allowed with
> > plaintext password unless using SSL encrypted sessions.
> I have had the exact same problem. I DO use SSL, but the change in the
> server package breaks squirrelmail. I also am not amused by SuSE's
> to change the behaviour and by not having a way to turn this off again.
> However, I made a workaround by force-installing the imap version of SuSE
> over the changed one which is running on SuSE 8.2. So now everytime I
> to UNselect imapd in online update my system breaks again. Very nice.
> I too would want a better solution. And I fully concur with you on the
> of Cyrus-imapd. Cyrus seemingly serves one single purpose, to drive
> utterly crazy. ;-| I gave up early when I saw the list of
> > I do not want to get into the complexity of installing SSL, all boxes
> > behind a completely secure firewall and use CVS pserver, etc. anyway so
> > "security" gained by encrypting either session or passwords is
> > illusory.
> > The imapd daemon wouldn't accept encrypted passwords even when I
> > the option on in my test Outlook Express mail client so I can't win
> > way.
> Installing an SSL certificate so that imapd speaks SSL too is quite
> you need help I can look it up for you... it is not more than 5 minutes
> however teaching all the clients that they should trust a self-signed cert
> sure isn't, so this may not be a viable option for you anyway.
> > I tried to recompile imapd from source since the change to not allow
> > plaintext passwords except in a TLS session is actually compiled into
> > server (very bad form, should be a config file option, probably with
> > setting as default). The source package is broken and won't compile.
> > I tried installing the fiendishly complex cyrus-imapd but that doesn't
> > either, complaining about a "cannot connect to saslauthd server". Tried
> > changing the sasl_pwcheck_method to "pwcheck" to see if that helped.
> > Daemon won't start now complaining of db errors.
> > I've set up qpopper to act as a pop3 client so I can now at least pick
> > my mail inbox from /var/spool/mail/<username> but that means I can't
> > other folders so (i) if users read mail on UNIX clients the mail goes
> > mbox and is inaccessible from Windows henceforth and more importantly
> > users cannot use .procmailrc to sort mail into files like "spam",
> > "suse-security-mailing-list", "cvs-logs" as these are now only
> > via unix and not Windows where people do most of their daily work.
> > Really it's such a simple thing I want to do!
> > Can anyone help?
> I am certainly willing to contribute but for now I'm stuck with the same
> problem as you are...
> > Thanks,
> > Carl
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here