Suggestions please for what POP or IMAP servers to use

Matt LaPlante cyberdog3k at
Mon Dec 17 08:17:05 PST 2007

On Dec 17, 2007 4:03 AM, Ted Mittelstaedt <tedm at> wrote:
> > -----Original Message-----
> > From: Matt LaPlante [mailto:cyberdog3k at]
> > Sent: Saturday, December 15, 2007 2:18 PM
> > To: Ted Mittelstaedt
> > Cc: Andrew Falanga; Rob; FreeBSD Questions
> > Subject: Re: Suggestions please for what POP or IMAP servers to use
> >
> > >
> > > 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.
> No, I haven't.
> > 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.
> >
> If you download and compile dovecot then is the default config template
> that is shipped with it enable the workarounds?  No.  The excuse that
> "enabled by default in many distros" is merely an excuse.  Nobody who
> is serious about building a server for a lot of clients is going to
> be using some precompiled version, they are going to compile from
> source so that if a security hole is discovered they can patch it
> immediately.

They're also going to actually *look* at the configuration and tailor
it.  What kind of fool goes to the trouble of building his own
software without also customizing the configuration to his

> IF the switches DISABLED the "lax" behavior, and the defaults in the config
> templates were to not have the switches triggered, then it would meet the
> definition of a forgiving server implementation.  But it doesen't even
> go that far.
> > 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.
> Outlook works just fine in IMAP mode with uw-imap, both regular Outlook
> and Outlook Express.

I never said it doesn't.  Dovecot works fine with Outlook and Outlook
Express too (both IMAP and POP3).  Imagine that, IMAP servers that
successfully service IMAP clients.

> > As far as I'm concerned, it's
> > a fairly ideal environment,
> It is good you spell out that this is your personal ideal.
> > 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.
> >
> It is a lot of extra work to encapsulate all the "alleged bugs"
> in separate code so you can provide "switches" for stick-up-their
> -asses-admins to flip.  That is work that should have gone into
> speeding up the code.  It is utterly wasted effort unless your goal
> is to allow admins who have penis envy the ability to jerk people around
> for their choice of e-mail clients.
> It isn't the mailserver administrator's business if Joe Idiot User
> who doesen't know any better chooses to use Outlook 97 as an IMAP
> client, to deny Joe Idiot access to the mailserver.  The admin does
> not need to be playing silly games like this, setting up his server
> so that only some clients can work with it, others can't, then telling
> people their software of choice has bugs and fuck you, don't use it.
> Programmers jobs are to makes things work for users.  If Mickeysoft's
> programmers cannot write a decent IMAP client, then if the developer
> of an IMAP server can write around the problem, then he should do it
> and embed the fix in the server code without calling it out in a
> config switch.
> The situation is absolutely no different with hardware drivers.  Take
> a look at for example the comments in the ne2000  (ed) driver code, or
> the DEC/Intel 21143 network card driver code (or man page)  There are
> a number of very badly borked up hardware implementations of those
> network chipsets.  Yet, do the driver authors of the ed or dc
> driver make the admins flip switches in the driver to make the driver
> work with their particular borked-up chipset implementation?  No.
> They write the driver code to work with all implementations, even
> the borked up ones.
> The dovecot author is engaged in technopolitics.  It is a very bad
> thing to do.  Whether the authors of bad IMAP client software deserve
> this is beside the issue.  You need to understand that the ONLY lever
> that the Open Source community has to keep the giants like Microsoft
> paying some kind of attention to published standards so that everyone's
> stuff can interoperate, is the moral superiority lever.  In other words,
> the Open Source community simply does not engage in predatory,
> circle-the-wagons, use-my-stuff-or-else behavior.  We have worked a
> LONG time to get to this point.  As a result of this, when there IS
> a problem between the commercial stuff - like for example Microsoft's
> Networking, and the Open Source stuff - like for example, SAMBA,
> everyone always assumes that the problem is due to the commercial
> software companies breaking things - either deliberately, in which
> case they look like assholes or sharks, or by accident, in which case
> they look like incompetents.
> Microsoft tested stuff like IE7 against Apache during IE7 development,
> and they made damn sure that before IE7 was released, it worked with
> Apache.  They knew that if it didn't, that everyone would blame them
> because nobody can conceive of the Apache project deliberately writing
> code into Apache that would break a web browser.  Why - because the
> Apache developers are altruistic and don't play those games.  Do you
> start to see how this works, now?
> Apache certainly could do it the other way - the Dovecot author's way -
> and set defaults that would break all IE versions, which Apache admins
> would have to seek out and turn off.  If that happened then Microsoft
> would quit bothering to test with Apache and just do whatever the hell
> they felt like, and blame Apache for getting it wrong.  Since people
> would know the Apache project was using the same tactics as Microsoft,
> nobody would really trust that either party's interpretation of the
> http standard was correct, and it would put most users and admins
> into the position of being forced to choose between them and use all
> open source stuff or all Microsoft stuff.  As the Open Source people
> do not have the money that the commercial people do, ultimately they
> would lose.
> I'm sure a LOT of people out there both inside the commercial software
> companies, and people like the Dovecot author, inside the Open Source
> community, would enjoy seeing the software market polarized like this.
> The newest version of the GNU license has this viewpoint, for example,
> and I daresay it's driven by Linux popularity.  You see, Linux distros
> have gotten popular enough that some of that community feel they don't
> need to consider what the commercial software people are doing anymore.
> To hell with them, let them eat software bugs, is the attitude.
> FORTUNATELY, so far the BSD people have kept their cooler heads and
> haven't adopted this attitude.  They have adopted the attitude that
> I discussed at length in Chapter 10 of my FreeBSD book in the section
> on the Microsoft Anti-trust trial.  In short, FreeBSD is better than
> Windows because it's technically superior, and it's going to win
> in the market because it's technically superior.  By contrast, Microsoft
> has the image that they are a big greedy company that is more interested
> in making a lot of money than winning based on technical superiority.
> Ergo, their stuff is not very good.
> Immediately after the MS Anti-Trust trial, of course, everyone
> thought that the FreeBSD way was naieve, believing that since MS
> was acquitted that the MS way was inevitable, as underhanded as
> it was.
> But then an interesting thing happened.  MS figured out about 6-12 months
> after winning the trial, that they had effectively won the battle but
> lost the war.  Looking back it's easy now to see that the huge increase
> in Linux penetration of the market dated from the time of the ending
> of the trial.  What was going on is that while Microsoft was still
> growing in sales, they were not growing as fast as the market, and were
> losing market share.  That is why MS eased Bill Gates out of the
> spotlight, it is why they refocused and actually came out with a
> server product - server 2003 - that really was superior to server 2000,
> instead of the way it was before where server 2000 really wasn't much
> better than NT4.  It is why MS has not filed any kind of legal
> proceedings against Linux even while claiming Linux infringes their
> intellectual property - they know that such claims will continue to
> be regarded as typical salesman bullshit as long as their lawyers don't
> actually do anything to back them up.
> In summary, MS realized that if you play in the market using dirty
> tricks then eventually you destroy your credibility - and once that
> happens, the only people who will buy anything from you are the
> people who are being forced to - and they will hate doing it, and
> will constantly be looking for a way to cut you out of the picture,
> and eventually they will find it and you will be cut out of the
> markets one little snip at a time.
> It is a lesson that most in the FreeBSD community have learned.  It
> is one that the author of Dovecot obviously has not learned and that
> is a shame.

You use a lot of words to say very little.  So much ranting about
intent and philosophy, and very little argument of technical merit.  I
don't care if the author plans to take over the world; his software
works well.  If you want to impress me with your opinions, give
specific technical examples (statistics, bugs) demonstrating why one
application is functionally superior to another.

> Ted

More information about the freebsd-questions mailing list