On Wed, 2003-10-29 at 12:50, Paul L. Allen wrote: > Justin Hopper writes: > > > Wow. Of all the rants I've read on mailing lists, this is probably one > > of the most interesting. > > Thanks. I try to be entertaining even when ranting.
Interesting? yes. Entertaining? no. Ignorant? very. > > My colleagues and I went from dreams of lush green MTA lands to hating > > DJB as well when we first started working with qmail instead of Sendmail. > > I think everyone does, once they find out what qmail CANNOT be made to > do for no other reason than DJB disapproves of people being able to do > it, even if every other MTA does it. So if every other MTA has security holes and reliability problems, qmail should as well? Have any of your friends jumped off bridges lately? > > However, over the years, we have come to appreciate qmail's extremely > > modular and simplistic nature. > > It has good points and bad points. as does everything in the known universe. > > The modularity is the most important aspect, since this allows it to > > grow from the minimalist MTA to a fully featured one. > > But only if you do not want to stray from the DJB path. I've just spent > time digging around for an answer to a problem that just cropped up. > One of our clients is on ADSL with dynamic IP. In the UK, ADSL lines > go down about once a week and you almost invariably get a different > IP (unless you pay THREE times as much for static). This client has > decided they want their own Exchange server. And this is where the > problems come in, because on average once a week they're going to > get a new IP and there will be a period, before their line comes back > up, when somebody else might get their old IP and they can't do anything > to update the dynamic DNS. If the person who gets their old IP is > running a mail server that acts as an open reley (which earlier versions > of Exchange defaulted to doing) then that person is going to get their > mail. That's why you set the TTL for dns entries to be very low. (like, 5 minutes, 2 minutes, 10 seconds, whatever) Yes, this will increase bandwidth, but if you're running a mail server on an adsl connection and complain about the cost of a static IP address, you obviously aren't getting enough traffic to need to worry about the added bandwidth. places like dyndns.org have clients that run on *nix systems that allow the customer to update their DNS records automatically, with no user intervention. The likelyhood of someone getting your IP address and stealing some mail during the 5 minutes of the TTL while the old record is still alive is very slim. Worried about someone stealing your uber important mail with top secret information? You shouldn't be on an adsl connection then, so that is moot point. > So how to fix this problem? ETRN? Nope, qmail doesn't support it > without patching, and it's not particularly safe anyway. Serialsmtp > and autoturn? Apparently not, from what I've read since it expects > static IP. Mailrdirsmtp and some custom "I'm alive" software at each > end? Maybe, but I don't yet understand how to make maildirsmtp > co-exist with vpopmail. Fetchmail running on the firewall we supplied > them? Ideal except that Fetchmail reacts badly to some mailing lists > and automated systems, I am told. all things that are entirely unnecessary with proper dns configuration. > > If it wasn't for this modularity, qmail might have died > > off by now. > > And if it weren't for DJB's stubbornness, its usage might actually > be growing instead of steadily declining. You look at any recommendations > for *nix MTAs these days and qmail is not in the top three. A couple of > years ago it was number one. Show us some stats to prove your claim. qmail is a little harder to install, yes, but once you figure out how to use it, it's great. > > Good thing we have people like Inter7 that create extensions to qmail > > that make it much more feature-rich, and also provide much better > > documentation. We aren't the only ones who 'create extensions' for qmail. > > Ultimately, it would be nice to continue to see MTA packages that > > provide upper-level functions while keeping the gears of > > qmail hidden away. > > Some things cannot be done that way. And deleting spam by mailfilters > means you may accept a gigantic spam mail only to discard it automatically, > which wastes bandwidth. well, you'd have to accept it to filter it, wouldn't you? Where's the bandwidth loss? > > If these packages continue to improve functionality and easy of use, > > hopefully one day in the near future the beast Exchange can be put to > > sleep. > > I hope it will happen, but I am far from confident. I think it more > likely that Postfix or Exim will take over. A point-and-click monkey > can install Red Hat 8 with Postfix as part of the distro and configure > it as easily as Windows and Exchange. Installing qmail and all the > add-on packages required takes longer and requires a very steep learning > curve. qmail doesn't require any 'addon packages' I ran my qmail server for a very long time with just a straight LWQ style install and it worked exactly how I wanted it. I like that about qmail. Very simple, and very extensible. > > Back to the matter at hand though, is there any feedback from the Inter7 > > devs on the features that I mentioned for QmailAdmin? You may want to consider posting your suggestions/feature requests to the sourceforge project. We're not the only ones working on qmailadmin/vpopmail anymore. > The main development lead for qmailadmin is now Tom Collins, with Inter7 > playing a secondary role. Tom is on holiday right now. oops, you already said that :) Ripping on qmail for not having every single feature you want it to have is unfair. qmail works quite well all by itself, and a lot of features that people want have already been created as patches for qmail. Want bloat? Want to have to update because of security problems all the time? Then use something else. Blaming your shitty ISP on qmail is not fair, and completely ignorant. The plain and simple fact that your IP changes is not something qmail can control, and the fact that your DNS points at the wrong IP after it changes is also not something qmail can control. That's not something ANY mta can control, and... would you really want it to? If you have mission critical emails, and emails that need to be kept super secret, then either get a static IP address, host your mail server somewhere so it is on a static IP address, or use one of the methods I defined above for keeping your DNS information up to date. Once again, qmail is not to blame for the problem you described. -Jeremy -- Jeremy Kitchen Systems Administrator [EMAIL PROTECTED] ..................... Inter7 Internet Technologies, Inc. www.inter7.com 866.528.3530 toll free 847.492.0470 int'l 847.492.0632 fax GNUPG key ID: 93BDD6CE
