The problem with this arrangement is that unless you're serving up nothing but static pages (absolutely no CGI, PHP, mod_perl, or other types of programs running whatsoever), it's trivial to get at someone else's stuff. Unless you run processes with suexec, anyone could write a PHP or Perl script to cd../other_user_dir and walk the tree. This works because without suexec, every single script and process forked on a user's behalf runs as the Apache user.
Of course, Apache itself has to have access to everyone's stuff, else it can't serve them up.
Also, unless properly configured, even with only static pages, you're still vulnerable to things like http://yoursite.com/~username/../other-user and so on.
Not true. The OS lives in the 16MB (or 32MB on newer models) of flash ROM. The iPaq itself is a barebones Strongarm 206MHz CPU with 64MB of RAM, a touch screen and a few buttons for input, an LCD and speaker and LED for output, a serial and USB port, and a bus for expansion devices.
It'll run whatever you can shove on it and get to run on the Strongarm.
I disagree. Everyone should be allowed to poke around with the kernel, even change stuff in the source.
Everyone else should have the same opportunities to shoot themselves in the feet as I have:)
What needs to be available is a nice easy to deal with boot loader that helps folks boot from their old working kernel when they screw up a recompile. GRUB and LILO can already be configured to do this; we need do nothing else than show people how to use those. I suggest GRUB (it's lovely in general), because it doesn't need to be installed again every time the kernel is upgraded.
Shooting one's self in the foot is a vital step in any learning exercise. When a person is so afraid of something that s/he won't even try it, they're in a lot of trouble.
I stand partially corrected. I dug around some more and found a patch for 2.4.17 to add packet writing. Nevermind that it doesn't work:) But hey, at least patches exist:
Ah, yes, that old favorite answer. Unfortunately, it's true in this case.
Some points of note:
Out-of-the-box cdrecord does not write DVD-R(W) discs. You have to pay for the author's "cdrecord-prodvd" release or apply the free patches I found at
http://www.abcpages.com/~mache/cdrecord-dvd.html.
While DVD-RAM fares better than DVD-RW in Linux (DVD-RAM doesn't need that damned packet writing stuff that the gang at http://packet-cd.sourceforge.net/
haven't updated since 2.4.7-ish), it still has
plenty of problems. If you hit a media error, kiss
your session goodbye and prepare to reboot.
And despite much marketing efforts to the contrary, DVD-RAM discs aren't readable by anything I've been able to throw them at.
Whether you're using the "official" DVD version of cdrecord (the test version, at least, limited to -dummy mode or 1GB images) or the one
based on the free patch, if you hand the Pioneer DVD-A03 "cheap" DVD-RW media, it always seems to give up. Sadly, Nero Burning ROM in 'doze writes to the same pieces of media just fine. This stings to admit, since I'm quite the Linux junkie:)
You can forget about packet writing if you're using a DVD-RW drive, unless someone out there has updates (or something better to use) than the packet-cd project at Sourceforge. The patches there won't even apply to kernels newer than 2.4.12 (according to the mailing list), and even then it's still unfriendly and unreliable.
I would love it if someone could disprove any of the above; I have a QPS (Que!) external Firewire drive (the Pioneer DVD-A03 stuffed into a firewire enclosure) that I really wish was more reliable in Linux than it is right now. Packet writing would be lovely. As it stands now, I can write DVD-Rs okay with the free patched cdrecord, but the only DVD-RW media that's writable in Linux seems to be the one that shipped with the drive. Nothing else has worked:(
Okay, I know it's socially popular now to bash/. for, well, slashdotting sites, but really, is it seriously/.'s job to check that any site it dares link to has lots of bandwidth?
Shouldn't a company as big and popular as iD have bigger servers anyway? Isn't it their responsibility to ensure they've got the capacity to dispense their product to everyone who wants it? Shouldn't they be in charge of distributing it to mirrors first if they don't think they can hack it?
What about other news sites? Should Blue's News not post links to this file? It's a Quake news site, so it seems appropriate.
Quitcher whining, get a decent proggie (like wget) that can try a site every few minutes and auto-resume downloads, and wait in line like everyone else.
Yup. 'Tis the beauty of the freedoms Linux presents; developers have the choice of whether to release source or binary-only products and which archs to support in binary releases, and users have the choice whether to make use of such software.
Where I used to work, a system was put in place (closed-source, Windows only, required a special client to access that was also Windows only) that didn't serve anyone's needs but was the "pet favorite" of the management staff who either got kickbacks for using and pushing the product or just ignored the input of all their employees and went with their first choice for egotistical or idiocy purposes.
Hearing the constant complaints, I (the senior sysadmin), installed Bugzilla. Despite its ugly query form, people loved it and immediately began using it.
Management took interest in it and immediately started complaining about it. Every piece of FUD that's ever been used against an open-source product was thrown at it. It turned personal; the managers of one of the groups actually *ordered* her employees not to use Bugzilla.
I redesigned the look of the tool (it took a day of work to completely redesign all the forms, report pages, and search pages), and more people started using it after the changes because it became easy to use. I enabled the e-mail feature (to e-mail updates and new bugs to the system).
It kicked ass, did everything the management wanted it to do, and it cost much less.
The layoff rounds that hit the company last month didn't spare me; I'm sure my involvement in getting Bugzilla rolled out played some role in their decision to lay off the only system administrator they had in the office (whoops:). When I left, the system Bugzilla was meant to replace was still in operation (servers still running, etc.).
Not one trouble ticket has been created in that old system for almost a year; from what people have told me since I left, that hasn't changed.
Bugzilla also sits in a state of disuse; it turns out the "battle" between the Bugzilla "fans" (and its maintainer/evangelist:) and the management was so annoying to everyone, that the entire office chose to give up trying to track problems altogether rather than having anyone admit they're wrong.
I really hate corporate politics; it kills good products.
And, btw, if you don't like how Bugzilla looks, go change it. You're spot on about this; the fact that it's free and open-sourced doesn't mean somebody on the development team is going to spend a day/week/month customizing it to your exact specifications.
It's HTML, for fsck's sake; it's not that hard to change. And I made some pretty drastic changes to Bugzilla's appearance. It didn't take very long.
The concept is made all the more exciting when applied to the Warcraft setting--one of the richest settings ever made for a computer game.
What the hell are they talking about? Warcraft and Warcraft II were brilliant games, but what storyline and immersive world are these guys thinking of?
The "story" of Warcraft (and Warcraft II) was dead simple: somebody ripped the fabric o' the universe a new one and orcs poured out from the hole eager to kick human ass. Now it's up to these humans to kick orcish ass before the orcs can kick human ass. Either the humans seal the hole, or the orcs kill the humans.
Sorry, didn't you see the sign? "It's funny. Laugh.":)
Re:Bad, but getting better.
on
Hotmail Hacked
·
· Score: 1
It's indeed a good sign they finally give a nod to those who find holes in their products, but are they actually doing anything to foster those efforts? Is Microsoft standing up against the DMCA which technically makes even looking for these kinds of holes illegal? Are they offering rewards for the holes people find? Are they opening up their source to people who've proven they know their stuff and could likely help them find and close more holes?
Until they start actually doing something to encourage folks with more than a quick nod, it doesn't really improve their image much:)
Agreed. And in this case, it's actually possible to boycott them without sawing off one's own nose to spite one's face:)
AMD have consistently made cheaper products than Intel, and for the past few years, they've made better products than Intel as well. When you can buy a CPU that performs better than Intel's offerings and costs less, it's hard not to boycott Intel.
I've owned AMD-based PCs and I've seen plenty of benchmarks. I know benchmarks get skewed in whichever direction the reviewer wants them to go, but my own experience tells me the K7 (Athlon, if you insist on brand names:) is faster clock-for-clock than Intel's best, and it's always cheaper.
Re:What to do? COUNTERSUE FOR WRONGFUL ARREST!
on
Adobe Backs Down
·
· Score: 1
No, that's called "double jeopardy." You can't be prosecuted twice for the same crime. Fortunately, as broken as our legal system is, there is protection from that type of insanity at least.
The funniest part about the Solaris 8 install media (at least on SPARC; haven't messed with x86) is how you can completely skip the "installation" CD entirely, booting off Software 1 of 2 to fire off a more decent (but still irritating) GUI installer, or if you just run it over a serial console, you can burn through the text-only installer.
I still amuse myself being able to install a Solaris 8 system from scratch with that trick faster than my coworkers who use the "pretty" installer.
No, I'm not making him out to be a monster. I'm pointing out that his behavior towards the uninitiated is an important factor in deciding whether to try qmail or not.
I agree that mailing lists aren't the best place for newbie questions, but I detest those who are completely intolerant of idiotic questions. I'm the senior system administrator at my office, and I get my share of stupid questions from people. My first response isn't to just blast the questioner for daring not to know some little detail, or even overlooking instructions clearly given about how to accomplish what they're trying to do (it's my second response;).
A mailing list is no different. If you get the same question asked over and over, stick it in a FAQ. Then when it's asked again, politely refer the questioner to the FAQ. You don't abuse somebody just because they don't know the answers you have. You lose users that way, and foster plenty of negativity towards the product.
I've had my share of frustration with users. I've been sorely tempted to blast the morons out of my lowly cubicle with a scalding assault on their brainpower and family heritage. Guess what? I hold back. In the case of work, I know better than to blow up at somebody; it's an excuse for them to complain, an excuse for my boss to write me up, and a reason for the office culture to shift enough that my skills & experience aren't sought anymore. In the free software world, all you've got is the support of your users. Alienate them, and you're toast.
By the way, cool lcd project...worthless but cool.
Obviously the most subjective part of this whole discussion is the behavior of the author(s) involved. That's something each individual administrator has to decide on. I don't quite feel comfortable putting my mail system in the hands of someone who gets so riled up about his product. I get the impression he's perfectly willing to put his users unwittingly in the line of fire to prove his point. It's just my opinion; you'll undoubtedly feel the need to offer corrections to it, but my perception of qmail's author just brings to mind one of the Things I Will (not) Do when I am an Evil Overlord ("I will never utter the phrase 'what? How can this be? I'm invincible!!!' as it will almost certainly be immediately followed by my horrific destruction").
Yes, I've heard of this "root hole in POP3 or IMAP" concept before. Funny thing is I don't recall any particular MTA being the cause. A qmail system is just as vulnerable to such exploits as a postfix system is when the actual exploit involves Cyrus IMAP, for example. Both MTAs will happily sit there and do absolutely nothing, since accessing one's mail once it's been delivered is a task neither MTA cares about.
Let's go over your other points.
I counter that postfix is also quite good:
Easy configuration - read README (ships with postfix)
Easy administration - read README (ships with postfix)
Security - it's odd, but I don't see any entries in the vulnerability database at Security Focus (bugtraq) for postfix either. I never suggested postfix was inpenetrable or flawless; my counterpoint here is that just because nobody's found and publicly complained about an exploit in qmail doesn't mean one doesn't exist. Organizations and authors, big and small, have walked away red-faced from such assumptions many times. I find it a bit worrying that qmail's author is so cocky about his product. Whether that concern is unfounded or valid isn't your place to decide. It's every single person's choice when they're deciding whether to install a particular system or not. It seems both postfix and qmail have had their share of problems, and those get fixed and updates are released to give those fixes to the world. Where's the problem with either system on this count?
Fast - Yup, I've heard about qmail running on Hotmail and/or the other big free web sites. I also can't shake my read of the comparison you referenced that throws that "three times faster than qmail" figure around. Yes, they discuss that they can't duplicate the performance, but that it's still faster than qmail. This comparison doesn't matter too much anyway; qmail and postfix both scream, and they've both met the goals they set out to achieve -- they're faster than sendmail. That's been widely acknowledged by everyone involved.
Great support - postfix is remarkably well documented and has plenty of FAQs and examples around. Your qualifier for qmail's support implies that if you dare ask a newbie question, you're going to be given yet another reason why you shouldn't have chosen qmail in the first place. I can't stand elitism; it especially has no place with a product such as an MTA. As the author of an MTA, it's in your best interest to tolerate newbies, and guide them to configuring your MTA properly so your product isn't helping to putting yet another badly behaved, misconfigured server on the internet.
Maildir - drat, typos in the wrong place. I did mean "maildir" instead of "mailbox". Postfix supports maildir as well. I am well aware of its NFS-friendly design, and it is quite a good one.
I am afforded an equal amount of good sleep by postfix; hasn't flaked on me yet, and I don't expect it to.
We're comparing very similar systems here. They're both setting out to do the same things, and it looks to me like they're both accomplishing what they've set out to accomplish. Bickering over each system's choice of implementation is a waste of time. If an implementation proves inappropriate, it will over time be fixed or abandoned.
Holy wars suck anyway; perhaps your time would be better spent away from embarking on one here. If you're game for an attempt at an objective discussion of the merits of the individual systems, then great, I'll carry one on as well. But if we're going to jump into a nasty flamewar (that the qmail & postfix communities have seen far too many of anyway), I'll respectully bow out here.
Most of these links seem to rather argue with your assertion that the best is qmail. First we've got a somewhat biased comparison (the "Life with qmail" document is probably not the best source for honest comparison) that still doesn't really claim one being better than the others.
Next up we've got another MTA comparison that claims postfix is nearly three times faster than qmail. Heh. Whoops.
Then we've a comparison between mbox (standard Unix mailbox format) and mailbox, qmail's format. This is a nice comparison, but doesn't help the argument much since postfix groks the mailbox format as well.
Finally we've a complaint from the author of qmail about how postfix handles the mail spool. Of course qmail's author's behavior is, unfortunately, a factor you must consider when choosing which MTA you want to use. There's a bit too much attitude there for my taste. I've never liked dealing with authors (or products) who have to prop up their work by tearing down others. It's one thing to say "I think my tool is the best" and quite another to say "My tool is the best because the others suck."
Additionally, the gaping hole described can be closed by runtime configuration. You don't have to run with world-writable mailboxes. It's also worth noting that if you're running a "closed" mail system (where users never log in directly to check their mail, but instead use IMAP or POP3), it's not a security risk at all (since only root or other privileged (and hopefully trusted) users would be granted access in the first place).
True. Many of the features are overkill. However, that postfix makes those features available (many not enabled by default; only the no-relaying feature is enabled out-of-the-box) and very easy to configure was the point of my post.
If you turn on absolutely every feature on the list, you're going to have a very unfriendly mail server. Some admins think that's a good thing (I'm one of them, although I tend not to implement the more draconian features:), since a misconfigured mail server has no business being on the internet, and calling attention to that misconfiguration by refusing to service it until it's fixed is a great way to get things fixed eventually.
The surest way to properly nuke spam is to set up aggressive procmail filters *and* use a mail server that's unfriendly. Certainly, refusing mail from known spamming domains and relays is acceptable, and quite effective. You let the mail server deal with known spammers, and your procmail deal with whatever slips through the cracks.
It can't be fully automated. It's just impossible. However, by letting the mail server deal with the grunt work (you don't really want to try to make procmail handle the RBL stuff, do you? Okay, fine, many of us more geeky types are quite willing to do that, but still, the argument is reasonably valid:), you can focus on the more incidious spammers and work aggressively to shut them down. You can better spend your time if your mail server is helping, even a little, in keeping spam out of your inbox.
Part II is a detailed section that is the heart of the book. How to set up Postfix is laid out in detail from how to install (both from an RPM file and from source), to configuring it, to logging and blocking UCE/UBE.
Devoting an entire chapter of a book to blocking spam sounds like a nice idea, but one of the many things postfix gets right is its ability to effectively and easily block spam for you. With only a few configuration directives in/etc/postfix/main.cf, you can make postfix:
Reject inbound mail if it's coming from a known spammer, known relay, or known dialup IP addy (the blackhole, relays, and dialups lists at the RBL)
Reject inbound mail from any system that presents an invalid (i.e. not strictly DNS-compliant) hostname
Reject inbound mail from any system whose IP address cannot be resolved to a name
Reject "inbound" mail whose real destination is any domain that the postfix installation doesn't directly service (by delivering the mail itself or by relaying to a defined external system); this is a default feature, incidentally
Limit the number of recipients a single message can have
Limit the number of messages a single system can send to the server over a specific duration
Limit (or completely inhibit) clients' ability to use the VRFY command to harvest addresses
I bet there's more that I've forgotten about (or not discovered yet). Every single item in this list can be implemented with one directive in/etc/postfix/main.cf; postfix is very easy in this regard.
I would think, given postfix's very easy means of setting all this stuff up (and the in-depth documentation that it ships with), that it would be a waste to devote more than a few pages to spam blocking when discussing this mail system. It won't relay by default (so there goes the most commonly used gaping hole for spammers right there), and by turning on features that limit DoS-type attacks and spamming runs, you catch all the clueless spammers. By including the RBL, you catch the more sophisticated ones. Sure, spam's gonna get through no matter what you do, but it won't be postfix's fault.
This book looks to be a clear, concise discussion of postfix's other, more interesting features. I'm glad to see a whole section devoted to getting postfix working with OpenLDAP, for example. Honestly, I think that sort of thing is more important than spam catching in the first place; sure, a user might have to delete a few spams if you haven't spent all the time you should on spam catching, but you might well have more free time if you manage to integrate all your authentication and account management into an LDAP directory that postfix can directly use for its users and configuration.
Just some random thoughts from a humble system administrator:)
Hope the Soul Player folks do it!
on
MP3Pro Released
·
· Score: 1
I just ordered a Soul Player; I've waited a long time for a good product to ship for a good price, and finally this beast is unleashed. I really hope they choose to add an Ogg decoder too; if they do so, they'll sell even more of these things! They've already released several firmware upgrades, each one adding new features to the player (I don't recall seeing any actual bug reports yet; very impressive). If I like it enough that I won't let my wife steal it away from me (she's getting good at stealing my toys, dammit:), we'll undoubtely by another one.
Slashdot Mirror
Hehehe yup, prepare to begin kicking :)
The problem with this arrangement is that unless you're serving up nothing but static pages (absolutely no CGI, PHP, mod_perl, or other types of programs running whatsoever), it's trivial to get at someone else's stuff. Unless you run processes with suexec, anyone could write a PHP or Perl script to cd ../other_user_dir and walk the tree. This works because without suexec, every single script and process forked on a user's behalf runs as the Apache user.
Of course, Apache itself has to have access to everyone's stuff, else it can't serve them up.
Also, unless properly configured, even with only static pages, you're still vulnerable to things like http://yoursite.com/~username/../other-user and so on.
Not true. The OS lives in the 16MB (or 32MB on newer models) of flash ROM. The iPaq itself is a barebones Strongarm 206MHz CPU with 64MB of RAM, a touch screen and a few buttons for input, an LCD and speaker and LED for output, a serial and USB port, and a bus for expansion devices.
It'll run whatever you can shove on it and get to run on the Strongarm.
Marriage is fun, satisfying, and painfully annoying all at the same time. Welcome to the most interesting experience of your life!
And most of all, CONGRATULATIONS!
I disagree. Everyone should be allowed to poke around with the kernel, even change stuff in the source.
Everyone else should have the same opportunities to shoot themselves in the feet as I have :)
What needs to be available is a nice easy to deal with boot loader that helps folks boot from their old working kernel when they screw up a recompile. GRUB and LILO can already be configured to do this; we need do nothing else than show people how to use those. I suggest GRUB (it's lovely in general), because it doesn't need to be installed again every time the kernel is upgraded.
Shooting one's self in the foot is a vital step in any learning exercise. When a person is so afraid of something that s/he won't even try it, they're in a lot of trouble.
*sigh*. Guess we can't ever talk about something more than once around these parts.
I stand partially corrected. I dug around some more and found a patch for 2.4.17 to add packet writing. Nevermind that it doesn't work :) But hey, at least patches exist:
http://w1.894.telia.com/~u89404340/patches/packetAh, yes, that old favorite answer. Unfortunately, it's true in this case.
Some points of note:
I would love it if someone could disprove any of the above; I have a QPS (Que!) external Firewire drive (the Pioneer DVD-A03 stuffed into a firewire enclosure) that I really wish was more reliable in Linux than it is right now. Packet writing would be lovely. As it stands now, I can write DVD-Rs okay with the free patched cdrecord, but the only DVD-RW media that's writable in Linux seems to be the one that shipped with the drive. Nothing else has worked :(
Or BeOS, FreeBSD, NetBSD, OpenBSD, MacOS, Solaris, AIX, HP-UX, Palm OS, Tru64 Unix, VMS, OS/360, etc.
It is unfair and unjust to create laws such that playing a piece of music on "unsanctioned" equipment/software is illegal.
Okay, I know it's socially popular now to bash /. for, well, slashdotting sites, but really, is it seriously /.'s job to check that any site it dares link to has lots of bandwidth?
Shouldn't a company as big and popular as iD have bigger servers anyway? Isn't it their responsibility to ensure they've got the capacity to dispense their product to everyone who wants it? Shouldn't they be in charge of distributing it to mirrors first if they don't think they can hack it?
What about other news sites? Should Blue's News not post links to this file? It's a Quake news site, so it seems appropriate.
Quitcher whining, get a decent proggie (like wget) that can try a site every few minutes and auto-resume downloads, and wait in line like everyone else.
Yup. 'Tis the beauty of the freedoms Linux presents; developers have the choice of whether to release source or binary-only products and which archs to support in binary releases, and users have the choice whether to make use of such software.
This is so true.
Where I used to work, a system was put in place (closed-source, Windows only, required a special client to access that was also Windows only) that didn't serve anyone's needs but was the "pet favorite" of the management staff who either got kickbacks for using and pushing the product or just ignored the input of all their employees and went with their first choice for egotistical or idiocy purposes.
Hearing the constant complaints, I (the senior sysadmin), installed Bugzilla. Despite its ugly query form, people loved it and immediately began using it.
Management took interest in it and immediately started complaining about it. Every piece of FUD that's ever been used against an open-source product was thrown at it. It turned personal; the managers of one of the groups actually *ordered* her employees not to use Bugzilla.
I redesigned the look of the tool (it took a day of work to completely redesign all the forms, report pages, and search pages), and more people started using it after the changes because it became easy to use. I enabled the e-mail feature (to e-mail updates and new bugs to the system).
It kicked ass, did everything the management wanted it to do, and it cost much less.
The layoff rounds that hit the company last month didn't spare me; I'm sure my involvement in getting Bugzilla rolled out played some role in their decision to lay off the only system administrator they had in the office (whoops :). When I left, the system Bugzilla was meant to replace was still in operation (servers still running, etc.).
Not one trouble ticket has been created in that old system for almost a year; from what people have told me since I left, that hasn't changed.
Bugzilla also sits in a state of disuse; it turns out the "battle" between the Bugzilla "fans" (and its maintainer/evangelist :) and the management was so annoying to everyone, that the entire office chose to give up trying to track problems altogether rather than having anyone admit they're wrong.
I really hate corporate politics; it kills good products.
And, btw, if you don't like how Bugzilla looks, go change it. You're spot on about this; the fact that it's free and open-sourced doesn't mean somebody on the development team is going to spend a day/week/month customizing it to your exact specifications.
It's HTML, for fsck's sake; it's not that hard to change. And I made some pretty drastic changes to Bugzilla's appearance. It didn't take very long.
The concept is made all the more exciting when applied to the Warcraft setting--one of the richest settings ever made for a computer game.
What the hell are they talking about? Warcraft and Warcraft II were brilliant games, but what storyline and immersive world are these guys thinking of?
The "story" of Warcraft (and Warcraft II) was dead simple: somebody ripped the fabric o' the universe a new one and orcs poured out from the hole eager to kick human ass. Now it's up to these humans to kick orcish ass before the orcs can kick human ass. Either the humans seal the hole, or the orcs kill the humans.
What immersive setting did I miss here?
Sorry, didn't you see the sign? "It's funny. Laugh." :)
It's indeed a good sign they finally give a nod to those who find holes in their products, but are they actually doing anything to foster those efforts? Is Microsoft standing up against the DMCA which technically makes even looking for these kinds of holes illegal? Are they offering rewards for the holes people find? Are they opening up their source to people who've proven they know their stuff and could likely help them find and close more holes?
Until they start actually doing something to encourage folks with more than a quick nod, it doesn't really improve their image much :)
Time to boycott Intel.
:)
:) is faster clock-for-clock than Intel's best, and it's always cheaper.
Agreed. And in this case, it's actually possible to boycott them without sawing off one's own nose to spite one's face
AMD have consistently made cheaper products than Intel, and for the past few years, they've made better products than Intel as well. When you can buy a CPU that performs better than Intel's offerings and costs less, it's hard not to boycott Intel.
I've owned AMD-based PCs and I've seen plenty of benchmarks. I know benchmarks get skewed in whichever direction the reviewer wants them to go, but my own experience tells me the K7 (Athlon, if you insist on brand names
No, that's called "double jeopardy." You can't be prosecuted twice for the same crime. Fortunately, as broken as our legal system is, there is protection from that type of insanity at least.
Neat! So qmail doesn't use libc? Nice hack. Too bad you're relying on one guy's coding skills to keep it all secure.
So you'd best secure it, buddy. This one is so astoundingly dense I don't know where to begin.
(Insert your poorly-reasoned, hate-filled "I'm better than all of you!" response here)
Hmmm. I thought "Aw shit!" or the even more critical "Oh fuck!" from an admin made the managers nervous :)
The funniest part about the Solaris 8 install media (at least on SPARC; haven't messed with x86) is how you can completely skip the "installation" CD entirely, booting off Software 1 of 2 to fire off a more decent (but still irritating) GUI installer, or if you just run it over a serial console, you can burn through the text-only installer.
I still amuse myself being able to install a Solaris 8 system from scratch with that trick faster than my coworkers who use the "pretty" installer.
No, I'm not making him out to be a monster. I'm pointing out that his behavior towards the uninitiated is an important factor in deciding whether to try qmail or not.
I agree that mailing lists aren't the best place for newbie questions, but I detest those who are completely intolerant of idiotic questions. I'm the senior system administrator at my office, and I get my share of stupid questions from people. My first response isn't to just blast the questioner for daring not to know some little detail, or even overlooking instructions clearly given about how to accomplish what they're trying to do (it's my second response ;).
A mailing list is no different. If you get the same question asked over and over, stick it in a FAQ. Then when it's asked again, politely refer the questioner to the FAQ. You don't abuse somebody just because they don't know the answers you have. You lose users that way, and foster plenty of negativity towards the product.
I've had my share of frustration with users. I've been sorely tempted to blast the morons out of my lowly cubicle with a scalding assault on their brainpower and family heritage. Guess what? I hold back. In the case of work, I know better than to blow up at somebody; it's an excuse for them to complain, an excuse for my boss to write me up, and a reason for the office culture to shift enough that my skills & experience aren't sought anymore. In the free software world, all you've got is the support of your users. Alienate them, and you're toast.
By the way, cool lcd project...worthless but cool.
Thanks! :)
Obviously the most subjective part of this whole discussion is the behavior of the author(s) involved. That's something each individual administrator has to decide on. I don't quite feel comfortable putting my mail system in the hands of someone who gets so riled up about his product. I get the impression he's perfectly willing to put his users unwittingly in the line of fire to prove his point. It's just my opinion; you'll undoubtedly feel the need to offer corrections to it, but my perception of qmail's author just brings to mind one of the Things I Will (not) Do when I am an Evil Overlord ("I will never utter the phrase 'what? How can this be? I'm invincible!!!' as it will almost certainly be immediately followed by my horrific destruction").
Yes, I've heard of this "root hole in POP3 or IMAP" concept before. Funny thing is I don't recall any particular MTA being the cause. A qmail system is just as vulnerable to such exploits as a postfix system is when the actual exploit involves Cyrus IMAP, for example. Both MTAs will happily sit there and do absolutely nothing, since accessing one's mail once it's been delivered is a task neither MTA cares about.
Let's go over your other points.
I counter that postfix is also quite good:I am afforded an equal amount of good sleep by postfix; hasn't flaked on me yet, and I don't expect it to.
We're comparing very similar systems here. They're both setting out to do the same things, and it looks to me like they're both accomplishing what they've set out to accomplish. Bickering over each system's choice of implementation is a waste of time. If an implementation proves inappropriate, it will over time be fixed or abandoned.
Holy wars suck anyway; perhaps your time would be better spent away from embarking on one here. If you're game for an attempt at an objective discussion of the merits of the individual systems, then great, I'll carry one on as well. But if we're going to jump into a nasty flamewar (that the qmail & postfix communities have seen far too many of anyway), I'll respectully bow out here.
[chomp] Mmmm... flamebait.
Most of these links seem to rather argue with your assertion that the best is qmail. First we've got a somewhat biased comparison (the "Life with qmail" document is probably not the best source for honest comparison) that still doesn't really claim one being better than the others.
Next up we've got another MTA comparison that claims postfix is nearly three times faster than qmail. Heh. Whoops.
Then we've a comparison between mbox (standard Unix mailbox format) and mailbox, qmail's format. This is a nice comparison, but doesn't help the argument much since postfix groks the mailbox format as well.
Finally we've a complaint from the author of qmail about how postfix handles the mail spool. Of course qmail's author's behavior is, unfortunately, a factor you must consider when choosing which MTA you want to use. There's a bit too much attitude there for my taste. I've never liked dealing with authors (or products) who have to prop up their work by tearing down others. It's one thing to say "I think my tool is the best" and quite another to say "My tool is the best because the others suck."
Additionally, the gaping hole described can be closed by runtime configuration. You don't have to run with world-writable mailboxes. It's also worth noting that if you're running a "closed" mail system (where users never log in directly to check their mail, but instead use IMAP or POP3), it's not a security risk at all (since only root or other privileged (and hopefully trusted) users would be granted access in the first place).
True. Many of the features are overkill. However, that postfix makes those features available (many not enabled by default; only the no-relaying feature is enabled out-of-the-box) and very easy to configure was the point of my post.
If you turn on absolutely every feature on the list, you're going to have a very unfriendly mail server. Some admins think that's a good thing (I'm one of them, although I tend not to implement the more draconian features :), since a misconfigured mail server has no business being on the internet, and calling attention to that misconfiguration by refusing to service it until it's fixed is a great way to get things fixed eventually.
The surest way to properly nuke spam is to set up aggressive procmail filters *and* use a mail server that's unfriendly. Certainly, refusing mail from known spamming domains and relays is acceptable, and quite effective. You let the mail server deal with known spammers, and your procmail deal with whatever slips through the cracks.
It can't be fully automated. It's just impossible. However, by letting the mail server deal with the grunt work (you don't really want to try to make procmail handle the RBL stuff, do you? Okay, fine, many of us more geeky types are quite willing to do that, but still, the argument is reasonably valid :), you can focus on the more incidious spammers and work aggressively to shut them down. You can better spend your time if your mail server is helping, even a little, in keeping spam out of your inbox.
Um:
Part II is a detailed section that is the heart of the book. How to set up Postfix is laid out in detail from how to install (both from an RPM file and from source), to configuring it, to logging and blocking UCE/UBE.
Devoting an entire chapter of a book to blocking spam sounds like a nice idea, but one of the many things postfix gets right is its ability to effectively and easily block spam for you. With only a few configuration directives in /etc/postfix/main.cf, you can make postfix:
I bet there's more that I've forgotten about (or not discovered yet). Every single item in this list can be implemented with one directive in /etc/postfix/main.cf; postfix is very easy in this regard.
I would think, given postfix's very easy means of setting all this stuff up (and the in-depth documentation that it ships with), that it would be a waste to devote more than a few pages to spam blocking when discussing this mail system. It won't relay by default (so there goes the most commonly used gaping hole for spammers right there), and by turning on features that limit DoS-type attacks and spamming runs, you catch all the clueless spammers. By including the RBL, you catch the more sophisticated ones. Sure, spam's gonna get through no matter what you do, but it won't be postfix's fault.
This book looks to be a clear, concise discussion of postfix's other, more interesting features. I'm glad to see a whole section devoted to getting postfix working with OpenLDAP, for example. Honestly, I think that sort of thing is more important than spam catching in the first place; sure, a user might have to delete a few spams if you haven't spent all the time you should on spam catching, but you might well have more free time if you manage to integrate all your authentication and account management into an LDAP directory that postfix can directly use for its users and configuration.
Just some random thoughts from a humble system administrator :)
I just ordered a Soul Player; I've waited a long time for a good product to ship for a good price, and finally this beast is unleashed. I really hope they choose to add an Ogg decoder too; if they do so, they'll sell even more of these things! They've already released several firmware upgrades, each one adding new features to the player (I don't recall seeing any actual bug reports yet; very impressive). If I like it enough that I won't let my wife steal it away from me (she's getting good at stealing my toys, dammit :), we'll undoubtely by another one.