On Dec 17, 2007 4:03 AM, Ted Mittelstaedt <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Matt LaPlante [mailto:[EMAIL PROTECTED] > > 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 specifications? > > 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 > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"