little long winded, but if you read to the end, there's a nice surprise! A solution to your problem!
On Wed, 2003-10-29 at 19:51, Paul L. Allen wrote: > > > 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. you cut qmail down because it doesn't have every feature that you want right inside. Other MTAs do that, and by adding every feature known to man they get bloated, and security problems arise. > I stated that > qmail is lacking in functionality that other MTAs provide. oh look, you said it again. > 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. he wrote qmail to be reliable and secure. Which one of those hasn't been accomplished? > > > 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. do you want reliable, secure, 'expensive' service? Or would you rather have unreliable, insecure, FEATURE PACKED 'expensive' service? I pick the former. > 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 that's a matter of opinion, and you're welcome to it. > and > started making them serious competitors to qmail. I didn't think vpopmail and qmailadmin were competing with qmail. vpopmail and qmailadmin supplement qmail. > If you want to bitch, > tread *very* carefully or I will roast your cojones like chestnuts.. I see our maturity level is high. > > 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: I admit, I was incorrect about part of my assumption. I missed the part where you said the link was down for an extended period of time. I simply assumed you meant it was switching IPs. I apologize. Still, exchange can't fix that part of your issue, nor can ANY other MTA. Period. > 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. that's an ISP issue, not a qmail issue, not an MTA issue, not an issue any MTA can solve. > 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. if the mail is so important, why host it on such an unreliable link? Honestly folks, there ARE relatively cheap colocation and dedicated server hosting services. > > Yes, this will increase bandwidth, > > Good, you have some understanding of the issues involved. That statement was made under wrong assumptions. You would still want a low TTL on the dns records, but since you have external dns hosting, the bandwidth of your DSL line wouldn't be affected by those TTLs, only the bandwidth at your dns hosting provider. > > 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. once again, I apologize for missing the extended period of downtime part. > > 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) Once again we see your incredibly high level of maturity. > 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. and how would said alternatives go about this? I really truly would like to know. The problem you described can NOT be solved by ANY MTA. How can an MTA on a downed host tell another MTA not to send mail to that other guy since it's not you? > > 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. mature. > 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. Unless you're running an ancient version of BIND and get 500 million hits a day, a pentium 133 with a 10mbit NIC would handle the load without flinching. > I'd like an MTA that offers features > other MTAs offer that I can run on a cheap computer like they do... so use one. qmail can run on very cheap systems, and is incredibly extensible. If qmail wasn't extensible, we wouldn't be having this conversation right now, as qmailadmin and vpopmail wouldn't exist. > > 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. qmail doesn't have a steep learning curve. UNIX does. Once you figure out how UNIX works, qmail is very natural. www.lifewithqmail.org is pretty much 'qmail for dummies', if you copy/paste everything, you really can't go wrong. And if you pay attention to what you're copy/pasting, you might actually learn a little bit. > > > > 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. Inter7 is not at issue here. You were talking about how much qmail sucked because your internet connection is terrible. I was simply commenting that we aren't the only ones who write software for qmail. Now that I look at it, I really didn't need to say that, because he said 'people like Inter7' and not just 'Inter7'. I apologize. > Don't go there, Ken, or I will totally demolish you... You already did. Leave the personal attacks where they belong: /dev/null > > > 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." > http://cr.yp.to/ucspi-tcp/rblsmtpd.html Need I say more? > Example 2: > > mail from:<[EMAIL PROTECTED]> > > the response is "bugger off." 'man qmail-smtpd' see the section on 'badmailfrom'. > Example 3: > > rcpt to:<[EMAIL PROTECTED]> > > the response is "bugger off." http://patch.be/qmail/ - another example of qmail's extensibility. > 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. I have helped many people running 'serious' mail servers with such issues. rblsmtpd is one of the things I highly recommend. Once again, I assumed. I assumed you meant filtering mail by content, which obviously you have to download the entire message for. But that's once again, not a problem isolated to qmail. Oh, unless of course there's some MTA out there that has ESP and knows what the other MTA is going to send, before it sends it, and can reject it, based on content. > Hey, how are your nuts? I haven't even lit the fire yet... mature. > > > 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. I'm Jeremy. Not Ken. I will assume you were adressing me, and reply to that: Your reply was meaningless. But I will extend on what you replied to: RedHat has its reasoning for not shipping qmail with their distribution. It's not because they don't think qmail is good enough, it's because of Dan's licensing policy. Arguably, that does hurt qmail, but that does NOT make it a poor MTA. > 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. so use one of those other MTAs. Nobody is stopping you. > > 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... I'm not a developer, and I really wouldn't know where to begin on some things. I am learning though. I submitted a patch to the qmailadmin project for the autorespond program and brought up a design flaw in how qmailadmin handles its 'vacation replies' and 'mail robots' and how the autorespond package cannot reliably fill both of those pairs of shoes. > > 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... Isn't that the way it always is? So you're basically ripping on qmail (which is free to use) for not doing the things FOR YOU that would make you more money, so you can continue to use it for free. Then you complain about having to spend time and money developing said features for qmail. You know, you DO generally have to do some work to make money in this world (unless you have 20 million in the bank, then you can live off the interest) > > 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. DJB's shitty attitude about what? A problem that you're having that he can't possibly solve by writing software or extensions to qmail. > Do NOT put words in my mouth or I will destroy you with facts and > historical record. Apologize NOW or face the chestnuts... show me where DJB has made comments on situations such as yours that show his 'shitty attitude' about it. Once again, I will add that he can't POSSIBLY solve the problem by writing software. > > 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. ok. http://www.qmail.org/turnmail I tried to think of a very precise way to make that do what you want it to do, but I don't know enough about serialmail to see if that application would work for you. My idea: you could catch mail for them on your server, they 'log in' with turnmail and you start feeding them mail. After say.. a day, you force them to log in again to get their mail. Seems relatively simple, if that fits your situation. [addendum, 10 minutes later] That is indeed a solution to your problem. You set up a dummy virtualdomain with a catchall maildir, and run that in place (and in line) with qmail-pop3d. If you want, you can fire that up on an off port, along with a custom checkpassword (there are some on www.qmail.org that could serve this purpose, or you can write one in perl/python/bash/c in about 20 minutes) and set up a little cronjob that would run getmail or the like (although even that is way more than you would need to simply authenticate). That turnmail script could also be modified to log its pid to make sure you don't run two maildir2smtp processes. [/addendum] > > 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. and how, exactly, do other MTAs deal with the situation? Like I stated in my last reply, no MTA can magically stop an email from going to another machine that has its old IP address, when it's not online at all. I guess the electrons just fly through the air. > 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. I assume you meant qmail there. I'll just ignore that since I've already provided you with a solution to your problem. A little bit of research can go a long way. -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
