Jeremy Kitchen writes: > On Wed, 2003-10-29 at 12:50, Paul L. Allen wrote:
> Interesting? yes. Entertaining? no. That is a subjective judgement. I entertain myself. I entertain some others. If you do not find me entertaining the killfile is your friend... > Ignorant? very. We will explore that judgement... :) > > 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? Now where did I say that? Please submit a qoute of mine, found from the archives, where I said that or even *implied* it. I stated that qmail is lacking in functionality that other MTAs provide. Functionality, which in my opinion, can be provided without sacrificing security. Functionality that third parties DO provide without sacrificing security, but which come with serious performance penalties because DJB has engineered things to prevent anyone offering such functionality because he disapproves of it *in principle* and not on security grounds. > > It has good points and bad points. > > as does everything in the known universe. And if one is rational, one weighs the good versus the bad and reaches a logical conclusion. Qmail is an expensive, feature-lacking, pain in the arse according to my boss based on what our customers *think* they want and the time and wages it takes me to install it compared to the time and wages it takes a point-and-click monkey to install Exchange with all the features our customers think they want. BTW, vpopmail and qmailadmin were a pile of festering poo for a hell of a long while until Tom Collins wrested development from Inter 7 and started making them serious competitors to qmail. If you want to bitch, tread *very* carefully or I will roast your cojones like chestnuts.. > That's why you set the TTL for dns entries to be very low. (like, 5 > minutes, 2 minutes, 10 seconds, whatever) YOu just do not understand the problem, do you? And that is SCARY, because I have already explained it in sufficient detail that anyone with a vestige of cluefulness could grasp it. Let me simplify it for you: 1) Client ADSL line goes down. 2) Somebody else gets client's former IP addreess and is running a server that can be relay-raped. 3) Somebody else gets client's mail because until the real client regains internet connectivity, they cannot inform dynamic DNS that they have a new IP. 4) Once client is back on-line, dynamic DNS is updated and things are soon (5 minutes or 2 minutes or 10 seconds) fixed. And yes, there are ways of determining if the client has gone away. They put a lot of load on the server if you are going to do them every ten seconds and have a lot of dynamic DNS domains. And even then, there is still a window in which important mail can get lost. You can minimize the likelihood this way but you cannot eliminate it. > Yes, this will increase bandwidth, Good, you have some understanding of the issues involved. > 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. But they're not running the DNS server. If you had the capability to understand the issues, you might even understand why they cannot. And while they may be one of the few of *many* of our customers requiring dynamic DNS for one reason or another, they are one of the few where such low timeouts are necessary. > 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. Gosh, that's what we do too. Using a very similar model. But we sure as hell don't want all of them doing it every ten seconds. > 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. The likelihood (hey, I can spell that right, unlike you - chestnuts roasting over an open fire) is very small. But it is NOT zero. Ideally it would be zero. Alternatives to qmail/vpopmail make this probability zero, or claim that they do, or make it a hell of a lot smaller than the available qmail solutions. > 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. Customers are almost as stupid as you. They don't know about, or care about, packet sniffing. They don't know about the dangers of weak passwords. But they bitch like hell when somebody asks why they haven't replied to an e-mail they never received because it went off to som relay-rapeable server that happened to get their old IP. Which is what I am trying to avoid. > all things that are entirely unnecessary with proper dns configuration. Bwahahahaha. Should I purchase two of the latest Crays to run as our DNS servers? You are TOO funny. I'd like an MTA that offers features other MTAs offer that I can run on a cheap computer like they do... > 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. Did I say it was bad? Oh, yes, I did. But I also pointed out that for anyone who is not prepared to face a learning curve as steep as a vertical wall, Exchange *looks* like a better deal. My PHB *hates* MS stuff and knows it is unreliable crap but has to look at the costs of me doing stuff versus a monkey doing stuff. > > > 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. The extensions Inter 7 created are WAY behind the times. It is the sqwebmail stuff that stops my PHB from immediately switching to Exchange. It is Tom Collins who has improved vpopmail and qmailadmin in recent times. Don't go there, Ken, or I will totally demolish you... > > 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? I CANNOT believe you said that. But you did. So either you are an unmitigated liar or you are too damned stupid to be a developer on vpopmail and qmailadmin. Example 1: helo spammer.com the response is "bugger off." Example 2: mail from:<[EMAIL PROTECTED]> the response is "bugger off." Example 3: rcpt to:<[EMAIL PROTECTED]> the response is "bugger off." Qmail's badmailfrom picks up the first of those. With the others, you DO transfer needless magebytes of data before the message is deleted, because of DJB's decision to make it impossible to filter on from or to. If you ran a *serious* mail server, you would understand this issue. Hey, how are your nuts? I haven't even lit the fire yet... > > 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. Ken, you are being disingenuous here and I will tear you apart each and every time you do that. Trust me on this. I have battled the morons in alt.flame on the occasions they escape their padded cell. If you want a single-domain mail server then qmail is fine. If you want virtual domains then things are a little harder. If you want things that DJB thinks you must not have, then they're damned near impossible, even if sendmail, postfix, exim and exchange offer them and ALL of your customers want those features. > 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. I have already done so, as you would know if you took an ACTIVE interest in the sourceforge stuff... > Ripping on qmail for not having every single feature you want it to have > is unfair. I am more than happy with every feature qmail has. I do not want more. Our customers do. I shall tell them that they are being unfair. Then they will switch to people who provide what they think they want. Then the company I work for will go out of business. Then I will be unemployed. Works for me... > Blaming your shitty ISP on qmail is not fair, and completely ignorant. And where did I do that? I blamed my client's shitty ISP as the primary cause of the problem and DJB's shitty attitude as the secondary cause. Do NOT put words in my mouth or I will destroy you with facts and historical record. Apologize NOW or face the chestnuts... > The plain and simple fact that your IP changes is not something qmail > can control, Correct. > and the fact that your DNS points at the wrong IP after it changes is > also not something qmail can control. Also correct. But have you ever heard of ETRN? A pile of insecure poo, but one solution to the problem. > Once again, qmail is not to blame for the problem you described. If other MTAs can deal with it, even if they warn about security problems, qmail is deficient. The way to stop people doing things the wrong way is not to make everything painful but to make the right way easy. Wmail makes *everything* painful. -- Paul Allen Softflare Support
