[qmailadmin] Re: possible feature additions
Tom Collins writes: There's also an outstanding request for a bounce address using the qmail bouncesaying program. Is bouncesaying such a good idea these days? Was it ever? In a few limited cases (this domain has been suspended because they refuse to pay their bills) is a good example of its use, but one you'd not want the domain admin to have control over. In the old days, any mail to a non-existent user was almost certainly a typo and was rare enough that postmaster could handle it. Or it was a hurried guess at a role address or a mailbox that was deleted when somebody left and again postmaster ought to figure out who to forward it to. In the first case bouncesaying had some merit for lazy postmasters and in the other two cases it would be little or no help to anyone since the recipient of the bounce would then mail postmaster about it. These days, most mail to non-existent users is sent by spammers using programs that try random usernames against domains. Bouncesaying looks like a wonderful idea for domain admins - that will teach those spammers when they get their rubbish back. But it isn't a wonderful idea as far as sysadmins are concerned unless they direct doublebounce mail into a black hole because spammers generally use fake, non-existent addresses. So not only does bouncesaying double the traffic by sending the junk back, it triples it when the other end bounces the bounce. A lot of the mail I wade through is doublebounce mail because our domain admins set no catch-all even though we tell them they must have a catch-all. No, you won't stop the double-bounces completely by removing bouncesaying and stopping them setting no catch-all. One particularly inventive user has recently abandoned a mailbox that got nothing but spam by replacing it with an autoresponder. Not only that, he's configured it in such a way that instead of me getting a doublebounce, I get a looping error. Users: you can't live with them, you can't chop them into small pieces and flush them down the toilet. -- Paul Allen Softflare Support
[qmailadmin] Re: possible feature additions
Michael Bagnall writes: I think the various points have been made. This is a support list - not a place to bitch about things. Thanks. Hey, Mike, you just bitched about things. Can we keep this sort of stuff off the list? Thanks. Oh, and if you could learn not to quote the entire message that you are responding to, when none of what you quote is necessary for newbies joining the list to understand your point, that would be great for those on low-speed connections. Of course, that advice really only applies to those who complain about the noise on this list. Yours in sweetness and light... -- Paul Allen Softflare Support
Re: [qmailadmin] Re: possible feature additions
Dear Paul, Your abusive behavior on this mailing list is not appropriate. As administrator of the list I will have to remove you if you can not play nicely. Ken Jones On Wednesday 29 October 2003 8:36 pm, Paul L. Allen wrote: Jeremy Kitchen writes: Damn it's 2:30 am here and I really do need to go to bed. Jeremy, rest assured that I have skimmed through your response and I will tear it to shreds when I have the time tomorrow. And believe, me Jeremy, I will kick the crap out of you (I'm drunk now, and in far too good a mood to attack people). BTW, Jeremy, you don't even come close to Tom Collins for technical understanding, innovation or honesty. Thank Fhuck that Tom wreested control from the fhuckwits at Inter 1.5. BTW, Jeremy, I am VERY pleasant and understanding when drunk, as I am now. Be prepared to have the crap kicked out of you tomorrow...
[qmailadmin] Re: possible feature additions
Paul Theodoropoulos writes: let me boil all this down, since this is becoming a pointless thrash. you made the following statement: And if it weren't for DJB's stubbornness, its usage might actually be growing instead of steadily declining. you've provided no evidence to support that statement. And you implied I was wrong yet you provided NO evidence to support your statement. And when I called you on it, you responded by repeating your claim that I was wrong and had provided no evident. Yet I actually gave evidence for my claim. Firstly, mirror traffic is declining. Secondly, qmail is at the bottom of recommendations which ARE followed by newbies. Oh, I forgot. Somebody looking for a replacement *nix MTA will go out looking for recommendations and choose the MTA at the BOTTOM of the list with the fewest features and the most criticism. People do it all the time. What car shall I buy? Well, there's an ancient second-hand Ford Pinto for sale, and I see that incredibly bad design means that if the Pinto gets rear-ended then the gas tank ruptures and you go up in a fireball. MUST HAVE!!! It happens all the time: people research competing products and choose the one that everyone says is the worst... either support the statement with evidence, or withdraw the claim. simple. I think so too. Support YOUR implication that I am wrong with evidence, or withdraw it. again, i'm not particularly trying to badger you. but the fact is, you are speculating that usage of qmail is declining. you have a hunch. you have a gut feeling. you think so. you believe so. You are speculating that it is not declining, but have provided NOTHING to support your speculation. Nothing at all. You have a hunch... and again, since i've made NO claim either way - reread the thread - nowhere have i said usage of qmail is increasing or usage of qmail is declining - , there's nothing for me to support, or to provide evidence for. you made the claim. back it up, or withdraw it. Ah, we get to what the meaning of is is. You are increasingly shrill in demanding that I withdraw my claim. Therefore you believe the claim to be false. It is that simple. You do not say you may be right but I think you don't have enough proof to be certain or I think you may be wrong but withdraw your claim or I'll scream and scream until I'm sick. There is no doubt that you wish people to believe qmail usage is increasing and are unwilling to entertain the possibility that it is declining. hopefully there will be at least one more response in the thread You get your wish. In part, anyway. -- Paul Allen Softflare Support
[qmailadmin] Re: possible feature additions
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
Re: [qmailadmin] Re: possible feature additions
Sorry my English, my natural languague is Spanish, and I talk/write very bad in spanish too :) I don't write much here, and now that I write it is not on qmailadmin Please STOP this, it is interesting, but it doesn't serve as anything The discucion doesn't make sense From the name of who originate the discussion should be a joke, Paul Allen???, Microsoft, please Paul A., if you have problems with the style of programming of DJB, please, call it, and discuss it with him One more thing, here I pay around u$s 200.- by month for 1Mbyte with a fixed IP and two phone lines, how much you pay on UK (I'm from Argentine) There are thousands of solutions to your problem, please read more, don't accuse others per your lack of genius Don't answer this to the list Pablo Murillo
Re: [qmailadmin] Re: possible feature additions
On Thu, 2003-10-30 at 07:19, Paul L. Allen wrote: [snip endless droning about how someone had to work a little to get what they wanted] This discussion is off topic, and pointless. Obviously you have it in you that qmail is evil and DJB is out to get everyone. I'm through feeding this troll. -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
[qmailadmin] Re: possible feature additions
Jeremy Kitchen writes: On Thu, 2003-10-30 at 07:19, Paul L. Allen wrote: [snip endless droning about how someone had to work a little to get what they wanted] This discussion is off topic, and pointless. Nope, it highlights the commonality in attitude between Inter 7 and DJB. An attitude which Tom Collins does not share. Tom sees feature requests that address needs and acts upon them; DJB and Inter 7 see feature requests that address needs and tell people to go screw themselves because they do not need those features. Obviously you have it in you that qmail is evil As I said, qmail is secure and reliable. But it fails to include the vital functionality that is provided by the 20 or so patches that almost everyone considers to be essential. YOu put words in my mouth... and DJB is out to get everyone. Another straw man. I stated that DJB's attitude means that qmail is declining in popularity and explained why. Some DJB-heads immediately proclaimed that they would not trust any mail server created by any means other than getting a tarball and compiling from scratch. You'd better not tell them that Inter 7 dropped vpopmail and qmailadmin development for over 18 months because Ken was working on developing RPMS that Inter 7 could make money on and show no intention of making available under the GPL. Jeremy, did I not give you a warning yesterday about terrirtory you had better not eplore? I thought I did... If not, I will take this no further. If I did give you that warning and you pursue this, it is chestnut time... I'm through feeding this troll. But I am far from through exposing your lies. Of course, you can delete me from the list. But I have enough direct contacts that such an action would not go unnoticed or unremarked upon here. -- Paul Allen Softflare Support
[qmailadmin] Re: possible feature additions
Pablo Murillo writes: One more thing, here I pay around u$s 200.- by month for 1Mbyte with a fixed IP and two phone lines, how much you pay on UK (I'm from Argentine) Here, out in the sticks, I pay about US$22/month for a crappy 56K dial-up with a limit of 16 hours/day usage. I work from home administering servers with bandwidths many thousands of times what is abailable to me here. But since they are Linux servers, this is not a problem. With Windows servers, using VNC or similar, administering Windows servers would be so painfully slow as to be impossible. There are thousands of solutions to your problem, please read more, don't accuse others per your lack of genius Did I ever claim (here) to be a genius? I don't think so. But I know I can beat most people in finding things through Google. After two hours, I concluded that it is hard to find answers about the problem I had. Two hours in which I could not find a way of doing what Exchange does out of the box. Does that sound like an economic solution to you? Yeah, if I could amortize it over hundreds of clients it would be economic, but right now it applies to ONE client of HUNDREDS. Given what we charge our customers for hosting and what we charge for my time, I figure we have made a loss for this year on this customer. I exclude the leisure-time posts I have made here in the hope that qmail and friends might end up being a usable alternative to Exchange, becuase if I included the time I spend on those posts then it would take us ten years before we could show an economic profit (but I underwrite my own pleasurable experiences). Don't answer this to the list You do not control what I write or where I write it. You may *request* where I respond but I am under no obligation to honour that request. What I DO guarantee is that if you mail me off-list I will either respond off-list or ignore you. If you post on the list then I reserve the right to reply on the list until such time as the list moderators remove me from the list. If you want to criticise me here then you have NO right to demand that I respond to your critisms only in private. Another criic of mine has contacted me privately. And I have responded to him privately, as I will to any criticism expressed privately. If you make the venue public, you have no moral right to demand I express any disagreement in private. Make the disagreement private and I will tell you (if I think it necessary) that any time I admit to being wrong you can publish that publicly (if I do not do so myself first). If you prove me wrong in private, I GUARANTEE your right to make that fact public. Sorry, I forgot that English is not your native language. Let me simplify this for you: YOU do not get to dictate what I say or where I say it. -- Paul Allen Softflare Support
Re: [qmailadmin] Re: possible feature additions
Paul, On Tue, 2003-10-28 at 15:47, Paul L. Allen wrote: Justin Hopper writes: Ah yes, I had forgotten that qmail will dump email if it sees a # sign in a dotqmail file. I was never sure if this was a desired effect or not, so I've never used it. According to the man page for dot-qmail, if the .qmail file is empty then it is ignored and defaultdelivery instructions are processed. It is too late (and I've had too much wine) for me to remember where I saw the tip about the #, but it was somewhere I considered trustworthy (trust is not transitive, so you should not believe me). But it does follow from djb's minimal, you have to be a guru to install qmail and I'm not going to explain it for you, shoot-yourself-in-the-foot and let Exchange win because it is easy to install and you have to be a masochist to install qmail, tendencies. IF the .qmail file is empty then it is ignored. That much djb states explicitly. Logically, if the .qmail file is NOT empty then it is NOT ignored. A .qmail file may contain various delivery instructions including comments. That much djb states explicitly. The logical conclusion is that a .qmail file containing just a comment is processed and causes mail to silently be discarded because there are not instructions which would result in a delivery. For any other application I would consider this to be undocumented behaviour which cannot be relied upon. For djb stuff, I consider that anything which can logically be deduced from the documentation is 99.999% certain to be intended, supported, and unchanging behaviour. One day, somebody ought to introduce djb to the Real World[tm]. The place where it takes an expensive admin a long time to figure all the qmail stuff out and where people can hire a cheap point-and-click monkey to install Exchange or even do it themselves. One where the raw features provided by qmail are so limited that neither ISPs nor customers are satisfied with what is available and one where Exchange is viewed by customers as the dog's bollocks (a UK phrase meaning something that is very good). The newer sqwebmail features such as filters go some way to redressing the balance, but they are effectively an extension to qmail by a different author. Qmail is secure and reliable while Eschange is an insecure, unreliable pile of steaming manure. But Exchange offers what people want (or think they want) and qmail is very restrictive. Djb would do well to read, and inwardly digest, Kernighan's Why Pascal is not my favourite language and Wall's comments about bondage and discipline languages. Sadly, qmail is a bondage and discipline MTA, and that is why its popularity is declinging FAST. Red Hat used to come with sendmail. Now it comes with postfix. Because of djb's copyyright conditions, Red Hat will NEVER come with qmail. In terms of security and reliability, qmail is better than either. In terms of out of the box install of your favourite distro, qmail just isn't in the running. Sigh, I'm ranting. And that's probably because months after I first started using qmail, I hit the problem that qmail passes mail around by sending the content on file descriptor 0 FIRST and the envelope headers on file descriptor 1 SECOND. In an SMTP transaction, the envelope headers come first. Logically, the envelope headers come first. In order to do filtering (like anti-virus, or spam filtering, or sender filtering, or recipient filtering) you WANT the envelope headers first. My conclusion is that djb DELIBERATELY did it the wrong way around to make it as hard as possible to add filters unless you are a guru. And for that, I hate his guts. I respect his coding skills. I respect his knowledge and understanding of mail RFCs. And I think he is a complete dickhead for his bondage and discipline attitude. I despise djb more than I do Nicklaus Wirth (hey, Nick, if I call you by value then I pronounce your name dickhead not worth) because Pascal is a crappy language in the first place and there are better alternatives) because if I want reliability and security then I have to use qmail and put on my bondage gear. Maybe djb got confused between BSD and BDSM and thought he needed handcuffs, chains and whips to write for BSD... If this is the way it is supposed to work, See above. I think that if it can be logically inferred from the minimalist documentation then that is how it is supposed to work. Wow. Of all the rants I've read on mailing lists, this is probably one of the most interesting. 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. However, over the years, we have come to appreciate qmail's extremely modular and simplistic nature. The modularity is the most important aspect, since this allows it to grow from the minimalist MTA to a fully featured one. If it wasn't for
[qmailadmin] Re: possible feature additions
Paul Theodoropoulos writes: i don't think djb makes any bones about the fact that qmail is meant for serious MTA usage. sites on non-static IP addresses are not serious MTA sites. that's my opinion, but i think it's borne out in practice as well. I would NOT run a mail server handling many independent domains on dynamic IP. But the reality in the UK is that if you want static IP on ADSL they charge you three times as much. You and I know that they need exactly the same number of IP addresses for ADSL whether they are statically or dynamically assigned and that the difference in cost of configuring the server to provide static rather than dynamic is so small as to be immeasurable. But static IP is more useful than dynamic IP (as here, for instance) so most UK ISPs charge all the market will bear. The fact is the medium-sized enterprises need their own mail server and ADSL to handle the volume of mail. And the fact is that static IP with ADSL if freaking expensive here. These are the realities. You may not consider this a serious usage of MTA but the people concerned do. And I agree with them. They have a problem caused by UK ADSL providers and it is a problem which needs a solution. If ADSL weren't so flaky here, it wouldn't be a problem, but it is. anyone who intends to transport significant amounts of mail, reliably, does not do so on a dynamic IP. ADSL is *expensive* here. ADSL with static IP is *freaking expensive*. What do you suggest as an alternative? Hint: It can't be done so just stop getting e-mail is not an answer our customers are going to accept. Part of the problem is that another company is dealing with their Exchange server and that company is a dumber than George W's little finger. But we're not in a position to influence their choice of who does what, expect if we annoy them enough that they stop using us for anything. but its rather like complaining that a semi-truck trailer makes a poor minivan. How about pointing out that both have wheels and while minivan comes with the tools that allow you to change punctures, the DJB semi has features that prevent you EVER changing a puncture? And if it weren't for DJB's stubbornness, its usage might actually be growing instead of steadily declining. citations? We run a qmail mirror and traffic is declining. Look at just about any comparison of *nix MTAs and qmail is near the bottom. I know a couple of ways of identifying qmail even when the greetings message has been changed and patches have removed other obvious identifications and by my reckoning Hotmail no longer uses qmail (but probably still doesn't use Exchange). I wouldn't want to entrust my important email to anyone who is unwilling or unable to deal with the 'steep' learning curve of qmail. You are a techy. As am I. Microsoft sell something that people can install on a machine in their office to handle their mail. An idiot can install it. Microsoft promise (hah!) that it is reliable. You can pay peanuts to a monkey to install it. While you and I may want people who know what they're doing to install a reliable MTA, most of our customers want the features offered by Exchange and do not understand the hidden costs but see that they even the toilet cleaner could install it. disclaimer, i am in business providing bulletproof email services. i use qmail and vpopmail. Most people BELIEVE that Exchange is bulletproof, because Microsoft tells them so. The simple fact is that actually is bulletproof but is missing functionality that their checklist says they have to have versus is a pile of steaming manure but *claims* to be bulletproof and has all the features on their checklist even though they will never use them is a foregone conclusion. They go for Exchange. you can have my qmail when you pry it from my cold dead servers. so to speak. ;^) Sadly, my increasingly pointy-haired boss cares less and less about reliability than about giving customers what they think they want. He is probably right: there are very few customers intelligent enough to understand the technicalities but there are lots of cusomters taken in by MS bullshit. -- Paul Allen Softflare Support
Re: [qmailadmin] Re: possible feature additions
At 03:09 PM 10/29/2003, Paul L. Allen wrote: The fact is the medium-sized enterprises need their own mail server and ADSL to handle the volume of mail. And the fact is that static IP with ADSL if freaking expensive here. These are the realities. You may not consider this a serious usage of MTA but the people concerned do. And I agree with them. They have a problem caused by UK ADSL providers and it is a problem which needs a solution. If ADSL weren't so flaky here, it wouldn't be a problem, but it is. ADSL is not a reliable backbone medium. Secondly, ADSL service guarantees are generally along the lines of 'if it goes down, we'll get someone out to check it within 24 hours, and we'll see if we can fix it'. A T1 (would that be an E1 over there?) generally has service guarantees that are measured in single digit hours, and they will keep working on it until it's fixed. I'm speaking of course from a U.S. perspective - please correct me if i'm wrong (i know you will ;^) If you are doing _serious_ email, you don't use an unreliable backbone medium. The definition of _serious_ should be obvious. There are people who rely upon their email for their livelyhood. There are people who *must* receive their email reliably, on time, every time. There are also a great many people for whom reliable email service is not a significant priority. anyone who intends to transport significant amounts of mail, reliably, does not do so on a dynamic IP. ADSL is *expensive* here. ADSL with static IP is *freaking expensive*. What do you suggest as an alternative? Hint: It can't be done so just stop getting e-mail is not an answer our customers are going to accept. no, you tell them we cannot promise reliable delivery of email if you host it on an unreliable backbone line. we would recommend that you host your email elsewhere. but its rather like complaining that a semi-truck trailer makes a poor minivan. How about pointing out that both have wheels and while minivan comes with the tools that allow you to change punctures, the DJB semi has features that prevent you EVER changing a puncture? but of course, a single puncture on that minivan incapacitates it. The semi, being designed for reliability, has multiple, redundant sets of axles and wheels and tires, so a single blowout doesn't cause a catastrophe. picking at a metaphor usually leaves a nasty scab. so i'll leave it there... And if it weren't for DJB's stubbornness, its usage might actually be growing instead of steadily declining. citations? We run a qmail mirror and traffic is declining. that could be due to any number of factors, few directly related to the actual growth or decline in usage of qmail. neither is it an empirical or definitive test of same. better to say i believe that qmail usage is dropping, but i have no evidence. Look at just about any comparison of *nix MTAs and qmail is near the bottom. comparisons are not a measure of whether the usage of an MTA is growing or declining. I know a couple of ways of identifying qmail even when the greetings message has been changed and patches have removed other obvious identifications and by my reckoning Hotmail no longer uses qmail (but probably still doesn't use Exchange). so you have no proof, correct? not trying to badger you, but the fact is, you've expressed an opinion that you believe qmail is not growing in usage. that's fine, and is your privilege. it is not a fact, however. I wouldn't want to entrust my important email to anyone who is unwilling or unable to deal with the 'steep' learning curve of qmail. You are a techy. As am I. Microsoft sell something that people can install on a machine in their office to handle their mail. An idiot can install it. Microsoft promise (hah!) that it is reliable. You can pay peanuts to a monkey to install it. While you and I may want people who know what they're doing to install a reliable MTA, most of our customers want the features offered by Exchange and do not understand the hidden costs but see that they even the toilet cleaner could install it. that's fine. one can always attempt to disabuse the customer of their misunderstanding of the situation. and of course, when they come crying at your doorstep in the middle of the night because their whitebox PC with a single IDE disk in it on an ADSL line crashed and had to be wiped clean, taking with it a years worth of critical email (who backs up their PC!?), then you can say i told you so. then you charge them up the yinyang for some reliable email service. ;^) but there are lots of cusomters taken in by MS bullshit. that's really what it all boils down to, i'd say. Paul Theodoropoulos http://www.anastrophe.com
Re: [qmailadmin] Re: possible feature additions
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
[qmailadmin] Re: possible feature additions
Paul Theodoropoulos writes: At 03:09 PM 10/29/2003, Paul L. Allen wrote: ADSL is not a reliable backbone medium. But they're not backbones. They're end users who want something faster than dial-up or ISDN. I work from home and I'm out in the sticks and I can't even get ADSL (don't even ask about satellite because the cost here is something you wouldn't believe). Secondly, ADSL service guarantees are generally along the lines of 'if it goes down, we'll get someone out to check it within 24 hours, and we'll see if we can fix it'. Yep. But the problem here is not that they could be without mail for 24 hours but that for 24 hours somebody could end up sucking their mail down. Not just a breach of confidentiality but also the mail is permanently lost to them. Unlikely to happen, but not impossible. A T1 (would that be an E1 over there?) Just as ADSL is unavailable in much of the UK, E1s are unavailable in many populous parts of the UK. And you don't want to know about the price. Really you don't. If you are doing _serious_ email, you don't use an unreliable backbone medium. The definition of _serious_ should be obvious. There are people who rely upon their email for their livelyhood. These days, many companies rely upon e-mail for their livelihood but cannot afford what it takes to get static IP. There is an ISP in the UK supplying dial-up services which, as soon as you dial in, pumps your mail at you (if you have an SMTP server running). In fact, this was the first mass-marked ISP in the UK. And this is *exactly* what these people want as regards mail. Should I tell them they should move away from us and their ADSL to a much slower BONDed ISDN just so they can get their mail reliably or should I try to find an answer? Hint: the money they pay us pays part of my wages. ADSL is *expensive* here. ADSL with static IP is *freaking expensive*. What do you suggest as an alternative? Hint: It can't be done so just stop getting e-mail is not an answer our customers are going to accept. no, you tell them we cannot promise reliable delivery of email if you host it on an unreliable backbone line. we would recommend that you host your email elsewhere. Which is what we may have to tell them. And they may well then switch to somebody who will LIE to them or who CAN provide reliable delivery using something other than qmail. The SMTP RFCs went to great pains to ensure that delivery is (well, should be) reliable. You shouldn't get an OK back from the server until it is certain that the message has been flushed to disk. But they were written in a time when ADSL with dynamic IP was relatively rare. The *spirit* of those RFCs is that mail should get where it is intended to go. Qmail + dynamic DNS, which is becoming increasingly common here, means the spirit of those RFCs is violated. Please adjust to reality. I have to deal with the real world, not an idealized one where all our customers have more money than sense and live in a location where they can get an E1 or accept our recommendations when they cannot get an E1. If I had users who were as smart as those described in the BOFH stories I would be in heaven. picking at a metaphor usually leaves a nasty scab. so i'll leave it there... Especially as we don't call them semis here and I had to guess. We run a qmail mirror and traffic is declining. that could be due to any number of factors, It could. But the number of qmail mirrors is not increasing fast enough to compensate. comparisons are not a measure of whether the usage of an MTA is growing or declining. True. But going by my increasingly pointy-haired boss, who evaluates technology first on how strongly it is recommended, and secondly on aesthetics, I consider this to be cause rather than effect. Many bosses look at the recommendations first and do not have the technical ability to evaluate ther technical merits (my PHB is a techy, but rarely uses his technical skills to over-ride his our customers will love this pile of manure judgements). I know a couple of ways of identifying qmail even when the greetings message has been changed and patches have removed other obvious identifications and by my reckoning Hotmail no longer uses qmail (but probably still doesn't use Exchange). so you have no proof, correct? Ummm, can you offer me proof that hotmail IS using qmail still? Every test I have done indicates it is not, although the qmail mirrors say it is. you've expressed an opinion that you believe qmail is not growing in usage. that's fine, and is your privilege. it is not a fact, however. And do you have ANY proof that *relative* qmail usage is on the increase? It is quite probable that qmail usage is increasing, but not as fast as other MTAs. You have attempted (and failoed) to invalidate the evidence I have avaliabe to me but not provided any of your own to back up your position. I can be convinced - give me verifiable
[qmailadmin] Re: possible feature additions
At 04:12 PM 10/29/2003, Paul L. Allen wrote: Secondly, ADSL service guarantees are generally along the lines of 'if it goes down, we'll get someone out to check it within 24 hours, and we'll see if we can fix it'. that's an inherent weakness simply of using dynamic addresses to host an MTA, you do realize? with a reasonably well crafted timing attack, one could present themselves as the IP the mail is to go to, and grab it all. We run a qmail mirror and traffic is declining. that could be due to any number of factors, It could. But the number of qmail mirrors is not increasing fast enough to compensate. that again is not evidence that qmail usage is growing or declining. there are mirrors all over the world. there is not necessarily any need for more mirrors. if a new mirror comes online with ten times the available bandwidth of five other mirrors in the same region, and those five mirrors then go away because they are not needed, does that mean qmail is less popular? i hope you see the folly in that line of logic. comparisons are not a measure of whether the usage of an MTA is growing or declining. True. But going by my increasingly pointy-haired boss, who evaluates technology first on how strongly it is recommended, and secondly on aesthetics, I consider this to be cause rather than effect. Many bosses look at the recommendations first and do not have the technical ability to evaluate ther technical merits (my PHB is a techy, but rarely uses his technical skills to over-ride his our customers will love this pile of manure judgements). but again, that is not evidence that qmail usage is growing or declining. I know a couple of ways of identifying qmail even when the greetings message has been changed and patches have removed other obvious identifications and by my reckoning Hotmail no longer uses qmail (but probably still doesn't use Exchange). so you have no proof, correct? Ummm, can you offer me proof that hotmail IS using qmail still? Every test I have done indicates it is not, although the qmail mirrors say it is. i didn't suggest i had proof. you've offered the speculation that hotmail is no longer using qmail. to support that, you've supplied no empirical, verifiable, or repeatable evidence to back up the claim. you have a hunch - and you may very well be right - but it is not proof of your claim. you've expressed an opinion that you believe qmail is not growing in usage. that's fine, and is your privilege. it is not a fact, however. And do you have ANY proof that *relative* qmail usage is on the increase? i haven't made a claim either that it's increasing or decreasing. you've made a claim that it is decreasing, but you've offered no evidence to back up the claim. that's all i'm pointing out. It is quite probable that qmail usage is increasing, but not as fast as other MTAs. or it may be the other way around. with out proof, who knows? You have attempted (and failoed) to invalidate the evidence you've offered *NO* evidence. I have avaliabe to me but not provided any of your own to back up your position. I can be convinced - give me verifiable evidence and logical reasoning and I will happily admit I was wrong. you've offered speculation, not evidence. none. this is the empirical method at work. provide evidence to back up your claims. *i've not claimed a position*. *you have*. but you've offered no evidence. only speculation. again, speculation is fine. so long as it is presented as same. claiming that you have proof or evidence without providing any is not helpful. Paul Theodoropoulos http://www.anastrophe.com
Re: [qmailadmin] Re: possible feature additions
On Wed, 2003-10-29 at 18:12, Paul L. Allen wrote: no, you tell them we cannot promise reliable delivery of email if you host it on an unreliable backbone line. we would recommend that you host your email elsewhere. Which is what we may have to tell them. And they may well then switch to somebody who will LIE to them or who CAN provide reliable delivery using something other than qmail. how does exchange, or postfix, or exim, or any other MTA deal with the situation? It doesn't. You can't. It's your ISP. once again, do not blame your shitty isp on qmail, and don't blame your email problems caused by your shitty isp on qmail. The SMTP RFCs went to great pains to ensure that delivery is (well, should be) reliable. You shouldn't get an OK back from the server until it is certain that the message has been flushed to disk. But they were written in a time when ADSL with dynamic IP was relatively rare. The *spirit* of those RFCs is that mail should get where it is intended to go. Qmail + dynamic DNS, which is becoming increasingly common here, means the spirit of those RFCs is violated. again, how is qmail different in your situation than any other MTA? Please adjust to reality. praise what you preach. I have to deal with the real world, not an idealized one where all our customers have more money than sense and live in a location where they can get an E1 or accept our recommendations when they cannot get an E1. If I had users who were as smart as those described in the BOFH stories I would be in heaven. if you had users who were as smart as the bofh you wouldn't have a job, they'd have it. You've obviously proven your ignorance of the matter by blaming qmail for the problems you're experiencing when in fact the problem has NOTHING AT ALL to do with qmail. We run a qmail mirror and traffic is declining. that could be due to any number of factors, It could. But the number of qmail mirrors is not increasing fast enough to compensate. So, you judge qmail's usage by the number of hits on your mirror that you run on your adsl line with the dynamic IP address? Please. comparisons are not a measure of whether the usage of an MTA is growing or declining. True. But going by my increasingly pointy-haired boss, who evaluates technology first on how strongly it is recommended, and secondly on aesthetics, I consider this to be cause rather than effect. Many bosses look at the recommendations first and do not have the technical ability to evaluate ther technical merits (my PHB is a techy, but rarely uses his technical skills to over-ride his our customers will love this pile of manure judgements). Many PHB's have know clue what MTA means, let alone the technical details about how they operate. They tend to choose the email server that looks the most shiny, and not the one that works the best. I know a couple of ways of identifying qmail even when the greetings message has been changed and patches have removed other obvious identifications and by my reckoning Hotmail no longer uses qmail (but probably still doesn't use Exchange). so you have no proof, correct? Ummm, can you offer me proof that hotmail IS using qmail still? Every test I have done indicates it is not, although the qmail mirrors say it is. hotmail isn't using qmail. who cares, hotmail has already been proven to be one of the worst email providers out there. Have you been following the qmail list lately? Almost daily my emails aren't getting to hotmail you've expressed an opinion that you believe qmail is not growing in usage. that's fine, and is your privilege. it is not a fact, however. And do you have ANY proof that *relative* qmail usage is on the increase? It is quite probable that qmail usage is increasing, but not as fast as other MTAs. You have attempted (and failoed) to invalidate the evidence I have avaliabe to me but not provided any of your own to back up your position. I can be convinced - give me verifiable evidence and logical reasoning and I will happily admit I was wrong. we don't need to prove it's increasing, as we didn't say it was. You stated that its usage was decreasing. back up your claims. but there are lots of cusomters taken in by MS bullshit. that's really what it all boils down to, i'd say. I agree. They have meaningless checklists of features the will never use. They believe that Bill Gates sells them gold bars when in actuality they are his turds wrapped in gold-coloured aluminium foil. And it is impossible to convince them otherwisse. So do I try to find a way of doing what Exchange can, and (in this case) they have a legitimate need for) or do I just tell them to go elsewhere and get a job as a toilet cleaner because we have no customers? ok, you say 'doing what exchange can' I assume you are referring to your problem with the switching IPs. How exactly does exchange handle that?
[qmailadmin] Re: possible feature additions
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
Re: [qmailadmin] Re: possible feature additions
I elided the wrong section of text at the top of my response. my last message should have started: At 04:49 PM 10/29/2003, Paul Theodoropoulos wrote: At 04:12 PM 10/29/2003, Paul L. Allen wrote: Yep. But the problem here is not that they could be without mail for 24 hours but that for 24 hours somebody could end up sucking their mail down. Not just a breach of confidentiality but also the mail is permanently lost to them. Unlikely to happen, but not impossible. that's an inherent weakness simply of using dynamic addresses to host an MTA, you do realize? with a reasonably well crafted timing attack, one could present themselves as the IP the mail is to go to, and grab it all. but beyond the incorrect eliding, i'm arguing the same point mr allen is making. so it's a wash! Paul Theodoropoulos http://www.anastrophe.com
[qmailadmin] Re: possible feature additions
Hi Paul
Paul Theodoropoulos writes:
that's an inherent weakness simply of using dynamic addresses to host an
MTA, you do realize? with a reasonably well crafted timing attack, one
could present themselves as the IP the mail is to go to, and grab it all.
Ummm, please read my original post. I *know* this. With what qmail
offers, you are vulnerable for as long as your ADSL is down. With
ETRN or some equivalent, you are vulnerable for milliseconds. I would
prefer no window of vulnerability at all, but if there is one I would
prefer if last milliseconds rather than hours.
I expect somebody will now appear to tell me how bad
relay-after-pop is. Sorry, guys, I'm running in a commercial
environment where alla of our users are stupider than G W Bush's
toe-cheese. We have to offer relay-after-pop or lose the 90%
of our customers who are incapable of understanding SMTP AUTH,
that again is not evidence that qmail usage is growing or declining.
See comments of mine elsewhere.
{my PHD}
but again, that is not evidence that qmail usage is growing or declining.
My PHB knew DOS and Windows forwards and backwards, including disassembling
the OS for fun. He eventually got shafted by MS stupidity and swore he
would never develop for Windows again. Windows is now a little less
unreliable than it used to be. Qmail is way hehind Exchange. People
still think MS is wonderful. It cosrs a lost to install qmail plus
add-ons yet the toilet cleaner can install Exchange. My PHB keeps
suggesting we switch to Exchange. He knows the OS is crap. He knows
the MTA is crap. But it would give our customers what they think they
want cheaper (short term) than they would get with qmail.
All three directors of the company I work for are saying we should
use Exchange. All three know it is a broken pile of shit. All three
know it is what our customers want... Either qmail does what our
moronic customers want or it won't run here for much longer. :(
Ummm, can you offer me proof that hotmail IS using qmail still? Every
test I have done indicates it is not, although the qmail mirrors say it
is.
i didn't suggest i had proof.
Correct, you did not. But I suggested that I DID have proof (which
you could have rewquested and then disputed).
Ummm, provide your proof, please. Shit or get off the pot... And
you know from our other discussions that I respect you..
[hotmail seems no longer to use qmail
and you may very well be right - but it is not proof of your claim.
Nothing I have tried reveals anything I interpret as being qmail,
or a very hacked version thereof. You provide me with some intrinsic
response by hotmail that is identical to qmail and I might consider
your point of view. I am well aware of how easy it is to customize
some responses without even recompiling. I am well aware of how easy
it is to sustomize the other responses if you do recompile. I looked
deeper than the obvious responses.
I'm damned sure Gates would tell lies when it suited him. But this time
I do not have the proof to convict him.
you've expressed an opinion that you believe qmail is not growing in
usage. that's fine, and is your privilege. it is not a fact, however.
And do you have ANY proof that *relative* qmail usage is on the increase?
i haven't made a claim either that it's increasing or decreasing. you've
made a claim that it is decreasing, but you've offered no evidence to back
up the claim. that's all i'm pointing out.
It is quite probable that qmail usage is increasing, but not as fast as
other MTAs.
or it may be the other way around. with out proof, who knows?
You have attempted (and failoed) to invalidate the evidence
you've offered *NO* evidence.
I have avaliabe to me but not provided any of your own to back up your
position. I can be convinced - give me verifiable evidence and logical
reasoning and I will happily admit I was wrong.
you've offered speculation, not evidence. none. this is the empirical
method at work. provide evidence to back up your claims. *i've not claimed
a position*. *you have*. but you've offered no evidence. only speculation.
again, speculation is fine. so long as it is presented as same. claiming
that you have proof or evidence without providing any is not helpful.
Paul Theodoropoulos
http://www.anastrophe.com
--
Paul Allen
Softflare Support
[qmailadmin] Re: possible feature additions
Jeremy Kitchen writes: Damn it's 2:30 am here and I really do need to go to bed. Jeremy, rest assured that I have skimmed through your response and I will tear it to shreds when I have the time tomorrow. And believe, me Jeremy, I will kick the crap out of you (I'm drunk now, and in far too good a mood to attack people). BTW, Jeremy, you don't even come close to Tom Collins for technical understanding, innovation or honesty. Thank Fhuck that Tom wreested control from the fhuckwits at Inter 1.5. BTW, Jeremy, I am VERY pleasant and understanding when drunk, as I am now. Be prepared to have the crap kicked out of you tomorrow... -- Paul Allen Softflare Support
Re: [qmailadmin] Re: possible feature additions
let me boil all this down, since this is becoming a pointless
thrash.
you made the following statement:
And if it weren't for DJB's stubbornness, its usage might actually
be growing instead of steadily declining.
you've provided no evidence to support that statement.
either support the statement with evidence, or withdraw the claim.
simple.
again, i'm not particularly trying to badger you. but the fact is, you
are speculating that usage of qmail is declining. you have a hunch. you
have a gut feeling. you think so. you believe so.
that's dandy. but it's not proof.
and again, since i've made NO claim either way - reread the thread -
nowhere have i said usage of qmail is increasing or
usage of qmail is declining - , there's nothing for me to
support, or to provide evidence for. you made the claim. back it up, or
withdraw it.
anyway, this doesn't have fuckall to do with qmailadmin, so my
contribution to the thread ends here. hopefully there will be at least
one more response in the thread - that of the claim being
withdrawn, or evidence being offered to prove it.
At 06:26 PM 10/29/2003, Paul L. Allen wrote:
Hi Paul
Paul Theodoropoulos writes:
that again is not evidence that qmail usage is growing or
declining.
See comments of mine elsewhere.
{my PHD}
but again, that is not evidence that qmail usage is growing or
declining.
My PHB knew DOS and Windows forwards and backwards, including
disassembling
the OS for fun. He eventually got shafted by MS stupidity and
swore he
would never develop for Windows again. Windows is now a little
less
unreliable than it used to be. Qmail is way hehind
Exchange. People
Paul Theodoropoulos
http://www.anastrophe.com
[qmailadmin] Re: possible feature additions
Justin Hopper writes: FUNCTION: The ability to blackhole an email address, so that any email sent in to that address will be deleted. Useful when you don't want to bounce the message, but just want it to disappear. SOLUTION: First, changed the dropdown box of email users when adding a new alias to include a DELETE option. Selecting this option would create a dotqmail file with the following: | /usr/local/vpopmail/bin/vdelivermail '' delete Not sure if this is the best way to blackhole email, or if routing it to /dev/null is. I don't know what vdelivermail does, but the standard way of getting qmail itself to delete mail is to create .qmail-whatever containing just a # in it. An empty file is ignored, but one containing only a comment causes the mail to be discarded. However, this is rather crude compared to the flexibility of sqwebmail's filters which allow you to set conditions for when mail gets deleted. -- Paul Allen Softflare Support
Re: [qmailadmin] Re: possible feature additions
On Tue, 2003-10-28 at 05:25, Paul L. Allen wrote: Justin Hopper writes: FUNCTION: The ability to blackhole an email address, so that any email sent in to that address will be deleted. Useful when you don't want to bounce the message, but just want it to disappear. SOLUTION: First, changed the dropdown box of email users when adding a new alias to include a DELETE option. Selecting this option would create a dotqmail file with the following: | /usr/local/vpopmail/bin/vdelivermail '' delete Not sure if this is the best way to blackhole email, or if routing it to /dev/null is. I don't know what vdelivermail does, but the standard way of getting qmail itself to delete mail is to create .qmail-whatever containing just a # in it. An empty file is ignored, but one containing only a comment causes the mail to be discarded. However, this is rather crude compared to the flexibility of sqwebmail's filters which allow you to set conditions for when mail gets deleted. Ah yes, I had forgotten that qmail will dump email if it sees a # sign in a dotqmail file. I was never sure if this was a desired effect or not, so I've never used it. If this is the way it is supposed to work, then yes, I should change the text string to just a single '#' character, which would be all the easier to write and read back in to check for. Any other comments or ideas about these features? -- Justin Hopper [EMAIL PROTECTED]
[qmailadmin] Re: possible feature additions
Justin Hopper writes: Ah yes, I had forgotten that qmail will dump email if it sees a # sign in a dotqmail file. I was never sure if this was a desired effect or not, so I've never used it. According to the man page for dot-qmail, if the .qmail file is empty then it is ignored and defaultdelivery instructions are processed. It is too late (and I've had too much wine) for me to remember where I saw the tip about the #, but it was somewhere I considered trustworthy (trust is not transitive, so you should not believe me). But it does follow from djb's minimal, you have to be a guru to install qmail and I'm not going to explain it for you, shoot-yourself-in-the-foot and let Exchange win because it is easy to install and you have to be a masochist to install qmail, tendencies. IF the .qmail file is empty then it is ignored. That much djb states explicitly. Logically, if the .qmail file is NOT empty then it is NOT ignored. A .qmail file may contain various delivery instructions including comments. That much djb states explicitly. The logical conclusion is that a .qmail file containing just a comment is processed and causes mail to silently be discarded because there are not instructions which would result in a delivery. For any other application I would consider this to be undocumented behaviour which cannot be relied upon. For djb stuff, I consider that anything which can logically be deduced from the documentation is 99.999% certain to be intended, supported, and unchanging behaviour. One day, somebody ought to introduce djb to the Real World[tm]. The place where it takes an expensive admin a long time to figure all the qmail stuff out and where people can hire a cheap point-and-click monkey to install Exchange or even do it themselves. One where the raw features provided by qmail are so limited that neither ISPs nor customers are satisfied with what is available and one where Exchange is viewed by customers as the dog's bollocks (a UK phrase meaning something that is very good). The newer sqwebmail features such as filters go some way to redressing the balance, but they are effectively an extension to qmail by a different author. Qmail is secure and reliable while Eschange is an insecure, unreliable pile of steaming manure. But Exchange offers what people want (or think they want) and qmail is very restrictive. Djb would do well to read, and inwardly digest, Kernighan's Why Pascal is not my favourite language and Wall's comments about bondage and discipline languages. Sadly, qmail is a bondage and discipline MTA, and that is why its popularity is declinging FAST. Red Hat used to come with sendmail. Now it comes with postfix. Because of djb's copyyright conditions, Red Hat will NEVER come with qmail. In terms of security and reliability, qmail is better than either. In terms of out of the box install of your favourite distro, qmail just isn't in the running. Sigh, I'm ranting. And that's probably because months after I first started using qmail, I hit the problem that qmail passes mail around by sending the content on file descriptor 0 FIRST and the envelope headers on file descriptor 1 SECOND. In an SMTP transaction, the envelope headers come first. Logically, the envelope headers come first. In order to do filtering (like anti-virus, or spam filtering, or sender filtering, or recipient filtering) you WANT the envelope headers first. My conclusion is that djb DELIBERATELY did it the wrong way around to make it as hard as possible to add filters unless you are a guru. And for that, I hate his guts. I respect his coding skills. I respect his knowledge and understanding of mail RFCs. And I think he is a complete dickhead for his bondage and discipline attitude. I despise djb more than I do Nicklaus Wirth (hey, Nick, if I call you by value then I pronounce your name dickhead not worth) because Pascal is a crappy language in the first place and there are better alternatives) because if I want reliability and security then I have to use qmail and put on my bondage gear. Maybe djb got confused between BSD and BDSM and thought he needed handcuffs, chains and whips to write for BSD... If this is the way it is supposed to work, See above. I think that if it can be logically inferred from the minimalist documentation then that is how it is supposed to work. -- Paul Allen Softflare Support
