Suggestions please for what POP or IMAP servers to use
cyberdog3k at gmail.com
Mon Dec 17 08:17:05 PST 2007
On Dec 17, 2007 4:03 AM, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
> > -----Original Message-----
> > From: Matt LaPlante [mailto:cyberdog3k at gmail.com]
> > 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
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.
More information about the freebsd-questions