Date: Mon, 17 Dec 2007 01:03:38 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Matt LaPlante" <cyberdog3k@gmail.com> Cc: Rob <bitabyss@gmail.com>, FreeBSD Questions <freebsd-questions@freebsd.org>, Andrew Falanga <af300wsm@gmail.com> Subject: RE: Suggestions please for what POP or IMAP servers to use Message-ID: <BMEDLGAENEKCJFGODFOCMEDJCFAA.tedm@toybox.placo.com> In-Reply-To: <cbb8f04c0712151417o4c9fb148q60a818427d959416@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Matt LaPlante [mailto:cyberdog3k@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 immediately. 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. > 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. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCMEDJCFAA.tedm>