On Dec 14, 2007 11:45 PM, Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 documented. 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. > > > Ted > 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 > > _______________________________________________ > firstname.lastname@example.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"