On January 19, 2013, Michael Torrie wrote: I really wasn't looking to start another war, but perhaps this one won't evolve that far. One can only hope. As to your comments and questions...
> What issues did you have with Sendmail, other than it's horrid m4 config > system? I tend to think of Sendmail configs like perl scripts or C > socket code.. You never write one from scratch, but just tweak the one > you've been using for 20 years. I know a lot of people set store by sendmail in the enterprise world. In fact, when I was working for Stevens Henager college, their entire mail system was sendmail based with a database storage backend. Don't get me wrong. It does work. But besides the M4 setups (which really are bad), there's the fact that sendmail has one of the worst security histories I can recall seeing. I admit freely I haven't looked in nearly 15 years, but it seems to me that the list of security vulnerabilities that sendmail contributors have had to patch out is longer than I am tall (and I'm above average height). Do I claim that any of the alternatives have had no security patches? Nope, not unless you count absolutely plain jane Qmail. Then I can't say one way or the other. But I do say that the lists seemed a lot smaller, even adjusting for age. I think I've heard of milters, but I've certainly never used them, nor even really seen them, so I couldn't tell you anything good or bad about them. My knowledge of them is that they exist. Period. > Would not the multiple binaries approach have security advantages? > Nothing but the final delivery agent (say, procmail) needs to have > special privileges. Each binary does one ting and has only enough > privileges to do its thing before handing it off via IPC to another. Yes, and no. What you refer to (I think, and correct me GENTLY if I'm wrong on this, please) is the age old issue of how long should any daemon process spend existing as root. For Exim that's easy. It stays as root only as long as it needs to setup the listener (since non-root users can't bind ports <1024 I don't think) and setuid to a non-privileged user/group (usually mail:mail, but it's configurable during build time). It does ALL of it's work at that user, never going back to root. The mail queue is owned by the non-root user. As for delivery, it will setuid again to the uid/gid it needs to write to a user's mail store, then quit. If IT is actually doing the writing, it will do so, then that process terminates, leaving the main listener. All external delivery takes place as your non-superuser, since non-root users can originate outgoing connections on ports under 1024. Since all processes exist as either mail:mail (assuming that what you used) or as the specific user being delivered for, it's not a security risk. And, as I said, it's easier for me to understand, easier to follow, easier to debug, etc.... > And Sendmail also > has a mode for analyzing how and why it's doing the things based on email > address. Handy for debugging rules. Though it's most definitely not > plain english. Exim does the same type of thing, as I said, but does use plain english. In debug mode it examines each entry it's processing, and will write out the decisions it makes, as it makes them. Very handy. :) I will admit it's not debugging an address per se but the message as a whole, but the end result isn't much different if you have a message in the queue to that address already. I will admit that message examination parameter is handy though. I'd forgotten about that. Perhaps the Exim author can add something similar. :) > Most postfix users use amavisd, which works about like you describe. Yea, considering I specifically said I usually use amavisd-new, I'm not exactly surprised. :) The Amavisd program itself was good, but had a few issues. Amavisd-new works better, and it's what I'd likely use. I imagine by now most Postfix users use Amavisd-new too rather than classic Amavisd. > sendmail is no more or less secure against hackers than any other MTA. > I've not had any security issues with sendmail (keeping it updated as > security issues were found) in almost 15 years. One can argue that it's > architecture is monolithic and inherently less secure than Postfix. As to security patches, that's kind of my point. Back when I was actually comparing things, sendmail would have usually 2-3x the number of security alerts that Exim had. I admit I didn't look too closely at Postfix because I liked Exim, and I never considered Qmail because of all the patches you have to add to get it to do much. But that's what I referred to as less secure. I'll grant that if you've got a version that's fully, recently updated, then the security risk is much lower. But the odds just seem to be more in favor of finding a security hole in Sendmail than in Postfix or Exim, not that they don't each have security vulnerabilities of their own. Just fewer of them, to my view. As to architecture, perhaps the monolithic structure is a bit riskier. But it's also far easier for me to understand, and it's easier to debug (again, to me). I won't claim that the multi-binary architecture doesn't work too. It most certainly does, as evidenced by Qmail and later by Postfix. But I like the monolithic setup myself. Just easier for me to wrap my mind around. > Any MTA is vulnerable to spammers, at least those wanting to send spam > to you. That's why I always patch in sa-exim. It scans EVERY message for spam, even if it's to me. Messages exceeding the configured spam score from spamassassin are not delivered. I like that. :) --- Dan On Sat, Jan 18, 2014 at 11:30 PM, Michael Torrie <torr...@gmail.com> wrote: > On 01/18/2014 02:47 AM, Dan Egli wrote: > > It's primarily a personal preference. I personally started (like I'm sure > > most of us did) with Sendmail since that was what was included in my > Linux > > Distro (RedHat 8.0, before they dropped their free version). After > finding > > many issues with Sendmail, I looked for an alternative. When I found that > > XMission, who was (and I think still is) the biggest ISP in Utah was > using > > Exim on their mail servers, I decided I'd try it. I've used it ever > since. > > What issues did you have with Sendmail, other than it's horrid m4 config > system? I tend to think of Sendmail configs like perl scripts or C > socket code. You never write one from scratch, but just tweak the one > you've been using for 20 years. > > In my professional life, on enterprise mail systems, I've always stuck > with Sendmail because it was the most widely supported MTA and was an > enterprise standard (yes I understand Exchange is a "standard" too, and > used for similar reasons as I give. shudder, but that's enterprise for > you). > > Sendmail's one redeeming feature is that it has these pluggable filters > called "milters." If you run an enterprise mail server, milters can be > a powerful tool. I wrote one milter filter in Python once. Powerful > concept. > > In the years I've been using it professionally, it has not had any more > security issues than any other MTA, and I've never been compromised via > sendmail. > > Postfix now supports milters, though maybe not quite as fully as > sendmail yet. If milter support were exactly the same I'd definitely > take Postfix just for ease of configuring. > > > As to why I don't use PostFix or Qmail, they have the same problem (to me > > it's a problem, not to others). They split functionality off into > multiple > > binaries. So you have the listener binary that will in turn spawn off a > > recipient binary when incoming connections occur. And it spins off a > queue > > manager binary when it runs through it's queue. That binary in turn > splits > > off another binary that actually tries to deliver the message. While this > > approach obviously works, I prefer the one binary method. Exim does that. > > Would not the multiple binaries approach have security advantages? > Nothing but the final delivery agent (say, procmail) needs to have > special privileges. Each binary does one thing and has only enough > privileges to do its thing before handing it off via IPC to another. > > > > Qmail ... > > > > I won't even consider starting a flame war by saying Exim is better than > > any other MTA (except for Sendmail and I don't think anyone will argue in > > sendmail's favor), but it's better _for me_ than any other MTA. I also > like > > the ability of Exim to run in debug mode. If you want to watch and see > why > > it's making a decision it is, you can run it in debug mode (exim -d) and > > watch it go through all it's decision tree, spitting the logic out to > > stdout in nice, plain english. That makes it VERY easy to diagnose > issues. > > I'll argue in sendmail's favor (see milters above). And Sendmail also > has a mode for analyzing how and why it's doing things based on email > address. Handy for debugging rules. Though it's most definitely not > plain english! > > > I've yet to see any similar programs for PostFix or Qmail, but I'm not > > exactly looking. I settled on Exim and liked it, so I left it there. :) > > Most postfix users use Amavisd, which works about like you describe. > And you can do things like graylisting with postfix easily as well. > > > As to security, any properly configured MTA is secure against spammers. > And > > except for sendmail, most are fairly secure against hackers. > > sendmail is no more or less secure against hackers than any other MTA. > I've not had any security issues with sendmail (keeping it updated as > security issues were found) in almost 15 years. One can argue that it's > architecture being monolithic is inherently less secure than Postfix. > > Any MTA is vulnerable to spammers, at least those wanting to send spam > to you. > > > It looses some > > of that security (not enough to become unacceptable, though) when you > > include database patches or Mbox patches or SMTP Authentication patches > and > > what not. > > Yes this is the biggest drawback to Qmail. To make Qmail do anything > useful you have to patch it with patch collections to add features you > need. This seems to be rather fragile to me, and despite the famous, > long-standing bug bounty the author offers, I'm never sure of Qmail's > actual security. > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
