Jeremy Kitchen writes: > little long winded, but if you read to the end, there's a nice > surprise! A solution to your problem!
A solution is nice. If it works... > 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. Other MTAs do that by being monolithic code and that is where the security problems arise. > > I stated that qmail is lacking in functionality that other MTAs > > provide. > > oh look, you said it again. I said it again because it is an important point. I can write an entirely secure MTA in a couple of minutes. It cannot do anything except issue an error code to everything you try to do, but it is 100% secure. What? You want it to actually accept and deliver mail? That would compromise the security model, just to give you extra functionality you think you ought to have. > he wrote qmail to be reliable and secure. Which one of those hasn't > been accomplished? See above. I can write an MTA that is 100% reliable (it NEVER claims to have accepted mail which it subsequently discards) and is 100% secure. The functionality is a little lacking, but you seem to consider functionality to be unimportant. > do you want reliable, secure, 'expensive' service? Or would you rather > have unreliable, insecure, FEATURE PACKED 'expensive' service? I pick > the former. I don't want features nobody uses or needs. I do want features most of our customers need. How many patches are there for qmail now that just about everyone uses? Relay after POP. SMTP AUTH. Accommodate AOL's broken DNS. Etc. These are things DJB did not put in and refuses to add yet are pretty much vital for most people. The number of "standard" patches was 20 or so last time I looked. Each one addressing something DJB refuses to add but which most people consider essential. Technically, relay after pop and SMTP AUTH are not entirely secure. But the alternatives are either being an open relay or not being able to offer mail services to anyone who has dynamic IP. Back in the real world, people have to patch qmail to make it do what DJB insists is a bad thing. > > 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. That is a matter of FACT. How long did they go without any visible development? Was it one year or two? How many enhancements have appeared since Tom took charge? > > and started making them serious competitors to qmail. > > I didn't think vpopmail and qmailadmin were competing with qmail. > vpopmail and qmailadmin supplement qmail. Sigh, it was late. "Started making a qmail-based solution a serious competitor to other MTAs." If you have something like sqwebmail as part of the solution, anyway. And if you hack either vpopmail or qmailadmin to allow the use of sqwebmail's filters. Then you get something that approaches what people get with other MTAs. > > If you want to bitch, tread *very* carefully or I will roast your > > cojones like chestnuts.. > > I see our maturity level is high. I thought it was very mature to warn you of what I would do. And AM doing right now... > 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. It can be anywhere from minutes to hours. But even seconds is enough to allow mail to go missing. > I simply assumed you meant it was switching IPs. The changed IP is a consequence of the down-time. > I apologize. Still, exchange can't fix that part of your issue, nor > can ANY other MTA. Period. Really? Have you heard of ETRN? It's something other MTAs support without patching. Again, there are security issues with ETRN, so DJB simply refuses to implement it. And again, in certain circumstances the lack of ETRN is a bigger security issue than having it. But rather than making it something you can choose to enable if you really need it, DJB says you cannot have it. Not with an unpatched qmail. Does anyone, other than DJB, run an unpatched qmail? > that's an ISP issue, not a qmail issue, not an MTA issue, not an issue > any MTA can solve. ETRN + SMTP AUTH solves it. Both are things DJB refuses to implement although most other MTAs offer them. Nor is saying "it's an ISP issue" an adequate argument. SMTP was designed around the premise that Internet connectivity was unreliable. It was also designed back in the days when all IPs were static and allocated in blocks so that if you did change your mail server's IP then you could guarantee that nothing would be listening on port 25 on the old IP until after TTLs had expired. It is not an ISP issue, it is that DJB refuses to deal with how things are in the real world today. > 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. Have you ever had a medium sized company with 50 users all using IMAP handle their mail over unreliable ADSL to a colo? It gets a little slow compared with having a server in-house. You can speed it up by only synching headers, but then when the ADSL goes down you can't read mail you have already received. Oh, and then there's the little problem that whether it is sensible or not, that's what the customer wants to do. We could go all DJB and tell the customer that they're so stupid we're not going to do business with them. But that doesn't pay the bills... > 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. We provide dynamic DNS for this customer. That's our bandwidth you're talking about. Which is not just the TTL on the DNS but also the constant "I am still here and this is my IP" traffic to ensure we never have stale information if they disappear. Which is not too bad if it's a one-off but is something I would hate to do on a large scale. > once again, I apologize for missing the extended period of downtime > part. It doesn't matter how long it is, except for affecting the probability of mail going astray. Short down-time does not make the problem go away, it merely makes it less likely to happen. Probabalistic solutions are sub-optimal. If I cross the road without looking, I can decrease the probability of getting run over by running rather than walking. I still do not consider that to be a good solution. > 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? You use ETRN to ensure that the MTA does not send mail to you UNLESS you are there and listening. > 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. And the constand "yes, I am still here and this is my IP" traffic? It is feasible with only one or two customers doing it, but ETRN would make it unnecessary. > 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. Nor would the 20 or so patches that implement necessary funcionality that DJB refuses to include. And even with all the patches, vpopmail, qmailadmin, sqwebmail and maildrop, it still does not do everything that Exchange does and that customers want. It's close enough that we can often manage to persuade them to go with us, but it's hard work to do so. A lot of what Exchange offers may be a bad idea from a technical viewpoint but people expect that functionality. > qmail doesn't have a steep learning curve. UNIX does. Once you figure > out how UNIX works, qmail is very natural. Nope. The philosophy of Unix is that it allows you to do things, no matter how undesirable others might think those things are. The philosophy of qmail is that you cannot do things DJB disapproves of without pain. Qmail is a bondage-and-discipline MTA. Instead of "this is a bad idea so it defaults to being disabled but you can have it if you want it and these are the consequences" qmail offers "this is a bad idea so you can't have it without a lot of pain." > www.lifewithqmail.org is pretty much 'qmail for dummies', I have the book. Which is better than the other qmail book but has many omissions, is poorly-indexed, and in many places gives nothing more than is available in the man pages. It is an asset, but it could have been a lot better. > > 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. Why not? They show the same "like it or lump it" attitude as DJB. > You were talking about how much qmail sucked because your internet > connection is terrible. Our internet connection is very reliable. That of our customer, who wants a dedicated in-house mail server, sucks. > > Example 1: > > > > helo spammer.com > > > > the response is "bugger off." > > > > http://cr.yp.to/ucspi-tcp/rblsmtpd.html Need I say more? Yes, you can tell me a reliable blackhole service. One that doesn't cave in when spammers try to flood it off the net. One that doesn't blacklist good domains when spammers spoof them. One that has NO false positives. One that is smart enough to know that some of our customers WANT mails from domains it considers to be spam-havens. > > Example 2: > > > > mail from:<[EMAIL PROTECTED]> > > > > the response is "bugger off." > > 'man qmail-smtpd' see the section on 'badmailfrom'. I already use that for the worst cases where I KNOW that none of our many customers will ever want mail from that address and I KNOW that it isn't spoofed. Which is about 0.00001% of the time. > > Example 3: > > > > rcpt to:<[EMAIL PROTECTED]> > > > > the response is "bugger off." > > http://patch.be/qmail/ - another example of qmail's extensibility. Another example of a patch to add functionality that DJB refuses to implement. > I have helped many people running 'serious' mail servers with such > issues. rblsmtpd is one of the things I highly recommend. One of our customers welcomes stuff others regard as spam. Those mails are an *essential* part of their business. Even if blackhole servers were reliable and had no false positives, I still could not use them on our shared servers. So the only option is maildrop mailfilters (did I mention that qmailadmin/ vpopmail do not yet support them) and that means that the server has to accept the mail before it can discard it. > 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. Indeed. But sometimes you can filter on sender or recipient. I have several customers who have abandoned one or two mailbox names which were getting nothing but spam. The qmail model does NOT permit rejection on recipient name until after the mail has been received in FULL. And that is a deliberate design decision by DJB because he wanted to make it as hard as possible for anyone to do what he thinks they shouldn't. To filter on recipient you need to write the mail content to a temporary file just so you can eventually get the envlope headers, then read from the temporary file so you can send it out on fd0 and then send the envelope headers out on fd1. Had DJB done it the other way around, the *logical* order in which an SMTP server receives things, it would not be necessary to go through those contortions. > 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. Do you think I do not know that? It is another example of DJB refusing to live in the real world. There is no reason why he could not package his stuff in an RPM and tell Red Hat they can ship that but not modified versions. It would not be good enough for most people (see the 20 or so essential patches adding necessary functionality DJB refuses to) but at least it would let Red Hat ship a basic qmail with the distro - enough for people to play with and maybe decide that it would be usable if they got the patches. As it is, RH ships with Postfix and that is what most people are going to go with. > Arguably, that does hurt qmail, but that does NOT make it a poor MTA. Yes, it does make it a poor MTA. You could have a gold-standard MTA that beats qmail on performance and security and beats other MTAs on functionality but if your distribution conditions mean that nobody uses it then it is worthless. Qmail lacks functionality and the distribution conditions mean people use other MTAs anyway. Usability, whether for end users or for installers, is an important issue. Qmail is deficient in usability for both. > so use one of those other MTAs. Nobody is stopping you. You are correct. And sooner or later, that is what we will probably end up doing, because other MTAs do what users expect and want (no matter how stupid their expectations) and can be installed quickly and easily by point-and-click monkeys. These days, hardware is cheap and technical people are expensive. It's cheaper to buy a fast box that a point-and-click monkey can install some other MTA on than to go with qmail and all the add-ons needed to get the functionality somewhere close to other MTAs. > 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. I think we'd make more money if we switched to Exchange. We could get our low-level guys to install it and we wouldn't be losing as many customers who want Exchange's functionality. I don't like MS's embrace and extend philosophy, but when 99% of our customers use MS MUAs, either our MTA offers what MS deludes them into thinking they want or we lose them. > Then you complain about having to spend time and money developing said > features for qmail. I have submitted suggestions and/or code to vpopmail, qmailadmin and sqwebmail (and getting Mr Sam to accept sqwebmail changes is a struggle sometimes). > 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. Serialmail almost does the trick. ETRN does the trick but isn't in qmail. Etc. People need the functionality provided by the 20 or so patches that DJB refuses to take on board. > show me where DJB has made comments on situations such as yours that > show his 'shitty attitude' about it. Just about any of his, or his admirer's, responses in the qmail lists. "You can't do that." "I don't think you should do that so I refuse to tell you how." That sort of thing. OK, I paraphrased, but that is the general attitude. > Once again, I will add that he can't POSSIBLY solve the problem by > writing software. Did I mention ETRN yet? It was designed for people with dial-up, have dynamically-assigned IP and are not continuously connected... > 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. As far as I could see, the serialmail stuff assumes static IP. > My idea: you could catch mail for them on your server, they 'log in' > with turnmail That is something I hadn't found when I looked at the serialmail stuff. It looks like it might work. > 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. Ummm, you just appear to have found a way of doing just that, using a similar idea to ETRN. It is called "here I am, give me my mail." But I have to write a custom checkpassword routine, at least, to make it work. Yeah, that sure beats having a point-and-click monkey install Exchange which does what is needed out of the box. > A little bit of research can go a long way. A "little bit of research" involved a lot of googling and not turning up any answer, reading the serialmail docs and finding everything mentioned static IP, etc. Compare that with having a point-and-click monkey install Exchange and it does what you want out of the box. Qmail's poor documentation would be adequate if it did everything you want out of the box. Finding out how to do something DJB doesn't want you to do usually requires a lot of work. "No pain, no gain" doesn't cut it economically. -- Paul Allen Softflare Support
