Suggestions please for what POP or IMAP servers to use
cyberdog3k at gmail.com
Sat Dec 15 14:17:34 PST 2007
On Dec 14, 2007 11:45 PM, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
> > -----Original Message-----
> > From: owner-freebsd-questions at freebsd.org
> > [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Andrew Falanga
> > Sent: Friday, December 14, 2007 7:35 PM
> > To: Ted Mittelstaedt
> > Cc: Rob; FreeBSD Questions
> > Subject: Re: Suggestions please for what POP or IMAP servers to use
> > On Dec 13, 2007 10:06 PM, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
> > > > The developer is very adamant about writing dovecot strictly to
> > > > the letter of the IMAP specification. He's also discovered many
> > > > of the popular clients have bugs, and are unable to work (or at
> > > > least have issues) with an IMAP server that goes purely by the rules.
> > > >
> > > > He refused to "break" his software to work around bugs on the
> > > > client side, but ultimately compromised by writing in
> > > > work-arounds that you can enable in the config file. You can
> > > > enable them all if you like.
> > > >
> > >
> > > Which is a really dumb attitude since the dovecot developer was
> > > not the author of the IMAP standard and probably was in diapers
> > > when the standard was first written:
> > I agree with your sentiment that, "who can use a server that no client can
> > connect to?" However, that being said, why write a standard you don't
> > intend to adhere too? It's a crying shame that folks write standards for
> > things like IMAP and e-mail client providers don't follow them. I wished
> > more people were like this fellow who writes Dovecot! If more people were
> > strict about server interfaces, then perhaps more vendors would
> > write their
> > code to the standard instead of those who write the standards
> > enabling poor
> > compliance by "dumbing" down their servers.
> It's a chicken and egg problem.
> There's nothing wrong with writing an extremely strict standard.
> The issue is the implementation.
> If your server implementation is so strict that most clients have
> difficulty, then users will find something else and your standard
> will end up on the dustbin.
> It's better to start out with a strict standard and a forgiving
> server implementation, then as it falls into mainstream use, work
> with the client developers to correct their stuff.
You've effectively described dovecot here. Its codebase is perhaps
designed to be very strict, however the same codebase also includes
configurable 'workarounds' (enabled by default in many distros) for
clients that are not up to spec. They're trivial to toggle and well
So, this meets both criteria that it will "just work" with clients
now, and the clients themselves could theoretically (good luck with
Outlook) fix their code in the future. As far as I'm concerned, it's
a fairly ideal environment, and I'm glad the developer has gone to the
trouble to 1) stick to standards in the core code and 2) made a point
of documenting and providing workarounds for buggy clients.
I personally use dovecot (+postfix) with great success. Dovecot is
modern, featureful, well documented, and its SASL impementation is
particularly useful with postfix. I've had no difficulty with clients
not being able to connect.
> We don't want to end up like Microsoft - which writes very lax
> and contradictory standards, then makes up strict implementations.
> Then every new release of their stuff breaks things.
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.2/1184 - Release Date: 12/14/2007
> 11:29 AM
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions