Postfix: A Secure and Easy-to-Use MTA

BSD Forums writes "On March 3rd, 2003, Internet Security Systems, in cooperation with the Department of Homeland Security, issued a warning regarding a hole found in Sendmail. The warning, echoed by CERT, warned system admins that any version lower than 8.12.8 was vulnerable to a serious root exploit. Sendmail has a long history of security holes, most of which have been thoroughly documented on security sites. While Sendmail runs half the mail servers in the world, there are smaller and easier-to-use mail transfer agents (MTAs). Network administrator Glenn Graham demonstrates how Postfix gives you most of the power with a fraction of the pain."

Comments

heh.

[bangel]

the department of homeland security is issuing security advisories now? did anyone know we're paying them to audit code?

I wonder if they'll start trolling on bugtraq.

-blak

Re:heh.

[capt.Hij]

the department of homeland security is issuing security advisories now?

Do they do anything else?

Re:heh.

[rf0]

I would just wait for the code they submit which introduces back doors. Nah that wouldn't happen would it?

Rus

Re:heh.

[grendel_x86]

Yes, they do, like spreading FUD, unnecessary panic, and wasting a crap-load of $$.

Re:heh.

[autechre]

Is this the same Department of Homeland Security that recently signed a contract with Microsoft to provide their software? And they're complaining about Sendmail?

http://slashdot.org/article.pl?sid=03/07/16/1634 25 0&mode=thread&tid=103&tid=99

On the other hand, maybe they'll train their sights on BIND next.

Re:heh.

[clckwrkMalChick]

yeap, and it's the same homeland security that after buying that issued this warning. I suppose I should be glad they're looking out, because you and I both know that the terrorists might come into the country next through the finger exploit.

Milters?

[itsjpr]

Does postfix have milters? Sendmail is popular for a reason.

Re:Milters?

[CoolVibe]

No, postfix has no milters. A shame really, since milter is a nice way to control how your mail flows (and to filter/reject/bounce when needed).

Milter is one of the things that's keeping me with sendmail.

Re:Milters?

[Anonymous Coward]

Milters being a means of adding a content filter to your MTA the answer is yes.

You can plug a content filter into your SMTP processes very easily under Postfix.

I have run large (ISP) sendmail installations for many tens of thousands of domains under both sendmail and postfix.

I now use postfix exclusively and would not revert to sendmail.

There are features in postfix that sendmail lacks in such an environment rather than the other way around.

Re:Milters?

[Anonymous Coward]

content_filter is the equivalent of Milter for Postfix.

This is quite powerful. For example, you can have some regular expression (around header or body), that sent to the content_filter.

If you want to switch and have milter in mind, please consult the documentation about content_filter...

Re:Milters?

[cloudmaster]

Yes, postfix has mail filters. They're just not *called* "milters", and they're readable by people who don't have M4 parsers built into their reading glasses. Grumble grumble crummy sendmail configuration grumble.

In fact, most of the things you can do with sendmail through external additions are already in postfix. I'm pretty sure that Postfix is also overall "faster" than Sendmail, and it upgrades easier, and the config system is useful, etc...

Re:Milters?

[aled]

Then postfix hasn't "milters" :-)

Re:Milters?

[Anonymous Coward]

No one will answer you.... it would be sacreligious to admit that exchange server works, and works quite well..... you see around these parts we have what we call the "double standard" it means that I can complain about Microsoft because I did not bother to update my machine and I got hit by Blaster. I can complain about Microsoft because I have to update, but I can not complain about having to patch sendmail for the same reason.

Re:Milters?

[dipipanone]

No one will answer you....

Probably because nobody can be bothered to respond to such an imbecilic remark. Sendmail and postfix are Mail Transport Agents, not Groupware. If you wanted to compare Exchange with a Linux equivalent, then there have been umpteen threads here in the past on the topic. This one, for example. Personally, I like this one but it isn't free. (At least not free as in beer. It's built on top of similar software to the free ones though.)

But do go on comparing apples with oranges if you wish. It doesn't hurt anyone, and it gives many of us a sense of smug superiority.

I can not complain about having to patch sendmail for the same

I'm so sorry, but you seem to be reading an imaginary slashdot thread in your own head, as opposed to this one, which is about the security holes in Sendmail and how using Postfix may be a better approach because of what a pain it is to keep it updated?

Perhaps you'd like to share your imaginary one with the rest of us and entertain us all some more?

Re:Milters?

[r7]

>exchange server works, and works quite well

Thanks to the Microsoft marketing department for that fact-free opinion. Trouble is it is inaccurate.

Exchange requires many times more systems administration hours per user or server than Postfix (or qmail/exim/sendmail). Exchange crashes far more often, and is the single most frequently exploited (virused/trojaned) MTA-capable software available.

Ah but "it does calendaring" I hear you saying, and "groupware", though not nearly as well as dedicated calendaring and groupware software. Leave it to MS marketing to call a sow's ear a silk purse...

R7

Re:Milters?

[Anonymous Coward]

The one thing I can't seem to find anyone whos uscceeded in doing is addng Habeas Headers to outgoing mail. Fairly straight-forward in sendmail.

Exim

[Anonymous Coward]

Exim seems to be quite popular at ISP's recently.

Or try qmail - unbroken since v1.03 (1998)

[KeithH]

Qmail is rock-solid. The best proof I can offer is that fact that no security flaw has been found since 1.03 was released in 1998. The man is a cryptographer and designed it for security.

There is also an enormous amount of support for the product available. Check out qmail.org and cr.yp.to/qmail.html

Re:Or try qmail - unbroken since v1.03 (1998)

[satch89450]

Qmail is rock-solid. The best proof I can offer is that fact that no security flaw has been found since 1.03 was released in 1998. The man is a cryptographer and designed it for security.

I run a number of qmail instances as part of my job, and while it may remain unbroken from a compromise viewpoint, it can get suffer from denial-of-service problems by bogging down to the point that the mail queue has to be cleared and the daemon restarted for the thing to run

I've never had this problem with PostFix.

I stopped running SendMail a long time ago, so I can't comment on that package's behavior first-hand when presented with a crushing load.

Re:Or try qmail - unbroken since v1.03 (1998)

[semanticgap]

I've run qmail on my machine for almost a year. In the end I ended up switching back to sendmail - while it may be "unbroken", qmail is cumbersome to use and lacks many important features of sendmail.

Re:Or try qmail - unbroken since v1.03 (1998)

[The Original Yama]

Want an idea of how secure qmail is? Take a look at the The qmail Security Challenge.

Re:Or try qmail - unbroken since v1.03 (1998)

[KeithH]

What can you do with sendmail that you can't to with qmail? There is a a very large set of mature additions and patches to qmail that permit just about anything you may wish to undertake with your mail server.

On the point of qmail being cumbersome: I disagree - what could be simpler than adding a single line to your rcpthosts file? Maintaining qmail is trivial. However, I'll agree that the author's terse documentation makes it seem quite foreign but compared to sendmail it is positively didactic. There are also many other resources available which supplement the original docs.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

I've considered qmail a few times, but Dan is such an abrasive prick that I just couldn't bring myself to use his software (the same can be said of Theo and OpenBSD). Check back through the qmail archives for some of his abusive responses to participants in the various qmail lists. Wietse, on the other hand, is easy to get along with, fixes things in a timely manner and operates in a much more respectful manner. Postfix is simple, secure, and well supported. Also, it doesn't require that you install all the author's other tools in order to have a functioning MTA.

Re:Or try qmail - unbroken since v1.03 (1998)

[mnmn]

There are two main things about qmail that gives it the edge.

1) It is a collection of small daemons. In the UNIX spirit. This cuts on the bugs and allows injection of emails into various stages, and developing addons much easier.

2) It has a structured config file system. Again thats truly like UNIX. You just go to one file, open it in an editor, usually has less than a screenfull of lines, edit it, close and reHUP the daemon. Imagine the same for sendmail. At the least you have to run make for it.

To be fair, I havent tried postfix, but after qmail, Ive kinda lost motivation to try anything else.

Re:Or try qmail - unbroken since v1.03 (1998)

[The Original Yama]

qmail is supposedly very secure in its default state. Aren't you compromising that security when you add third-party patches? I would think that these patches, since they are not part of qmail proper, have received nowhere near the scrutiny that sendmail (or postfix, exim, etc.) have received. Doesn't that defeat the main reason for using qmail?

Re:Or try qmail - unbroken since v1.03 (1998)

[Lussarn]

More info is definetely needed before +5 interesting. Which OS, Filesystem, mountoptions and queue disk setup did you use for qmail to act like this.

I've had qmail experience the behavior you are talking about using Solaris/ufs/noasync (single scsi disk) but using ext3/async,noatime (single scsi) under Linux X86 has proven to be very nice.

Reiser would probably do a good job here too.

Setting up mailservers is more science then just telling what sucks and what does not.

Re:Or try qmail - unbroken since v1.03 (1998)

[KeithH]

The DoS problem doesn't lie with qmail itself. That particular issue is best addressed through thresholding which is supported by ucspi-tcp's tcpserver (a replacement for inetd or xinetd).

If you are using ucspi-tcp already, then it is probably as simple as modifying the contents of /var/qmail/control/concurrencyincoming.

ucspi-tcp is not *required* but much of the qmail documentation assumes that you are using it. ucspi-tcp is also written by Dan Berstein (cr.yp.to/ucspi-tcp.html)

Re:Or try qmail - unbroken since v1.03 (1998)

[KeithH]

That's a good point and one that should be considered whenever one patches the source. However some of the patches are trivial and "obviously" safe while others are additions that don't actually require changes to the qmail source itself.

Because of qmail's design, it is very resistent to compromise, even if one of the components is modified.

I believe that the strict partitioning of function in qmail lends itself better to extension than a constantly evolving package such as sendmail.

I'm not in a position to compare it to Postfix.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

Having used both qmail and postfix, I'd say that both are considerably faster, far more solid and easier to configure than sendmail.

Personally, I somewhat prefer postfix.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

That is the reason I use qmail. The qmail list doesn't have the "I haven't RTFM" idiots posting and getting answers to the same questions day in day out like the postfix list. People like that deserve to get picked on. qmail was so easy to install, if you have problems then you only have yourself to blame for not planning and researching what you are doing first.

Postfix, on the other hand, suffers from the windows design pardigim. One big package to do it all. Very poor design choise this Wietse guy has made. Even just recently there was a remote DOS in some versions of postfix.

http://marc.theaimsgroup.com/?l=bugtraq&m=106001 52 5130257&w=2

Even Wietse doesn't trust his own software.
http://marc.theaimsgroup.com/?l=bugtraq &m=10601867 7502632&w=2
At least DJB does.

qmail is by far the easiest SMTP server to setup on *nix. It makes sense in its configuration and is well documented and stable. Postfix on the other hand is still underdevelopment, suffers from a poor design, and probably will include the kitchen sink by next year.

Re:Or try qmail - unbroken since v1.03 (1998)

[ajs]

This is exactly the problem with the OpenBSD, qmail (and the rest of DJB's software) and any other system that claims security through simplicity, but then refuses to either add features or accept code changes for the feature set that is needed in the real world. I respect this software, as I respect all functioning software that is contributed to the community (though qmail is contributed with some heavy provisos on what you are allowed to do in terms of modification and distribution).

However, you get the "unsupported majority" who run a modified/patched/extended version that might well have security flaws that no one knows about. Worse, when an exploit is found in one of those changes, the maintainer of the central package usually makes a point of saying, "look, see! My software was secure, it was just those icky add-ons that were broken!" (as OpenBSD did with apache).

Bottom line: if you run OpenBSD or qmail or any other like service, don't patch it, or add unsupported features.

If that's not a good enough feature-set for you, choose a platform that embraces the feature-set that you need.

Now, on to the myths of sendmail:

Recent sendmail holes have been found because careful security auditing by programmers who have no goal other than to find such problems is being PAID for on sendmail. Companies like Red Hat have found such bugs in the Linux kernel, sendmail, apache, samba, etc, etc because they are looking for them, fixing them, and patching their user-base proactively.

I'm not saying that this is a first. Many companies that can afford it perform such audits, and it's still not as helpful, IMHO, as the benefit of being open source in the first place. However, saying that software is "insecure" because paid auditors have discovered and fixed the problems is... questionable.

I like sendmail. It has its quirks and problems, but I've yet to see a replacement that doesn't insist on proving that it's "better than sendmail" by imposing some strange restriction on the users (e.g. exim's B&D approach to RFC-compliance; postfix's convoluted incoming vs outgoing filtering; qmail's B&D approach to software distribution).

I like these other packages too, but I don't see a role for them as-is in my environments. Perhaps someday someone will write a simple sendmail replacement that is feature-for-feature compatible, but simply has simpler code and a more straight-forward config syntax (the only two real failings of sendmail).

Re:Or try qmail - unbroken since v1.03 (1998)

[gfilion]

qmail is supposedly very secure in its default state. Aren't you compromising that security when you add third-party patches? I would think that these patches, since they are not part of qmail proper, have received nowhere near the scrutiny that sendmail (or postfix, exim, etc.) have received. Doesn't that defeat the main reason for using qmail?

I agree partly with you, it bothers me to have to patch my vanilla qmail to get all the functionality that I need. But on the other hand you only install the patchs that you need, so you're still more secure than if all the features/patchs we're allready bundled with qmail.

The idea is to keep your installation as small as possible and to install only well-known patchs.

Re:Or try qmail - unbroken since v1.03 (1998)

[ttyv0]

That is why when you decide to add patches to qmail, you only add patches that had be verified , are known to be good, and had been in use for couple of years.
There are plenty terrible patches available -- if you apply those, it just means that you don't know what you're doing. However, some of the best patches where written by very smart people (who published qmail books, for example).
Qmail is secure because it was _designed_ from the ground up to be secure. Anybody who knows enough C program and about qmail internals can add patches to qmail without comprimising it's security because qmail _makes it easy_ to be secure.

Re:Or try qmail - unbroken since v1.03 (1998)

[thogard]

Qmail has a guarantee

But have you noticed the qualifiers? Sendmail works around bugs in the OS (and most of the CERT warnings involving sendmail are because of OS related issues and other delivery programs, not the sendmail core).

How many of the race conditions fixed in sendmail and apache exist today in qmail? Does qmail work around any linux kernal problems?

Re:Or try qmail - unbroken since v1.03 (1998)

[Feyr]

i have to agree, bernstein is one of the few i absolutely can't stand, and given the crappy documentation on all of his projects, i avoid everything he touches

i have yet to try postfix for any meaningful length of time, but courier (www.courier-mta.org) has given me a wonderful experience. it even have a "milter-like" interface! and also no remote security holes (minor, local ones a year ago) since dinausors age

Re:Or try qmail - unbroken since v1.03 (1998)

[ideut]

Dan is such an abrasive prick that I just couldn't bring myself to use his software (the same can be said of Theo and OpenBSD).

Theo won their massive flamewar tho. (see link in sig)

Re:Or try qmail - unbroken since v1.03 (1998)

[.tom.]

You should have read some postfix architecture wrapup before stating that qmail has the edge : postfix design follows those precise two points.

(eg. for architecture related info see here and here )

Re:Or try qmail - unbroken since v1.03 (1998)

[Crayon Kid]

Why should it? That's the whole point DJB is making.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

So, why not fix the faulty part instead. If there are any mail related problems in the Linux kernel maybe you should fix the kernel instead of workarounds in the apps.

I noticed you didn't give any example of those mailrelated bugs in the Linux kernel, are you sure you don't make this up as yo go along?

Re:Or try qmail - unbroken since v1.03 (1998)

[gfilion]

I've considered qmail a few times, but Dan is such an abrasive prick that I just couldn't bring myself to use his software (the same can be said of Theo and OpenBSD).

Let me guess, you're the kind of guy who's gonna vote for Mary Carey as the next California Governor, aren't you?

I wonder how much she would charge to have a picture of her posted on qmail's web site saying: "I dig qmail admins!"

Re:Or try qmail - unbroken since v1.03 (1998)

[proj_2501]

"Even just recently there was a remote DOS in some versions of postfix."

Big deal. DJB offers $500 for finding a security hole in qmail EXCEPT DOS attacks.

Re:Or try qmail - unbroken since v1.03 (1998)

[mjh]

postfix's convoluted incoming vs outgoing filtering

It strikes me as more than a little bit ironic to call ANYTHING convoluted in comparison to sendmail.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

That was the second DOS on postfix. Each had to be fixed in the postfix code and not by a configuration change like qmail.

Re:Or try qmail - unbroken since v1.03 (1998)

[KC7GR]

At the risk of sounding like one of those infomercial testimonials...

I ran qmail for a year or so, then ended up switching to Postfix. At this point, you couldn't pay me to switch back to qmail.

It's not that qmail's a "bad" program. It's certainly not! Dave B. did a heck of a job with it, and I know it's in service as a Sendmail replacement at thousands of sites.

My gripes with qmail are that you practically need to be a programmer to implement it "properly" (at least that's my impression), and that, in order to have an ideal working environment for it, you have to replace the inetd daemon, and add in other tools that are far from simple for non-programmers to implement and use.

My biggest gripe with qmail was how it implemented spam blocking. Complex and clumsy (to my view), with no way that I found to "whitelist" a given domain name or IP, and no way to block on domain name lookup either.

Postfix solved all the problems listed above, and it came pre-installed with NetBSD (my Internet server OS of choice). As for its blocking/whitelist syntax, it couldn't be simpler. Examples...

For blocking: some.host 554 Access denied.
For whiteliesting: some.host OK

You simply replace 'some.host' with an IP address or host name, and the three-digit error code with anything you want. qmail was limited to two error codes. The best part is that you can, if you wish, block entire countries that have become spam sewers simply by doing things like this in the blocklist:

.cn 554 Access denied. China's a spammer paradise.

With qmail, you'd have to go through and enter every single IP range assigned to China, manually. I know -- I did this at one time for qmail, and it was two hours plus worth of work! What's even worse is that you have no control over what error message text is sent back. Postfix lets you put in anything you want.

While I will admit that Postfix's default blocking file cannot directly accomodate CIDR notation or IP ranges, Rahul Dhesi, one of the nice folks who inhabits news.admin.net-abuse.email, wrote a handy script to take a source blockfile, complete with said CIDR notations and specific syntax to indicate a range, and convert it into a form usable with Postfix. He also has a bunch of other handy tools for use with Postfix on his site.

I may not know what a "milter" is, but I do know that postfix can block or pass mail on just about anything you want. It supports regular expressions, hashes, etc.

I guess I do sound like a testimonial... Well, the heck with it! I like Postfix. ;-) The info at Postfix's home site speaks for itself.

Keep the peace(es).

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

qmail_1.03.orig.tar.gz 18-Jun-1999 20:57 215k

!=

modern SMTP server

so to enable qmail for something usefull it needs patches.... but... as we read on qmail.org

It is not acceptable to have qmail working differently on different machines; any variation is a bug.

So all qmails out there are buggy... one big bug per definition.

Stop beating a dead horse, dead for more than 3 years

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

simpler code and a more straight-forward config syntax (the only two real failings of sendmail).

OK, maybe I'm a masochist, but I actually like sendmail's config file :o)

No - seriously - yes, it can be a pain to understand, but it allows me to add functionality without patching the sendmail binary.. (yes, I really do edit sendmail.cf by hand..)

If anyone ever does write a better mailer, I hope they include a decent plugin system (maybe similar to Caudium's - simple, easy, does not require compilation..)

Oh, and as long as I'm dreaming, I'd like a pony. :o)

Re:Or try qmail - unbroken since v1.03 (1998)

[ePhil_One]

ucspi-tcp is not *required* but much of the qmail documentation assumes that you are using it. ucspi-tcp is also written by Dan Berstein (cr.yp.to/ucspi-tcp.html)

Which is exactly why I won't use it. Dr Berstein is brilliant, and writes good code, but he wants me to replace half my system with his stuff. But until someone delivers DJB Linux, where everything runs under his model, I'll be sticking with the existing stuff. I DO NOT want to have two init programs running, two ways of controlling daemons, two ways of logging, etc.

I'm using his DNScache software on a few systems, I'm impressed with its performance, but am constantly frustated by its non-conformity.

Re:Or try qmail - unbroken since v1.03 (1998)

[AftanGustur]

Collection of small daemons

And yes, you *could* configure it with just a screenful of lines, but we have over 20 domains, and all sorts of bells and whistles going for it so the config is is more like 51 lines of variables.. (postconf -n | wc -l).

But the best part is that even though we have a lot of configured variables, postfix still uses only 1 file on the disk for each normally handled email (is uses 2 if the mail gets delayed) and it is ridiculously *fast*.

Re:Or try qmail - unbroken since v1.03 (1998)

[papason]

Yes, we have run Postfix and Sendmail in the past and since moving to qmail, our systems have been solid. Bullet proof. Postfix is bloated in size for the first comparison to qmail. The list goes on. See http://www.geocities.com/mailsoftware42/ for a detailed comparison of MTA's.

Re:Or try qmail - unbroken since v1.03 (1998)

[JamieF]

>Postfix, on the other hand, suffers from the windows design pardigim.
>One big package to do it all.

I guess if you define "one big package" to be modularized like this and "do it all" to mean "be an MTA" then you're right. Are you saying that qmail does less, with more than 36 different executables (which is how many postfix uses), and that that's better?

>Even Wietse doesn't trust his own software.
>http://marc.theaimsgroup.com/?l=bugtra q&m=1060186 77502632&w=2

Riiight. So you're saying that when Dan ships a bug fix, all qmail installations are magically updated, and all distributions out there on FTP servers and CDs are updated too. No? That's all that Wietse was lamenting - read the message again. He's saying that you can fix a bug in the current code but you can't make it go away retroactively. He doesn't say he doesn't use or trust his own software.

>Postfix on the other hand is still underdevelopment,

I guess you would prefer an abandoned product? Or are you saying it's not ready for production use yet? IBM released it FIVE YEARS AGO as the IBM Secure Mailer. It does get updated, though. Horrors! Do you use an OS that is "done" too, because not ever being updated is a good thing?

>suffers from a poor design,

According to you. How exactly is the design poor in your opinion? Hint: You can't just say "it's like Windows". What are some specific design choices and examples of why that's bad? Or are you just hand-waving?

>and probably will include the kitchen sink by next year.

Based on what, exactly? Please explain why you think Postfix is adding all sorts of non-MTA features lately, and preferrably show a link to a message by Wietse where he says he's going to do so in the future.

Re:Or try qmail - unbroken since v1.03 (1998)

[ajs]

postfix's convoluted incoming vs outgoing filtering

It strikes me as more than a little bit ironic to call ANYTHING convoluted in comparison to sendmail.

And to turn that around, it strikes me as more than a little bit odd that postfix manages to be MORE complex than sendmail in this respect. I mean, it's not like rule-sets are a joy to behold, but postfix manages to make it even more of a pain, to the extent that I've heard seasoned postfix admins on mailing lists say, "well, that's not exactly doable out-of-the box, why don't you just set up an incoming and and outgoing server?..."

I like the *idea* of postfix, but it seems that the filtering system makes it rather a difficult migration away from sendmail.

Re:Or try qmail - unbroken since v1.03 (1998)

[DavidTC]

New feature in the snapshot...Postfix can handle CIDR now, and it will be in the next version.

Or you can just use the snapshot...it's not like it's unstable, plenty of places use it on huge production servers.

And I thnk there's a patch with just CIDR, but I am not sure.

Re:Or try qmail - unbroken since v1.03 (1998)

[hysma]

Aren't you compromising that security when you add third-party patches? Not nesicarly. Qmail avoids doing anything as root, so an exploit in any 3rd party add ons/patches would only grant you access to one of the 4 qmail users that is installed on the system. Can't do much with that aside from perhaps reading/deleting the mail queue.

Re:Or try qmail - unbroken since v1.03 (1998)

[Brendan Byrd]

I looked at qmail two years ago, and I have to say that qmail is the most confusing MESS I have even seen. NOTHING is in its right default place! NOTHING! Everything has this strange directory structure, and it doesn't even use the default LOGGER. Yes, you have to install this dumb logger daemon, solely for the purpose of logging stuff for your qmail.

Sorry, but I'd perfer a mail program that puts stuff in the right place. I want my configuration files in /etc, and I want syslog to manage my e-mail logging.

Re:Or try qmail - unbroken since v1.03 (1998)

[axxackall]

i have yet to try postfix for any meaningful length of time, but courier (www.courier-mta.org) has given me a wonderful experience.

After I've finally decided to migrate from sendmail, courier-mta was my first choice to try. The software is nice for the first moment, but after you try anything non-default you discover a poor decumentation and a very unfriendly author. After I've found in maillists that qmail and courier-mta's authors have a very similra character, I've abandoned courier-mta, moved to Postfix and it's almost a year I use it in various installation having no problem to extend it in any direction I need: very flexible and very wise architecture, very good documentation and no any serious/security bugs so far.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

Obviously he was talking about qmail having the edge over sendmail.

Re:Or try qmail - unbroken since v1.03 (1998)

[Feyr]

i somewhat agree. Sam can be annoying, but usually with reason (and he's dead bent on respecting the RFCs). the documentation is all there tho, it's just not organized like you would expect it to. :)

Re:Or try qmail - unbroken since v1.03 (1998)

[KeithH]

I suppose I should have emphasized the "not" as well as the "required". You do *not* have to use ucspi-tcp with qmail if you don't want to.

Re:Or try qmail - unbroken since v1.03 (1998)

[j-turkey]

I've considered qmail a few times, but Dan is such an abrasive prick that I just couldn't bring myself to use his software (the same can be said of Theo and OpenBSD). Check back through the qmail archives for some of his abusive responses to participants in the various qmail lists.

You show 'em! Maybe those bartards'll think next time they do something that you don't agree with. Ya know, they're not selling commercial products, so they're not taking on any financial losses from your boycott. Chances are that they're not developing software to make friends, or otherwise gain popularity with the Slashdot/Usenet/etc crowd.

Seriously though...that seems like an impractical attitude. Does that mean that because I don't agree with RMS' principles and goals, that I shouldn't use any GNU software?

Also, there's no need to have any contact with DJB, or DeRaadt to use their software. There's a decent support community out there. If one of these guys does write software that you need, and you use something inferior (or inappropriate) because you don't like them -- it's like cutting off your nose to spite your face.

I use qmail (and in some cases, OpenBSD) not because of whether or not I like the authors, but because they are practical for some uses. If I choose a product for work because I like the author, and not based on other merits, I'd likely get fired.

However, your point about timely patches was not missed...It just seems like the larger point was that DJB and DeRaadt are pricks, and because of it, you don't want to use their stuff. It may do you good to consider using a "product" based on it's merits next time.

Just a thought

--Turkey

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

The reason qmail is cumbersome is because the license is needless pain. You cannot adapt qmail to the particular OS you are using and distribute binaries. For example DJB insists on the /services directory whereas FreeBSD insists this directory belongs in /var/services. As a result FreeBSD cannot distribute packages for qmail or any of DJB's code.

What you have to ask yourself if you chose to use DJB's software is, what happens when DJB dies. He should release his code as BSD or GPL so that we don't have to live with this hive of incompatable patches.

DJB claims his desire is to influence all systems to "look the same", but in reality he is forcing every system to run a locally modified program that is extensify customized differently at each site. Which is worse.

Re:Or try qmail - unbroken since v1.03 (1998)

[rainer_d]

I think, esp. with DJB-DNS, you must use something like the FreeBSD port or - if it exists - a binary of the Linux-distribution of your choice. I run it on FreeBSD and OpenBSD (only cache), but OpenBSD has no port since some time (TdR didn't like the license) and the way it is installed by default is absolutely incredibly complicated.

With FreeBSD's port, at least everything is arranged with some common sense.

Re:Or try qmail - unbroken since v1.03 (1998)

[Xenna]

Qmail doesn't use it's own logger daemon. It uses plain old syslogd.

There is a program called splogger, which is what is probably confusing you. It accepts data on standard input and passes it on to syslog.

The idea is that a program (like qmail-send or qmail-smptd) outputs its logging to stdout where it is picked up by splogger. This way there are no logging functions in the qmail-send program itself. Each program does it's own thing, typical DJB design and worth considering for other programmers IMHO.

Also, you can use inetd with qmail-smtpd if you like, it's just that Dan advises you to use tcpserver.

Bernstein may not be the most pleasant guy in software design, but his ideas deserve to be looked at carefully...

X.

Re:Or try qmail - unbroken since v1.03 (1998)

[thogard]

Because the race conditions that exist in many OSs are not fixable by its users but are fixable by the software that you do have source for. From what I can tell, qmail has more patches out there than any other MTA and I'm guessing they were written for a reason.

Re:Or try qmail - unbroken since v1.03 (1998)

[cas2000]

> postfix's convoluted incoming vs outgoing
> filtering;

you obviously don't know postfix at all, because postfix has no concept of "incoming" or "outgoing" mail.

ALL mail is "incoming" because it all gets stored in the queue upon receipt (whether via smtp, or local injection), and ALL mail is "outgoing" because it all gets delivered from the queue.

> Perhaps someday someone will write a simple
> sendmail replacement that is feature-for-feature
> compatible, but simply has simpler code and a
> more straight-forward config syntax (the only
> two real failings of sendmail).

somebody has, and there is. it's called "postfix".

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

yeah what a nigger

Re:Or try qmail - unbroken since v1.03 (1998)

[Shaklee39]

Um, no. qmail has patches available to add components to the MTA. Show me one race condition or even a "fix" on something other than changing functionality like allowing more concurrent remote connections.

Re:Or try qmail - unbroken since v1.03 (1998)

[Shaklee39]

You do not need to be a programmer to set it up, unless the ability to follow directions makes you a programmer. As far as spam blocking goes, why would you expect a spam blocker out of an MTA? Most people would figure out that qmail is not for blocking spam and instead would use something like spamassassin and have the best spam blocker up and working within 5 minutes like I did.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

please don't give him a response, these are the kinds of people that we do not want to use qmail. The kind that are unable to figure something out unless someone holds their hand through the process.

Re:Or try qmail - unbroken since v1.03 (1998)

[Anonymous Coward]

QMail has one bug that makes it almost unusable for me: it's SMTP daemon doesn't check that the RCPT TO: address is valid before accepting a delivery. Which means you end up with a ton of double-bounced mail the next time a worm comes around that delivers to fake email addresses (xxxyyyzzz@yourdomain.com) with a bad From or Reply-To header.

I think this is in general bad practice, instead of

(infected machine) -> (your SMTP server)

you have

(infected machine) -> (your SMTP server) -> (bouned mail to server from fake From: header) -> (your SMTP server)

It wastes bandwidth and is in general a nuisance. There are patches available to remedy this (baddrcptto and a few others come to mind), but they don't come from DJB and so if you use them you don't get the magic security guaruntee.

The configuration files are OK, but take some getting used to. I like the .qmail forward files, but qmail has the bad habit of insisting on installing its binaries to /var (??), which according to DJB is done for portability reasons. Personally, I'd rather deal with ./configure -DPREFIX=/usr/local or something to that effect.

More info/annoyances available here:
http://www-dt.e-technik.uni-dortmund.de/~ma/qmail- bugs.html.
The author of the page calls them "bugs", but I would classify them more as "major pains in the asses" :-)

Re:Or try qmail - unbroken since v1.03 (1998)

[ajs]

postfix has no concept of "incoming" or "outgoing" mail

Exactly the problem that many run into, and the problem to which I was refering. If you *do* have to distinguish these two states, you end up getting snared in postfix's complexity, and if you don't then the end-result to users is very non-intuitive for things like spam- and virus-filtering.

Re:Or try qmail - unbroken since v1.03 (1998)

[bafu]

why would you expect a spam blocker out of an MTA?

I can't speak for everyone, of course, but I want my MTA to be involved whenever possible since I would prefer to jam the offending message back to the sending server whenever possible. If it can be set up to allow 3rd party filters to be plugged in, milter-fashion, so much the better. That way the MTA folks can work on the MTA and the filter folks can work on the filters.

Also, to come back to the parent poster's complaint, if you can properly deal with a simple IP/domain-based block right off the bat, rather than waiting for a per-message post-processor like spamassassin to handle it, you'll save noticeable amounts of resources (unless you are a small shop, I suppose). I like and use spamassassin, but it definitely doesn't scale as well as I would like... the more work I can offload from it, the better.

Use Qmail

[The Original Yama]

The Qmail author offers money for any holes found. So far he hasn't had to pay a cent.

Re:Use Qmail

[dasmegabyte]

Qmail is a little tricky to set up, but it's also small, has some awesome optional features (virtualhosts and the .qmail aliasing system are wierd, but once you get them down you'll appreciate the flexibility they offer) and once you're done it's worth it. It's nice to have a service that you can say, "This is done. I no longer have to worry about it."

Of course, since I use DJBDNS and qmail-pop3, I have 3 services I can mostly ignore. And it only took me 8 hours curled up with lifewithqmail.org to do it.

Re:Use Qmail

[Anonymous Coward]

You're suggesting that money is a primary incentive to find a vulnerability in software, and that people are more likely to try to find an exploit if they will be paid to do it. This means that you, and the author of qmail, have a very low opinion of your fellow developers.

For that reason alone, I would not spend one moment of my time using, let alone auditing, qmail. I am not surprised no holes have been found.

Re:Use Qmail

[The Original Yama]

Don't put words in my mouth. I made a very simple statement. If you choose to interpret that in some elaborate manner, then that is your problem.

Re:Use Qmail

[hanssprudel]

the author of qmail, ha[s] a very low opinion of your fellow developers.

If you had looked at the license for qmail, you would already know this.

Re:Use Qmail

[kfuq]

Qmail rocks, nice and stable - but it is a bitch to setup/administer

postfix is good, but virutal domains are kind of wierd with it.. v-users have to have a local account

everything i have ever read on email v-doms with sendmail -- total bitch..

Re:Use Qmail

[ideut]

The financial offer is utterly bogus. Its existence does not imply any additional security. If you consider the hourly rate of pay of a professional code auditor, the DJB "reward" pales into insignificance. So why bother mentioning it?

Re:Use Qmail

[chrsbrwn]

Virtual users most definitely do not have to have individual local accounts with postfix. I have set up a corporate mail server, with 3 different mailing domains, and 60 different users spread throughout the domains. The user info is stored in MySQL, and postfix and courier-imap pick up their info from there. None of the mail users have local accounts, all are mail only.

I also have blacklists/whitelists, spam & virus filtering, and dns blocklist checking set up. I was able to do all of this without patching the source (I used debian's default .deb), and was able to reuse my previous sendmail installation's /etc/aliases (which I needed to support the mailing list manager I had previously set up).

Re:Use Qmail

[dasmegabyte]

Virtual users do not really need to have a local account at all...they need to have an entry in the users database, and that by default uses local accounts. But if you want to make a big directory full of mail drop folders and make everything perfectly virtual...then qmail allows you to do that.

You will need a UNIX user account for your ploy. But really, you need a UNIX user account to do anything. I made one called virtualusers, which has no permissions except in /home/mailtricks. Then I did this in /var/qmail/users/assign:
=nosuchuser:virtualusers :::/home/mailtricks/nosuch user:::
=anotheruser:virtualusers:::/home/mailtri cks/anoth eruser:::

virtualusers is used as the accessing UNIX user for mail delivery. As long as it has rwx access to /home/mailtricks, any number of "users" can use the same UNIX account. The cool thing is, if you use qmail-pop3 and a qmail compatible imap server (like courier), they can use the same assign database for checking mail as you use to deliver it.

All you have to do is manage the virtualdomains and assign files, which isn't so hard. I'm working on a jsp web admin system for virtual users which does exactly that...I'll be releasing it under BSD if it ever matures.

Re:Use Qmail

[DavidTC]

The problem is that postfix has about a dozen ways of doing 'virtual domains'.

None of my local users, as in, actual shell account holders. get mail. All the mail accounts are in a mysql database, as are all the domains that we accept mail for, and they all dump into /var/mail/domain.dom/n/name/. I don't think I use any of the 'virtual' stuff at all.

Of course, I don't do any of the + tricks with email addresses. or run any mailing lists.

Re:Use Qmail

[Anonymous Coward]

I haven't looked at the license for qmail. Do you have a link to it?

Re:Use Qmail

[kfuq]

WOW.. gettin jumped by the postfix people..

|-)

where were all of you when i was trying like hell to figure out virtual hosting in postfix about two years ago !!

What's wrong with sendmail?

[CoolVibe]

No, really?

Of course now I get al the exim, qmail and postfix fanboys blasting at me, but sendmail works well. Works good enough for most. Heck, if sendmail were so insecure, why is OpenBSD still including it in it's base?

Don't get me wrong, postfix is a nice MTA. Yes, it is easier to set up depending on what you think is "easy", but still, it's a nice MTA, but no reason to not use Sendmail if you can help it.

Re:What's wrong with sendmail?

[Anonymous Coward]

Yeah, but OpenBSD is including an ancient version that they spent tons of time audding.

After using qmail for 4 years, I can't see why anyone would touch sendmail.

Re:What's wrong with sendmail?

[Anonymous Coward]

not only is it "good enough for OpenBSD", it's also good enough to be behind some of the largest email servers in the world.

Sendmail is tried and true. It handles load like there is no tomorrow. There's a reason it has been the standard for so many years...

Just because it has holes (that are patched in later versions) does not make it any worse off than anything else.

Re:What's wrong with sendmail?

[satch89450]

Don't get me wrong, postfix is a nice MTA. Yes, it is easier to set up depending on what you think is "easy", but still, it's a nice MTA, but no reason to not use Sendmail if you can help it.

I ditched SendMail because it made me uncomfortable as an administrator. Yes, I could get it working "good enough" that I wasn't a relay, but because of the arcane command file structure I wasn't satisfied that it was tuned the way I wanted it. (BTW, I had hand-coded a sendmail.cf from scratch before, and made it work, but that was when I had a whole day to spend on the project.)

Back in the days when there weren't a hoard of people trying to crack your system, SendMail was OK. Nowadays, you want to make absolutely sure there are zero holes in your system -- arguably you want to PROVE there are no holes, which is an impossibility -- and SendMail makes that very hard to do.

With PostFix, I can get a configuration file, sort it, and check each parameter against the manual. In fact, PostFix can get me EVERY setting (using postconf) so that I can verify I like the defaults, too.

In the current Internet environment, "good enough" isn't good enough.

Re:What's wrong with sendmail?

[Anonymous Coward]

Yes, Qmail is a fine MTA too but it's license doesn't float my boat. Until a MTA comes along with a decent license, sendmail will be used by all.

Re:What's wrong with sendmail?

[UnclPedro]

Heck, if sendmail were so insecure, why is OpenBSD still including it in it's base?

Because it's the only major MTA with a license that's acceptable to Theo.

Re:What's wrong with sendmail?

[CoolVibe]

Sendmail currently ships with being a relay by default turned off. Also, all BSDs ship with sendmail set up that way. And they're not ancient versions anyway. (8.12.x, last time I checked). Of course NetBSD ships with postfix, but I harly use it. Sendmail performs well enough, and m4 isn't the hassle everyone thinks it is.

Like some other poster says, postfix is actually pretty fussy when it comes to virtual domains. In sendmail you use a sendmail.cw, plonk all your recieving domains in there an be done with it. And there's milter.

Sendmail is good enough for me, the same as postfix would be, but I don't see a solid reason to switch.

Oh, I haven't seen a compromise through sendmail in YEARS. Yeah sure there were bugs, but if you keep your world upt o date with cvsup or cvs, the holes get plugget VERY fast.

Try better. I'm not convinced.

Re:What's wrong with sendmail?

[CoolVibe]

Yeah, but OpenBSD is including an ancient version that they spent tons of time audding.

False:

220 xxxxxxxxxxxx ESMTP Sendmail 8.12.9/8.12.9; Mon, 25 Aug 2003 15:30:11 +0200 (CEST)

Well well well, ancient huh? Whatever. Yes, that's openbsd's default sendmail as of version 3.3

Re:What's wrong with sendmail?

[CoolVibe]

But if sendmail is the security nightmare everyone claims it is, why isn't OpenBSD a heap of swiss cheese then?

Re:What's wrong with sendmail?

[gfilion]

Of course now I get al the exim, qmail and postfix fanboys blasting at me, but sendmail works well. Works good enough for most. Heck, if sendmail were so insecure, why is OpenBSD still including it in it's base?

The devil is in the details. I remember when I was trying to set up a virus checker for sendmail, I screwed up, and sendmail started sending my emails to /dev/null. With qmail, at least, when I screw up my configuration, it keeps the emails in the queue until the configuration is repaired.

Re:What's wrong with sendmail?

[macdaddy]

If you coded a sendmail.cf from scratch then you are a damned fool. There's no other way to put it. YOU DO NOT CODE THE CF BY HAND. YOU DO NOT EVEN TOUCH THE CF! The Sendmail gurus have been saying this for years and there is NO excuse for not heeding their warnings. You use the M4 macros to build your CF. There is rarely, and I do mean rarely, any reason to directly edit the cf. You can do everything you need to do in the M4 macro file. Even the Sendmail gurus themselves don't touch the CF.

This is something that really pisses me off. People bitch and moan about Sendmail being so hard to configure when really they haven't done the tiniest bit of research or RTFM. If they had they would have known not to edit the CF. "Don't touch the CF" is the most common answer on comp.mail.sendmail. Yet these novices still feel knowledgeable enough to make claims about how hard it is to configure Sendmail. I swear the quality of sysadm nowadays is somewhere in the crapper. I've been using Sendmail since 8.8.7. I have never had an unusual configuration I couldn't quickly create with a minimal amount of online research. It's not rocket science folks.

Re:What's wrong with sendmail?

[pigeon]

I agree.. switching to postfix was for me a very good decision. Guess sendmail is a nice MTA, just like russian is a nice language.. if you know it. And oh, I have a spare O' Reilly sendmail book lying around..

--
Order your own anti-sco shirt now, proceedings go to the EFF. http://www.cafeshops.com/geekkitchen

Re:What's wrong with sendmail?

[isenguard]

Um, it depends how long ago we're talking about. I'm not that old, and when I first set up sendmail the M4 macros weren't available.

Re:What's wrong with sendmail?

[CoolVibe]

That's strange. When I set up a milter to do virus checking, when the configuration is faulty, sendmail sends back an 44x error to the sending mta, which means it has to try again (and it will, ESMTP demands it).

if you lost mail, then it's not the fault of sendmail, but the fault of your virus checker. Sendmail is obsessive about NOT losing mail.

Again, more FUD from the postfix, qmail and exim fanboys.

Re:What's wrong with sendmail?

[CoolVibe]

Ah, the voice of reason.

Moderate this up. It cuts straight through the FUD from the qmail/postfix/exim fanboys.

I _NEVER_ touch the .cf. Never never never. Creating a sendmail.cf on e.g. FreeBSD requires no more knowlegde than how to run 'make' in /etc/mail. You don't even _need_ to mess with m4. NetBSD does the same. OpenBSD however requires you to make your own .mc, but that's not really hard, since theres lots of .mc files you can use in /usr/share/sendmail.

Also, it strikes me that lots of the anti-sendmail crowd got modpoints today. They are clearly on crack.

Re:What's wrong with sendmail?

[rootofevil]

doesnt this go against everything we love so dearly about linux?

i cant mess with the config file directly? why on earth would i want to run this obviously broken software in that case?

Re:What's wrong with sendmail?

[rosie_bhjp]

why would I want to use a system that requires you to preprocess your configuration file, and gives you an obfuscated but still legible configuration file as an output? Does the arcane syntax of the .cf file really make it that much faster for sendmail to parse the configuration file?

I understand sendmail is just fine for people who are used to it, I used it for four years and got by with few problems. I also understand why people shy away from sendmail and the attraction to alternative mailers like postfix and qmail. For the past year I've used postfix and feel infinitely more comfortable with its configuration, design philosphy, and inner working than I ever did with sendmail.

Maybe I should spend my time RTFMing and doing online research into sendmail to make myself feel more comfortable with it. Nah, I'd rather just install Postfix and get on with my life.

Re:What's wrong with sendmail?

[CoolVibe]

You can mess with it, but we recommend that you don't. You still have a choice though.

Also, using m4 is soo much more easier and less error prone.

Re:What's wrong with sendmail?

[AchmedHabib]

I don't like a program that needs a compiler for the configuration file.

Re:What's wrong with sendmail?

[johnnyb]

I have admin'd sendmail from the mc files, and I still must say, POSTFIX IS MUCH EASIER!!! In addition, Postfix is uber-secure. Wietse never lets any foreign data touch a privileged daemon. Even with local delivery, the daemon drops it's privileges _before_ getting the data to deliver.

And, amazingly, it's very, very fast.

And, it has excellent resource controls, so you don't inadvertantly DOS yourself.

All of these are very easy to use and setup.

Re:What's wrong with sendmail?

[Anonymous Coward]

You can do everything you need to do in the M4 macro file.

Not quite - I edit my .cf file to add new functionality to sendmail (mostly anti-spam stuff) for which there is no M4 equivalent..

M4 is fine if you want to stick with the straight and narrow, and do stuff that someone has already thought of.. but it's inadequate for adding stuff the first time..

Re:What's wrong with sendmail?

[CoolVibe]

m4 is not a compiler, but a macro language. m4 is not only useful for creating sendmail configs, You could compare m4 to the C preprocessor.

I use it to generate html/php pages, for instance. Instead of shooting it down, try researching it before you badmouth it. m4 is actually pretty nice.

Re:What's wrong with sendmail?

[JCCyC]

Heck, if sendmail were so insecure, why is OpenBSD still including it in it's base?

Because it's the only major MTA with a license that's acceptable to Theo.

Speaking of which, Postfix's license is the IBM Public License, which qualifies as Free Software. Is there anything wrong with it according to TdR?

Re:What's wrong with sendmail?

[Dr. Manhattan]

YOU DO NOT CODE THE CF BY HAND. YOU DO NOT EVEN TOUCH THE CF! The Sendmail gurus have been saying this for years and there is NO excuse for not heeding their warnings. You use the M4 macros to build your CF.

If your config language is Turing-complete, and needs a parsing tool to be useful even to "gurus", something is very, very wrong.

Re:What's wrong with sendmail?

[UnclPedro]

As I recall, it's section 4 of the license (Commercial Distribution) that's the problem. Search an archive of the misc@openbsd.org list for "postfix license" and I'm sure you'll find several instances of the flamewar. :)

Re:What's wrong with sendmail?

[Cynic 1.0]

Isn't there something wrong if you have to compile a configuration file? Config files are supposed to be flat text files that anyone can read and understand. There's something seriously wrong if there's so many warning signs attached to mail server configuration.

I've run into custom cf files where it took me some time to track down and only partially understand the changes to the rules. In qmail and postfix, I could just look at the configuration files even on systems where I hadn't set things up and know exactly what was happening and how.

No way can M4 be used as an example to see how easy sendmail can be. And what's with cf file versioning?!?

I know sendmail can be just as secure as any other mailer provided the updates are installed but it is a big help to have a secure by default mail server running.

Re:What's wrong with sendmail?

[Anonymous Coward]

It's an extra step, that most other software doesn't need. It doesn't fit with the rest of the system.

Maybe if I had to use m4 for every other config file on the system too, then Sendmail's use of it wouldn't seem so gratuitously strange. But that's not the world I live in.

Re:What's wrong with sendmail?

[pjrc]

People bitch and moan about Sendmail being so hard to configure when really they haven't done the tiniest bit of research or RTFM.

I recently made a change to my sendmail config, and I spent a couple hours reading through sendmail's "manual"... it is complete garbage.

You write:

YOU DO NOT CODE THE CF BY HAND. YOU DO NOT EVEN TOUCH THE CF! The Sendmail gurus have been saying this for years and there is NO excuse for not heeding their warnings.

Well then, would you care to explain why the sendmail manual (if you could go so far as to call it that) is laced with lots of documentation that only refers to the .cf way to specifying things.... and then you need to search through all sorts of other documentation to find the M4 way of acheiving it?

Overall, the sendmail documenation is very poorly written. The scattered bits of reference to .cf lines are only one example of what's wrong. There is very little "larger picture" documentation to provide a conceptual model of how the system works... and what does exist makes lots of lots of references to sendmail's internal operation and lacks much explaination of how that relates to the overall task of delivery of messages. There are vast repositories of documentation of individual features, each with very terse and brief explaination, more often than not making reference to some other element (of course, without a hyperlink or reference to where it is).

Compare to Exim's documentation, which is well written. While somewhat verbose and therefore lengthy, everything is explained clearly in plain english that is easy to understand. Features are documented clearly with plenty of background material about how they relate to the overall objective of delivering mail. There is a default configuration file which is intended to work for most sites with only a few lines edited (compare to sendmail where the default is not intended to work easily). There is a whole chapter in the Exim manual that explains every little part of the default config... compare to sendmail where just abou the only docs you'll find on the default config are very hostile sounding warnings that it isn't meant for anyone else to use and you're a fool if you use it without editing everything.

While Exim is the only other MTA I've spent the time to learn, I'm sure Postfix and Qmail are also vastly better than sendmail in terms of ease of configuration and clarity of readability of their documentation.

So don't spout off about sendmail detractors not reading the fucking manual (RTFM). I read lots of that fucking manual only last week. It sucks. Anyone who spends an hour reading the poorly written sendmail documentation and then even a few minutes looking at the well composed, clearly explained and easy-to-read Exim manual can clearly see that anyone who does attempt to RTFM would clearly not perfer sendmail's horrid documenation. Perhaps Postfix and Qmail are somewhat better or worse compared to Exim..... but it's amazing just how badly composed Sendmail's documentation is.

By the way, I've resisted ditching sendmail for years, cause it was already set up and working. But GNU Mailman drove me to learning Exim, because Exim has a feature where it can deliver based on the existance of mailman's list config files, which allows me to have a list administator able to create new lists without editing /etc/alises.

I should have learned a better mailer years ago. But now that I'm familiar with a MTA that has an easy to understand config format that's structured based on a conceptual model that represents understandable steps involved in delivery of mail (as opposed to sendmail's very abstract model), and it actually has a well written manual.... I'll never go back to sendmail. I'm still running sendmail for my mail email, but next time a security advisory comes out or I have to change the sendmail config, instead I'll create a new Emix (or might try Postfix) config rather than continuing to limp along with a difficult-to-understand (larely due to poor documentation) sendmail installation.

Re:What's wrong with sendmail?

[whoever57]

And there's milter.

Postfix has "content_filter", which seems to do everything milters can do.

Re:What's wrong with sendmail?

[styrotech]

As I recall, it's section 4 of the license (Commercial Distribution) that's the problem. Search an archive of the misc@openbsd.org list for "postfix license" and I'm sure you'll find several instances of the flamewar. :)

Is that still a problem? I'm just curious, I haven't kept up with that issue.

I seem to recall during OpenBSDs big license audit, they had an issue with the Postfix license, contacted Wietse about it, the license was modified ever so slightly and everything was all sweetness and light again.

I get the feeling OpenBSDs reasons for not dropping sendmail are:
a) Because Sendmail was traditionally the defacto unix MTA standard, they want to support every last Sendmailism.
and b) they've invested so much blood sweat and tears auditing it they don't want to throw that effort away, and start again from stratch (admittedly Postfix wouldn't be as hard to audit as Sendmail).

I do use Postfix on OpenBSD. I just compiled the source from postfix.org and it worked perfectly.

Re:What's wrong with sendmail?

[satch89450]

If you coded a sendmail.cf from scratch then you are a damned fool.

When I accomplished this feat, the M4 macros were not available -- the only way to deal with SendMail was to tweak the sendmail.cf file by hand.

Having the M4 macros is an improvement, I will grant you, and SendMail is indeed powerful. In my opinion, though, that power has long since been rendered moot by the near-universal adoption of DNS-based mail, the elimination of bang paths, the deprecation of source routing, and the needs of the security folks to keep the Bad Guys from ruining everything for everyone.

Remember, I moved from Sendmail to PostFix for personal comfort as an administrator.

Re:What's wrong with sendmail?

[javamutt]

I've said it before and I'll say it again. Complexity is very tightly tied to availability in a general sense. I stay with sendmail because I've got it working "good enough" and I don't have the time right now to rearchitect our mail system...

BUT I aboslutely hate the fact that the config language is so complicated that it needs a preparser. Just reading the sendmail book from O'Reilly can be painful because of its size.

I like flexibility, I agree that restricting yourself to M4 (vs. cf editing) makes sendmail MUCH more tasteful, but really - this is the best we can do as a default after all these years?

I'm temped to make use of RedHat's new MTA switcher and take something new for a spin if it saves headaches. I wonder how clean their setup is.

I've switched one box to postfix..

[brentlaminack]

In general I found that virtual domains were a bit trickier to set up in postfix than in sendmail. Ordinary aliases were just as easy (read identical). My sites don't do enough volume to tell any difference in performance. The build/install process was probably a bit easier for postfix, i.e. didn't have to monkey around with M4. So as a sendmail admin of more years than I care to think about, postfix seems about as easy to administer as sendmail on a day-to-day basis.

Re:I've switched one box to postfix..

[ThatDamnMurphyGuy]

I think postfix virtual domains are a little harder because they're two virtual methods in one package.

You can use them old-style like Sendmail, or you can use them Postfix style. The two differ by slight syntax variations. Confusing at first, but the point is you have the option to run compatable virtuals from Sendmail, of not depending on the situatation. I won't even claim to have a full understanding of the differences.

Re:I've switched one box to postfix..

[segment]

I've run heavy sites with postfix when I worked at a service access provider once. We had about 5k domains (notice I typed domains... users = ? don't have an idea) on each server (back then was a VAR501) running on postfix without a problem. QMail is alright but I notice the load gets heavy a bit so it's not good for like legacy systems at least in my opinion.

Sendmail.. ugh. Remember that old comment, if you've got nothing nice to say? At least they gave out free sendmail swiss army knives once!

Re:I've switched one box to postfix..

[Anonymous Coward]

When you have thousands of domains on the box you really do notice how much better postfix is than sendmail.

I've handled tens of thousands of domains under both and the ease of management, load handling and better security (as well as readable code!) make postfix the hands down winner for me.

Re:I've switched one box to postfix..

[cloudmaster]

open up /etc/postfix/virtual

add a line "virtdomain.com VIRTUAL"

add a list of virtual username-to-username mappings or the line "@virtdomain.com @realdomain.com" to do sendmail-ish virt. domains.

run "postmap /etc/postfix/virtual" to regenerate the database (so postfix doesn't have to scan a plain text file over and over)

Possibly uncomment the part in main.cf that enables checking for virtual domains if you havne't done that already.

That's pretty simple, IMHO. :)

Re:I've switched one box to postfix..

[bigberk]

In general I found that virtual domains were a bit trickier to set up in postfix than in sendmail

postfix used to have a different way to do virtual domains (in fact, it was called the "sendmail-style" virtual domains). These were a pain. Now it is very easy to set up virtual domains. There are 3 steps, and it will take you all of 2 minutes to set this up. I kid you not...

1. Make sure 'virtual_maps' directive is in postfix.conf; e.g. virtual_maps = hash:/etc/postfix/virtual
2. Edit the file 'virtual' making sure you include the "Virtual domain" as the first line of a group. Include as many as of these blocks as you want, multiple domains.
   example.com Virtual domain
   ad1@example.com destuser1
   ad2@example.com destuser2
   
3. Run 'postmap /etc/postfix/virtual'

Re:I've switched one box to postfix..

[dpilot]

Does this take care of remapping both outgoing and incoming addresses?

I've been running Exim for years, primarily for its ease of rewriting and reasonable security record. I've thought of moving to Postfix, but have never really had the time to dig into rewriting.

I also maintain my Mom's dialup system. Exim isn't designed for dialup, but is able to easily queue, recover, and force-send from ip-up. How is Postfix with intermittant connections?

Re:I've switched one box to postfix..

[WoodstockJeff]

I dumped sendmail and my unsuccessful attempts to compile qmail (no binary distributions allowed) when I "accidentally" discovered that one of my Mandrake installs had a working, non-relaying mail server running, without my having to configure it... it was postfix. Subsequently, our shop has standardized on postfix for the MTA, but not for deliverying mail to users. For that, we use dbmail, which uses either MySQL or PostGres as the mail storage handler. As part of building postfix and dbmail to work together, I found that a LOT of things become easier with postfix when it has SQL support... using MySQL to host the transport table (doubles as the mydestination table), virtual domains can be added without even restarting the daemons; just add them to the table. dbmail makes it possible to have overlapping user namespaces, if your users will tolerate login IDs of 'user@domain.tld' instead of juse 'user'. Postfix uses dbmail's alias table to determine if an address is local, so that it won't accept mail for non-existant addresses (one of the popular ways to bypass anti-relaying in Exchange and other MTAs that don't vet the destination address when accepting mail). All of my postfix non-regexp spam filters are stored in MySQL, so that I never have to run postmap. All in all, postfix was a good choice for me. Even though I can't use the default binary distribution anymore, it's been pretty easy to deal with. Wish I could have said the same about qmail... never did get that to compile to a usable configuration, despite the book...

I can feel the flames...

[Crayon Kid]

...because the article poster had to mention Postfix. Now someone's gonna say "qmail", someone else will say "exim", someone will say "fuck you, sendmail all the way" and what could have been a nice debate about the full-of-security-holes-dinosaurs of open source will be spent in 500 messages worth of flamewar. Sigh.

Re:I can feel the flames...

[Anonymous Coward]

fuck you, flamewars all the way

=)

Re:I can feel the flames...

[AdEbh]

Fuck you!!! I was going to say that!! :)

- Alex

Re:I can feel the flames...

[Anonymous Coward]

Say That! I was going to fuck you!

That businessmodel is better!

[Anonymous Coward]

1) Get hacked every other day.
2) ?
3) Switch from sendmail to postfix.
4) Secure!

Re:That businessmodel is better!

[judzillah]

5) Profit!

sendmail for legacy

[Harald Paulsen]

I can see that some ISPs have a need for sendmail due to legacy UUCP-customers (yes, someone still uses UUCP), but the world should really move on with regards to MTAs. Postfix, qmail and Exim are all good alternatives. Perhaps linux-distributions should offer other mailers as standard, that would probably get the ball rolling.

As for myself, I switched to postfix several years ago and haven't looked back even once.

Re:sendmail for legacy

[Zigg]

Debian has defaulted to exim as long as I can remember. exim tends to choke pretty seriously on some of my mail, though... (fetchmail'd from an Exchange server) sendmail has never had any such trouble, and I suspect Postfix, based on my previous experience with it, also would not.

Re:sendmail for legacy

[mt_nixnut]

RedHat defaults to sendmail but has a one click converter to postfix which is handy. It coaxed me to try postfix a few months ago and I am definately not going back. It works great and did not force me to change any of the accounts. Last time I looked at Qmail and Cyrus it sure seemed like I had to mess around with a lot to get it going. Even though people swear there are advantages to that setup. Postfix is much easier to set up and administrate IMO.

FWIW

Re:sendmail for legacy

[goga]

I do still use uucp. Postfix handles it without problems.

Re:sendmail for legacy

[martinde]

> exim tends to choke pretty seriously on some of my mail, though... (fetchmail'd from an Exchange server)

The FAQ talks about exim/fetchmail, if you're seeing the "standard problem" it's not hard to deal with. Probably it would be better to ask on a mailing list if it's not in the FAQ.

Re:sendmail for legacy

[Anonymous Coward]

yes, someone still uses UUCP

Does anyone know how to contact him, we could tell him about this great thing called the internet where you can talk to others and get replies and stuff

On a serious note, I was trapped at a place where they uucp`d updates for applications to openserver systems about once a week.... (Everything was "mature" there except the applications they wrote, they where old) The only reason they where changing to Linux wasn`t the licence costs, the application/database environment which they would have to get new licences for, it wasn`t the limitations of UUCP and 5800 boud modems, it wasn`t openserver not getting anywhere but it was SCO looking dying or dead already flinging dung at everybody. If SCO manages to lose customers who are not interested in getting rid of openserver at the soonest opertunity, then they truly lost their deadend unixware and "openserver is such and improvement over xenix" legacy developer market, then what is there left to sell?

Re:sendmail for legacy

[cloudmaster]

http://www.postfix.org/transport.5.html

The "Examples" section (wouldn't see *that* in sendmail's cryptic docs), it tells how to send mail to specific sites using UUCP. Postifx does suport it, as do most of the popular MTAs.

You're on the right track, though. Several sites still use sendmail because it's already there and it already works. Sysadmins (myself included) are lazy. While I personally *like* to learn things, and I like my systems to run efficiently, some other admins like the job security they get from having some obscure m4 that generates an even more obscure cf file. Personally, I think my job's secure because I do it well. :)

Re:sendmail for legacy

[Anonymous Coward]

Harold Paulsen wrote:
I can see that some ISPs have a need for sendmail due to legacy UUCP-customers (yes, someone still uses UUCP), ...

Er, Postfix does UUCP just fine. I've used both dialup UUCP connections and UUCP-Over-TCP with Postfix.

Re:sendmail for legacy

[Ian Lance Taylor]

I use UUCP with qmail. It's easy.

Re:sendmail for legacy

[r7]

Ian wrote:
>I use UUCP with qmail. It's easy.

Though not as easy as Postfix with Postconf's GUI front-end.

R7

Re:sendmail for legacy

[lysander]

You're on the right track, though. Several sites still use sendmail because it's already there and it already works. Sysadmins (myself included) are lazy. While I personally *like* to learn things,

I also like to learn things, but holy god the sendmail O'Reilly is a dense, 1000 page pile.

FWIW, I use postfix now whenever I have a special need for a mail server, and usually stick to the default MTA on whatever distro I'm using, otherwise.

Re:sendmail for legacy

[Zigg]

It's not the "standard problem"; it's a combination of exim trying to parse headers it really doesn't need to and fetchmail bailing out for no good reason instead of moving along when it gets a 5xx.

Yes, it's a bug, and yes, someone probably could fix it, but I don't even have that setup anymore anyway.

i'd like to point something out

[andy666]

windows users don't have to worry about this!

hahaha

(it's a joke ok ? i use unix.....)

Lucky I'm on windows

[Mhumble]

Phew lucky I'm running exchange and don't have these damn sendmail SECURITY fixes to worry about ;)

Panther / Mac OS X 10.3 (11?) will use Postfix

[tm2b]

Just as a heads up to Mac users... the next major revision of Mac OS X, Panther, will be changing from Sendmail to Postfix. So if you use Mac OS X, you don't need to do anything special other than buy Panther when it becomes available.

Personally, that's what is pushing me over the edge to learn Postfix and use it on my OpenBSD servers. In a nostalgic way, it's too bad... I once made some seriously good money writing custom sendmail.cf files on a consulting basis.

Re:Panther / Mac OS X 10.3 (11?) will use Postfix

[immel]

Sweet! At least Apple will do something useful for panther (as opposed to just GUI "improvements") by adding a more secure mail client.

Re:Panther / Mac OS X 10.3 (11?) will use Postfix

[Hatta]

You have to pay for a security fix? fuck that

Re:Panther / Mac OS X 10.3 (11?) will use Postfix

[pHDNgell]

You have to pay for a security fix? fuck that

Haha, I get it...one of the changes they made in their new OS is to replace a daemon which is not only not listening, but not running by default with one that is considered (among other things) more secure. Because this is a major release, and this is the only change you cared to look at, you call it paying for a security fix.

Hey, 10.3 also allows me to maintain an encrypted home directory...is that a security fix I'm paying for?

Did you know that they've been rolling out security fixes as part of their update service? You can find that out pretty easily online.

Re:Panther / Mac OS X 10.3 (11?) will use Postfix

[tm2b]

You're totally missing the point. You only "have to" if you lack the skills necessary to download postfix and install it yourself. It's Unix, dude.

The point is that the *default* of the OS is changing.

In any case, if you follow the link I posted you'll see what you would actually be paying for.

Its look like Qmail Vs Postfix war

[Delifisek]

Qmail uses some kind of weird uniq ways. Of course you may defend your lovely Qmail server.

But if I remember correct. You cannot feel difference between Qmail vs Postfix until, start to deliver 40.000 mails per day.

So use Postfix :)...

Re:Its look like Qmail Vs Postfix war

[Anonymous Coward]

Brodherhood of Linux - Share the knowledge, Protect the Freedom

You forgot:

DoS your enemies - imaginary or real.

Re:Its look like Qmail Vs Postfix war

[slushpupie]

We handle roughly 1.5million pieces of mail daily, and found major performance problems with qmail. In particular, qmail would tend to start slowing down, for no apparent reason, which would make the queue size even larger; and well, it was a slipery slope. We found by switching to postfix not only did we eliminate the issues, but since this is a cluster of mail servers, the postconf command made admining the boxes much easier.

(this was on stock redhat 7.2 installs with scsi raid 5 disk arrays)

Re:Its look like Qmail Vs Postfix war

[A. Lynch]

We handle about 14 million incoming messages per day, across 8 qmail-ldap hosts, in a clustered environment. And we use SpamAssassin for mail filtering, as well.

Those 8 hosts (which are quite modest IBM x335 servers) carry almost no load, and their queues are quite small (about 20,000msgs per host, mostly junk waiting to bounce).

The biggest performace increase we saw was when we switched from magnetic disks to Solid State (RAM) disks for the queue drives.

Re:Its look like Qmail Vs Postfix war

[Anonymous Coward]

14 million and you need 8 hosts? Ever hear of sendmail?

Re:Its look like Qmail Vs Postfix war

[A. Lynch]

Need, have...

We had 8 boxes before we went to SSDs. Things were a little chuggy. We replaced the queue disks, and kept the number of machines.

Speed improved, and we can now handle a much larger message load on these boxes, without lifting a finger.

Re:Its look like Qmail Vs Postfix war

[Anonymous Coward]

So you shelled out huge bucks for solid state disks and 8 hosts for only 14m messages a day?

I've got an old sun E450 doing about 4m a day using local memory for the queue and nothing more going on. No clusters, no incredibly expensive ssd, no 8 hosts. For the money you spent on those ssd drives alone, I could have built a few racks of E420s off ebay and handled 50x your mail load.

You're giving admins a bad name.

Re:Its look like Qmail Vs Postfix war

[Woko]

I doubt any organisation doing 4 million messages a day is going to be comfortable relying on anything bought off ebay.

Re:Its look like Qmail Vs Postfix war

[wolverine1999]

I'm using Qmail on a server but Postfix on another machine... I'm tending to find the latter somewhat better actually. Perhaps I'll switch the server to Postfix..

Courier

[dusanv]

I have been using Courier for over two years now. No remote roots ever or problems of any kind (I am amazed!). It's open sourced and a full package (esmtp, pop, imap, webmail and a thousand other things). It gets my vote.

Re:Courier

[Anonymous Coward]

i'd like to check it out, what is your e-mail address?

:)

Re:Courier

[psicat]

I second this. I have also been using the Courier-MTA suite for over two years (under RedHat). It's been a relief over Sendmail + imapd + popd + etc...

Re:Courier

[gfilion]

I have been using Courier [courier-mta.org] for over two years now. No remote roots ever or problems of any kind (I am amazed!). It's open sourced and a full package (esmtp, pop, imap, webmail and a thousand other things). It gets my vote.

I used it for a couple months because I wanted to have Maildir type mailboxes and wanted an IMAP server, it would crash all the time and give me all kind of troubles. I then switched to Binc IMAP (Binc is not courrier), which claim to be better than Courrier, but it was actually worse. It wouldn't last one week without crashing and send a lot of junk in syslog. I finally settled for dovecot with qmail. I have been running it for 6 months now without any problem.

Re:Courier

[forevermore]

You're (obviously) not the only one... I started using Courier a few years back when one of my sysadmin friends mentioned that his company was switching over all of their mail systems to courier. And though people may not all like them, Real Networks it a big company, and it says a lot that they gave courier the vote of confidence over Postfix or QMail.

Re:Courier

[ahacop@wmuc.umd.edu]

I tried out Courier for my company's email and liked it very much. The configuration was straight forward, etc. However, it choked on various MIME-enhanced emails which apparently don't conform to the standard but which certain email clients used by millions of people tend to send out. The response from the Courier camp was "we won't add code to accomodate other software's incorrect behavior." Fair enough, I say. However, I can't tell the CEO of my company that she won't be getting some emails from clients because it doesn't conform to a standard....

So I switched to postfix.

Re:Courier

[Anonymous Coward]

I thought postfix and and courier typically fulfilled different functions. I have just set up my system with postfix to handle delivery and receipt of email being exchanged with external computers. Postfix puts the incoming messages into a maildir under the users home directory. Courier serves this maildir over IMAP or POP so that mail reading programs such as mozilla can handle them. This is more or less the configuration recommended by the official gentoo documentation .

Setting this up was suprisingly painless:

emerge posfix courier-imap
# edit three lines of /etc/postfix/main.cf as
# described in the article
/etc/init.d/postix start
/etc/init.d/courier-imap start
# start sending and reading mail

Re:Courier

[dusanv]

it would crash all the time and give me all kind of troubles

That's strange. I am using Courier both at home and at work as well as a friend of mine and there are no problems. There is a mailing list for courier. Did you try getting help there? Well, I am glad you found something that works for you...

Re:Courier

[dusanv]

Not that there is anything wrong with Postfix but Courier can do everything Postfix can and a lot more (IMAP among other things as you have noted yourself). Is there any advantage to using Postfix for SMTP related tasks instead of Courier?

Mmmm...postfix

[ender-]

I for one have used sendmail and postfix, and have tried qmail in the past [sorry, didn't like it].
I finally settled on Postifx. I really like it. I feel I don't have to jump through nearly as many hoops to get it running well as I did with sendmail. I certainly didn't need a 900 page 'bat' book to get postfix running. :)

With that said, to each his/her own. Use what you want, I'm sure people love qmail for reasons that make sense to them, and the same with exim and sendmail. Those of you who would flame me or others because of our choice of email servers all I can say is "Get over it..."

Ender

Re:Mmmm...postfix

[delcielo]

I agree.

At the height of our SPAM problems, we were getting 100k e-mails per day, rejecting about 90k using our own 420k line list, checked against 500 exceptions. We were also using about 10 anti-spam lists, doing several header and body checks, and running the whole thing on a pc that averaged about 5% load average.

I'm a big fan of Postfix. Wietse Venema is a smart man.

Stupid question...

[Skirwan]

Is Sendmail still used because it ships as the default mailer with almost every flavor of Unix?

Yes. Yes it is.

Just like Internet Explorer is still used because it ships as the default browser with every flavor of Windows, and Apple Mail is still used because it ships as the default mail client with every flavor of Mac OS X, and so on. This surprises you because...?

--
Damn the Emperor!

Re:Stupid question...

[hackstraw]

That and also its a bitch to get sendmail uninstalled from a package based system (rpm or deb). I havn't tried in a long time, but when I did, I could not install a new mailer because it conflicted with the old mailer, and I could not uninstall the old mailer because things like cron depended on it, and so on.

Re:Stupid question...

[Basje]

No it doesn't. Debian has Exim as it's default MTA.

Re:Stupid question...

[Anonymous Coward]

Arguably MSIE and Apple Mail are not as bad compared to alternatives as sendmail is.

Some people may feel that sendmail isn't that bad, but considering that it is probably the product with the longest history of security problems...

Re:Stupid question...

[mindriot]

Yep, and it's quite powerful and has not suffered too much from exploits. Personally, I've been running on exim for quite a while, and exclusively after I ditched my last Red Hat installation in 2001.

But in many cases postfix might be preferable since it is even easier to use... although I think exim configuration is simple and well-documented. Bigger servers running Sendmail should at least consider switching to exim...

Re:Stupid question...

[Anonymous Coward]

So what part of "almost" don't you understand, exactly?

Re:Stupid question...

[johnnyb]

Red Hat has "alternatives" set up, which make it real easy to switch MTAs. For RH8, I only have to do the following:

alternatives --set mta /usr/sbin/sendmail.postfix

service sendmail stop

chkconfig sendmail off

service postfix start

chkconfig postfix on

And you now run Postfix!

Re:Stupid question...

[Basje]

Yes, I prefer postfix myself.

The only thing missing with postfix is native authenticated smtp. One needs to authenticate through sasl to use it, and I don't trust sasl. I'm not implying that sasl is an insecure product by virtue of bugs, but there are too many variables to make me confident that I can configure and deploy it securely.

Re:Stupid question...

[mgedmin]

Debian has it even easier:

sudo apt-get install postfix

That's it.

Re:Stupid question...

[Bakaneko]

Actually "alternatives" from RedHat is a reimplementation of Debian's "alternatives"...

Re:Stupid question...

[angulion]

SuSE has for some time defaulted to Postfix..

Debian may switch

[mcgroarty]

Debian has been installing exim by default forever now. It's also remarkably easy to use and configure, and it's just as versatile as sendmail.

There's been discussion about switching to postfix as the default for new installs however, and it may even be a done deal. A lot of arguments have been tossed about for this, however the biggie seems to be its simplicity: with something as complex as exim or sendmail, there are just more opportunities for something to go wrong. Postfix is quite enough for most users.

Re:Debian may switch

[HoserHead]

If you've bothered to read any of that particular thread ("default MTA for sarge"), you'd have found that Postfix isn't actually very likely to be the default MTA for any Debian release any time soon. exim4 is simple and powerful, and what's more, it builds on the legacy of exim as the default mailer in Debian.

There isn't really any compelling reason to switch away from exim, and that more than anything else is likely to leave exim as the default for years to come.

Re:Debian may switch

[mcgroarty]

Please read the thread you point to.

Re:Debian may switch

[drunkentiger]

But lots of exim's features (and ease of configuration) may tip the scales for some people over postfix, courier or sendmail.

For example, exim has the ability to block mail by referencing the DNSBL (DNS block lists) or the RBL (realtime block lists) for hosts known for spam relays. See exim's rbl howto.

Postfix is good, but it comes down to what the sysadmin believes is a good tradeoff between features and security.

Re:Debian may switch

[pHDNgell]

For example, exim has the ability to block mail by referencing the DNSBL (DNS block lists) or the RBL (realtime block lists) for hosts known for spam relays. See exim's rbl howto.

Is this supposed to be an advantage over postfix? You can use RBL type lists for general mail classification in postfix (and I do).

I'm amazed at how many people are spouting things you can't do with postfix who clearly haven't tried. Oh well, if you can't beat 'em:

I've never used postfix, primarily because I have a need for SMTP and I heard it doesn't support SMTP.

not only qmail but courier mail as well.

[xeeno]

There ARE others out there you know.

Re:not only qmail but courier mail as well.

[batkins]

Um, yes, there are others and courier isn't one of them. Courier is an IMAP server. We're talking about MTA's here.

Re:not only qmail but courier mail as well.

[Daerr]

Courier is an MTA as well.

<a href="http://www.courier-mta.org/">
http://www.co urier-mta.org/
</a>

Re:not only qmail but courier mail as well.

[Feyr]

better get your facts straights

www.courier-mta.org

full blown email server: MTA, filtering, pop3, imap and webmail, all neatly packaged (and written) by the great Sam. works like a charm too

Alternatives

[rf0]

Postfix is cool and words but so does Exim, Qmail et al. Sendmail is a large code base that has devloped over many years but its secret is its ability to do alomst anything required. Of course its almost impenterable if you don't want to learn rule sets but you can just get the Orielly book which is only about 1000 pages long :)

Rus

Qmail just works

[esconsult1]

The combination of Qmail and Vpopmail is perfect for our company with multiple virtual domains. No other solution comes close.

If you run virtual domains, Postfix or Sendmail is not an option, especially if you dont want to deliver john@d1.com and john@d2.com to john@localhost. Heck, with virtual domains, you don't want to have user accounts anyway.

I wish there were other easy to use open source options, because Qmail really suffers under Sobig at this point.

Re:Qmail just works

[Anonymous Coward]

Huh, that's funny. I'm going to have to check my Postfix config and figure out why all my virtual domains are working.

http://www.freebsddiary.org/postfix-virtual-doma in s.php

Re:Qmail just works

[kill-hup]

If you run virtual domains, Postfix or Sendmail is not an option, especially if you dont want to deliver john@d1.com and john@d2.com to john@localhost.

Obviously, you haven't heard of virtusertable...

Re:Qmail just works

[InsaneGeek]

What you talking about Willis?

Sendmail & Postfix support virtual domains with no problems.

Postfix: http://www.postfix.org/faq.html#virtual_domains

Sendmail you can do it extremely easily with the virtualusertable (and I have for years and years)

Re:Qmail just works

[esconsult1]

Obviously, you haven't heard of virtusertable...

Actually, I have. It still requires you to have user accounts on the box, or to forward the mail to some other mail server.

AFAIK, with virtusertable, you can't have multiple "john" accounts on the box. I could be wrong, or horribly misinformed, but to get the functionality of vpopmail in bare Postfix or Sendmail has not been done so far. In fact, you can't even get that functionality with bare Qmail either.

Re:Qmail just works

[hackstraw]

Postfix can do virtual domains with sasl authentication and imap/pop daemons from Project Cyrus.

Its also real cool because you can use a mysql database to manage the accounts over the domains so that the users do not need real shell accounts.

Re:Qmail just works

[Anonymous Coward]

While sendmail and exim both suffer from the weakness you mention with regard to not supporting real virtual users (unless you are using Cyrus IMAP in which case they all do) you are wrong about postfix.

Postfix has supported vpopmail type setups for a very long time.

I have boxes running using it - actually a customised version as vpopmail is excessive for the requirement.

it just works - beautifully.

Re:Qmail just works

[tangent3]

I followed this guide to setup a an email server with multiple virtual domains, using a combination of postfix, courier-imap, and other cool stuffs.
Users are managed using a mysql database and some PHP tools I wrote.

Re:Qmail just works

[cleverhandle]

Actually, with a new version of Cyrus IMAP, you can have proper virtual domains with Sendmail - no virtusertable, no user accounts.

Re:Qmail just works

[thogard]

your mail box users are real users on your box? why?

Re:Qmail just works

[omega9]

MOD PARENT UNINFORMED.

Typical "I never figured the others out and only got this one to work, so the others suck" post.

FFS... Sendmail and Postfix not having virtdomain support?

Re:Qmail just works

[TheSync]

Don't forget the excellent combination of Qmail with TMDA for flexible challenege-response spam blocking.

Re:Qmail just works

[pHDNgell]

AFAIK, with virtusertable, you can't have multiple "john" accounts on the box. I could be wrong, or horribly misinformed, but to get the functionality of vpopmail in bare Postfix or Sendmail has not been done so far. In fact, you can't even get that functionality with bare Qmail either.

No it doesn't. You're stuck at the wrong layer. I did this with sendmail before I did this with postfix.

I haven't had local users on a mail server at all in many users. Why should someone have a UNIX account on my mail server just to read mail? That's a security hole in my opinion.

Re:Qmail just works

[HopeOS]

Assuming both john@foo.com and john@bar.com are different people, and for whatever reason, both of their mail is stored locally, you can use the virtusertable in conjunction with the aliases file.

/etc/mail/virtusertable:
john@foo.com john-foo
john@bar.com john-bar

/etc/aliases:
john-foo: john_foo_mail
john-bar: john_bar_mail

Your local users would therefore be john_foo_mail and john_bar_mail. Substitute their login id's as appropriate. The nice feature here is that if they move to another system, you can edit the aliases file to forward their mail as necessary.

I've never had to deal with mail for people who did not have actual login accounts on some machine, so for large installations, I'm definitely not an authority, but for the six or seven domains and thirty odd email accounts that I host, this works fine.

Good luck!

-Hope

Re:Qmail just works

[papason]

We run qmail and have not suffered a bit w/Sobig.F
Maybe some explanation of what syptoms you see ?

Wait for the "backlash"

[heironymouscoward]

I'm expecting certain people to make much of this news, citing the "insecurity that comes with open source".

All it demonstrates is that large complex pieces of software are inherently more difficult to secure than smaller simpler ones.

Sendmail is great but we switched to another MTA about four years ago, also because Sendmail had exploits.

Re:Wait for the "backlash"

[Anonymous Coward]

All it demonstrates is that large complex pieces of software are inherently more difficult to secure than smaller simpler ones.

Especially large, complex pieces of software originally written over a decade ago. BIND, Sendmail, and WU-ftpd have all been major problems over the past decade because they were written at a time when security wasn't important. They've tried to upgrade them and incorporate security into these products since then, but you can't easily patch a rusty ship at sea. At least with BIND 9 they did a rewrite and got it audited by an external group and it's been fairly secure.

Re:Wait for the "backlash"

[Overly Critical Guy]

All it demonstrates is that large complex pieces of software are inherently more difficult to secure than smaller simpler ones.

What happens to this when it's Windows, and it's suddenly "WINDOWS WAS DESIGNED FROM THE BEGINNING WITHOUT SECURITY IN MIND!!1." You know, the standard hysterical absolutes.

Oh? You mean nothing is 100% secure? You mean Linux has more monthly than Windows? People need to get off their high horse and gain some perspective.

Re:Wait for the "backlash"

[Anonymous Coward]

Considering that other open source MTAs (postfix, qmail, exim, courier) have a better security history, it's a problem very much specific to sendmail.

Sendmail would benefit considerably from a redesign. But that probably isn't going to happen, because sendmail is used by those who want it to work the way it always has. Better alternatives are already available for those who are comfortable with something slightly different.

Re:Wait for the "backlash"

[dspeyer]

Sendmail vs Windows makes an interesting comparison.

Both were designed as insecure -- sendmail because the net was so small in those days that you could trust it, windows because it was intended for single-user off-net PCs.

Neither is securable. Both need to be replaced while maintaining backwards compatibility. Windows got Windows NT, Sendmail got qmail, postfix, exim and others.

Windows NT is still terribly insecure, qmail/postfix/exim are rock solid. Why?

Because the mail compatibility relies on a well thought out open standard (RFC822) whereas Windows relies on an entire slapped-together API.

So stop being overly critical and learn something! :-)

Re:Wait for the "backlash"

[johnnyb]

Actually, most people levy the same criticisms of Sendmail that they do of Windows. And guess what? Since you have choice in the Linux world you have both distributions that ship Sendmail AND distributions that ship stuff that's, well, actually secure.

Re:Wait for the "backlash"

[Sanction]

"Oh? You mean nothing is 100% secure? You mean Linux has more monthly than Windows? People need to get off their high horse and gain some perspective."

Ahh, and now everyone who has ever had training in selecting comparable sample sets is laughing their asses off at you...

Try taking a few courses in statistics or symbolic logic, then come back.

This is big news

[Anonymous Coward]

And for folks who didn't know that Postfix has advantages over Sendmail, here's a wrapup of other recent events:

Japan surrenders; war over
JFK Assassinated in Dallas
Moon landing a success
Wall falls, Berlin united

Slashdot. For up-to-the-minute news.

isnt' now the time to find your favorite spammers

[Anonymous Coward]

email server, and well, make it stop serving email?

daemonless operation needed

[Anonymous Coward]

Until postfix doesn't cope with daemonless, on demand operation (no daemons running; user invokes the (fake-)sendmail-command via e.g. 'mail' oder 'pine'), postfix is nothing for me.

The mails are queued, yes, but not immediately sent.
I am not willing to run and administer another 4 processes on simple, dumb workstations.
Sendmail was easy - it just would send mail to the smarthost. Finito!

Re:daemonless operation needed

[Anonymous Coward]

if all you need is send mail to a smarthost use nullmail. Finito!

we need to realize...

[Sfing_ter]

There are many good and secure mta's out there, sendmail has the larger base and was created by one of our demi-gods. That and it is "the" mta for most of the Unix'. Don't bash, just explain why you want jihad for your mta then go back to your square-headed wife.

aMy postfix is extremely secure

[Gyorg_Lavode]

My postfix installation is extremely secure, I can't get it to receive any email at all. If anyone could help me unsecure it by teaching it to deliver mail to my computer, could they shoot me an email? (bassettgabriel @qwest.net). I'm not a system administrator, just a guy w/ linux at home and the simple setup just isn't working for some reason.

Re:aMy postfix is extremely secure

[kfuq]

webmin can help "1st time" users setup alot of stuff easily on a *nix box..

Re:aMy postfix is extremely secure

[Anonymous Coward]

how would people want to respond if you cannot receive mail? ;-)

Re:aMy postfix is extremely secure

[Gyorg_Lavode]

I would have very big issues if I was administering qwest.net on my home machine =)

Re:aMy postfix is extremely secure

[lmfr]

Not even from localhost? If you can, then probably your MTA is configured to listen only on localhost, so change it:

/etc/postfix/main.cf: inet_interfaces = all

And this isn't an advertisement how?

[Apostata]

Sorry for the flamebait, but how would it seem if an "objective" news-headline site said the following:

"The Dodge Ram has had a number of documented problems over the years. However, for less problems, try the Ford Explorer."

Come on...

Re:And this isn't an advertisement how?

[Anonymous Coward]

Not to be a grammar Nazi (Yeah, I know, here it comes...), but that should have read

However, for fewer problems, try the Ford Explorer.

And, to be realistic, perhaps for fewer problems the person should try a Toyota over a Dodge or a Ford.

Re:And this isn't an advertisement how?

[Anonymous Coward]

OH shoot, to be fair, I should also add that grammar aside, I found the original reply to be a perfectly reasonable and valid comment, and agreed with it completely. You made a good point.

Re:And this isn't an advertisement how?

[omega9]

You can't have competition unless there are several products that fill the same basic need. And from spending way to much time on /., it seems that we're generally in support of competition.

So, if we're for competition, we're for the idea of several available scratches for the same itch. People being who they are, some of us will like one option over the other and develop a preference. Once you've got options and preferences you can have a discussion (and eventually a flamewar).

An article comes up concerning Postfix and deserves some possible attention. The most natural way to begin is by a comparison to similar programs, one of them bening Sendmail, and Sendmail having recently (3'03) been issued a security warning.

I don't see what's strange about any of this.

Re:And this isn't an advertisement how?

[proj_2501]

It would be ridiculous, because the Ford Explorer is not a pickup truck. No, neither is the Explorer SportTrac.

Re:And this isn't an advertisement how?

[koehn]

If I was a consumer paying for the service, I might think there's an ulterior motive. Since I can use either one for free, at no cost beyond the inevitable pain of installing an MTA, it's an alternative, not an advertisement.

However, had they listed other alternatives like qmail et al, it would appear lest biased.

All that said, I use sendmail 8.12.9 as my MTA/MDA, which I compile myself and build my own .mc for, and while I agree that it's complex, there's no configuration I can think of that sendmail won't support. I have a fairly simple setup (5 domains, some virtual users, aliases, multiple MXs, procmail, TLS) and the hard part was learning how the internet handles mail (MX records, SMTP, TLS, etc), not learning how to make sendmail do what I want. Google got me what I needed to know, and quickly.

I may switch MDAs soon, so that I don't have to use mbox on the back end (cyrus is looking like the most likely target because of its DB mail store), but I think I'll stick with sendmail since I already know it. It hasn't had a new revision in a fairly long time (3/31), and it's been extremely reliable.

Re:And this isn't an advertisement how?

[evilviper]

Maybe it would sound like it was from the same site that regularly says:

"Microsoft Windows has had a number of documented problems over the years. However, for less problems, try Linux."

Popular open-source packages with security holes

[shoppa]

Citing a long history of security holes and patches is one way of justifying going with a less-populare but maybe more secure package. Right off the top of my head are these long-standing open-source packages with long histories of security holes:

• wu-ftpd. Most recently known for the crack of alpha.gnu.org.
• sendmail. "Not having sendmail is like not having VD", according to popular wisdom
• vixie-cron. I don't even know of a "virgin" distribution of this, which is probably a good thing; all the Linux vendors have their own set of extensive patches to vixie-cron.

There are multiple choices for replacing each of these, most of them a written-from-scratch replacement. Not all of these are perfect, either, but at least they're less popular, so (hopefully?) less likely to get hacked.

I personally run fcron, postfix, and proftpd instead of the more popular packages. I don't honestly claim that they're any more secure, in all cases they were mostly personal choices having to do with cleanness/installation ease.

Root Prompt Redundancy

[gwydi0n]

I find it quite amusing that in the Root Prompt news box that I have at the top of my right hand sidebar, the second news item is titled "Postfix: A Secure and Easy-to-Use MTA"

Pain?

[AdEbh]

Glenn Graham demonstrates how Postfix gives you most of the power with a fraction of the pain.

Don't know about the "most of the power" bit but I could hit myself in the head and still have "a fraction of the pain". It's sendmail for f**ks sake!!!

- Alex

SMTP

[FrostedWheat]

SMTP is a fairly simple protocol, so why are there so many security problems with mail servers? Am I missing something obvious?

Re:SMTP

[shoppa]

Sendmail started out with lots of regex ability because it was designed from the start to route mail not only through SMTP but into/out-of other mail systems - i.e. uucp mail, bang paths, corporate-internal mail systems, etc. So it needed to be able to dynamically rewrite and forward mail to non-SMTP systems.

This configurability honestly isn't needed today in 99% of cases. The number of people I know who need a bang-path to get mail to them (uucp) is now down to two.

But the ability to do things dynamically in sendmail through its configuration file isn't necessarily a weakness, the regex abilities are often used for other things today.

Re:SMTP

[FrostedWheat]

Troll? Honest question! Sheesh

Re:SMTP

[hungarian_sausage]

Which has incidently caused a DoS security hole in Postfix versions up to and including 1.1.12! Read this advisory from packet storm. Apparently you can mangle the adress enough to cause Postfix to shutdown and simply restarting won't solve the problem. You have to remove the offending e-mail from the que.

Re:SMTP

[Anonymous Coward]

Sendmail is old, and suffers from bad old coding habits of people who have been around since before buffer overflows were considered a problem.

Besides, a problem with any server-like program, independent of the protocol and service is fact that they handle data from an untrusted remote source which may be malicious. Good, security conscious programmers always treat data carefully, especially if it is from an outside source, but bad programming habits are common.

Re:SMTP

[Synn]

Keep in mind that sendmail had to evolve over decades and various network protocols, like UUCP. Computers in town A would dial computers in town B that would dial to computers in town C and pass mail, files, shell commands and so on.

Sendmail was even smart enough to prioritize the mail and do things like delay the delivery for when the long distance calls were cheapest.

It's not SMTP itself so much as the evolving mail systems that surround SMTP. Like today we have spam filters and virtual domains.

Re:SMTP

[A Masquerade]

SMTP is indeed a simple protocol (ignoring extra complications like DSN support and odd ESMTP additions). If you are designing an SMTP relay then things are nice and simple to secure.

The problem comes that users want their mail delivered to them - into their spool or directory, as their UID. So you need to have some method of changing UID to the destination UID, so you need setuid and suddenly any security hole you have loses you the game.

Sendmail & exim are the one big daemon that runs setuid design - so any security holes gives you real problem. Postfix and qmail have better privaledge separation, so you will tend to lose less if they are broken.

What's lost in postfix?

[Anonymous Coward]

Can someone post a list of the things we LOSE going to postfix? I'm interested, but I'd like to be able to check to see what I'm losing, so I can compare that to what I'm using.

The reason why

[Overly Critical Guy]

This article was really about a hole in sendmail. However, with all the so-called "Microsoft holes" Slashdot has been reporting non-stop about, they needed to immediately offer a working alternative so they can say, "It's not that big a deal; here are well-known alternatives," and play down the hypocrisy a bit. Meanwhile, there are just as many alternatives to Outlook, but that doesn't stop people from declaring Windows unsafe (never mind that SoBig is a user-transmitted worm). They were just trying to play down the seriousness of it. "You should have been using postfix!"

Just had to say it. Mod me down if you disagree.

Re:The reason why

[Anonymous Coward]

Meanwhile, there are just as many alternatives to Outlook, but that doesn't stop people from declaring Windows unsafe (never mind that SoBig is a user-transmitted worm).

Sure, but that doesn't change the way that Microsoft products are viewed (e.g. as unsafe). Blaster didn't help much either...

It's easy to win an argument by changing the subject.

Re:The reason why

[_Sprocket_]

This article was really about a hole in sendmail.

No it isn't. Two introductory paragraphs talk about sendmail holes, and its inglorious history. Then the vast majority of the article talks about Postfix configuration.

Sendmail vulernabilities are the hooks, not the subject.

However, with all the so-called "Microsoft holes" Slashdot has been reporting non-stop about, they needed to immediately offer a working alternative so they can say, "It's not that big a deal; here are well-known alternatives," and play down the hypocrisy a bit.

Sorry. I missed the Unix (Solaris, *BSD, OSX, Linux, etc) variations of SoBig, Blaster, Nachi, etc. I had no idea these recent worms attacked more than Microsoft infrastructure.

Meanwhile, there are just as many alternatives to Outlook, but that doesn't stop people from declaring Windows unsafe (never mind that SoBig is a user-transmitted worm).

Yet, Outlook is what is being commonly used and exploited. Sure - there are alternatives (as long as they don't make the same mistakes Microsoft did... or use the same bits of technology). Its a shame that, for one reason or another, they aren't more commonly used.

Of course, its not all about Outlook. There's been more going on in the last few weeks than SoBig. Or is there a variation of Blaster or Nachi that propogates via email?

They were just trying to play down the seriousness of it. "You should have been using postfix!"

Or it could have had something to do with dates. Namely, the Sendmail exploit mentioned was published on March 3. This article has a Aug 21 date.

But then - there's that really annoying Sendmail worm that hit everyone just after the Blaster/Nachie and SoBig combo caused so much ruckas. Thank gawd Slashdot and O'Reilly were there to cover it up with a well-timed article on installing and configuring Postfix.

Re:The reason why

[Overly Critical Guy]

*cracks knuckles*

No it isn't. Two introductory paragraphs talk about sendmail holes, and its inglorious history. Then the vast majority of the article talks about Postfix configuration.

Duh. That's what I was referring to.

Sendmail vulernabilities are the hooks, not the subject.

I know. And my point was that this article should really have been about the hole in sendmail, but instead, Slashdot covers it up by drilling home an alternative, just to drown out the news of the hole.

Sorry. I missed the Unix (Solaris, *BSD, OSX, Linux, etc) variations of SoBig, Blaster, Nachi, etc. I had no idea these recent worms attacked more than Microsoft infrastructure.

Apparently, you miss a lot of vulnerabilities. Blaster was patched already. As for SoBig, that's a user-transmitted worm. If everyone used Linux and an e-mail client, guess what? Stupid users would still run the attachments. Sorry to POP that bubble.

Or it could have had something to do with dates. Namely, the Sendmail exploit mentioned was published on March 3. This article has a Aug 21 date.

Interesting that Slashdot ignores it for so long.

But then - there's that really annoying Sendmail worm that hit everyone just after the Blaster/Nachie and SoBig combo caused so much ruckas. Thank gawd Slashdot and O'Reilly were there to cover it up with a well-timed article on installing and configuring Postfix.

No kidding; otherwise, we might have a headline about a hole in an Open Source app, and that wouldn't be consistent with the necessary string of "Microsoft holes" that Slashdot wants to drive page hits. Instead of a headline about a Sendmail hole, it's magically transformed into an informative article on Postfix. Nice! Hook, line, and sinker.

Re:The reason why

[Nerull]

Wow, this must be some new defenition of 'ignore' that I was not aware of. This hole was posted on Slashdot back in March when it was found, nice try, but no cigar for you.

Re:The reason why

[Navarre]

lilo: linux init=/bin/bash - Instant root without password

"Enter Lilo Password:"

Re:The reason why

[_Sprocket_]

Apparently, you miss a lot of vulnerabilities. Blaster was patched already. As for SoBig, that's a user-transmitted worm. If everyone used Linux and an e-mail client, guess what? Stupid users would still run the attachments. Sorry to POP that bubble.

No - I've seen those. I'm not claiming that Microsoft is the only one that gets exploits. But lets call a spade a spade. This recent spat of worms and viruses live entirely in Windows. They are, in fact, Microsoft vulnerabilities and Microsoft worms.

Sure - even with Linux you're going to have "stupid users". Its just that they will have to be more motivated to hang themselves. Even the nice GUI Linux email clients have taken sane approuches to handling data (to include HTML email).

Or it could have had something to do with dates. Namely, the Sendmail exploit mentioned was published on March 3. This article has a Aug 21 date.

Interesting that Slashdot ignores it for so long.

You may be suprised to find that Slashdot covered this vulnerability on March 3rd. The day it was published. This is the same vulnerability being mentioned here. In August. In an article about Postfix.

Hardly ignored. Or covered up.

Oh. And, of course, there is no Sendmail worm wrecking havock with the Internet and private networks.

The Sendmail Book Is a Crime Against Humanity

[FreeUser]

I ditched SendMail because it made me uncomfortable as an administrator. Yes, I could get it working "good enough" that I wasn't a relay, but because of the arcane command file structure I wasn't satisfied that it was tuned the way I wanted it. (BTW, I had hand-coded a sendmail.cf from scratch before, and made it work, but that was when I had a whole day to spend on the project.)

I agree, sendmail has a steep learning curve, and I don't have to change mail settings often enough for it to sink in and become instinctual knowledge the way most other things have. For that reason, as well as the security issues others (and the article) have raised, I too have switched to postfix.

However, a friend of mine who administers numerous networks for clients swears by sendmail, and claims that it is far easier to learn and administer than the one, thick O'Reilly book on sendmail would have you believe. Indeed, he accuses the book of actually obfuscating administrative techniques for sendmail, to the point of calling it a "crime against sendmail and humanity." (He is sometimes prone to the melodramatic).

I haven't delved as deeply into sendmail as he has, so I cannot personally confirm that, once the epiphany hits, sendmail becomes dramatically more straightforward than the Sendmail book's coverage, but I do concur that, with my moderate knowledge and a copy of said book on my bookshelf, the current state of the software and documentation leaves a lot to be desired in terms of getting things going fairly quickly and simply, which programs like qmail, postfix, and others address nicely.

It is, however, IMHO a shame to give up some of the more advanced features of sendmail (and its amazing flexibility), such as milters, so here's hoping they either work their way into postfix et. al. in a more accessible fashion, or that (assuming my friend is accurate in his allegations) someone writes a more accessible book on the subject of sendmail.

In the meantime, the O'Reilly book seems to be the only book on the subject, so if it is really the reason so many of us get discouraged with sendmail and move on to easier, if less flexible, MTAs, then perhaps a second book covering the subject would be in order.

Not Debian

[autechre]

I think they switched which MTA was installed by default between Potato and Woody, but neither one was Sendmail. And of course, they have you configure it when it's installed, and you can just tell it to not run the daemon and deliver local mail only (so you still get important stuff sent to root).

I've used Postfix, and like it very much. Currently, the email server for which I'm responsible runs Sendmail, because I haven't had time to figure out how to port the virtusertable over to Postfix.

As for hackstraw's comment, Debian makes it easy because packages depend on "an MTA", and all of the MTAs conflict, so you just use APT to install your MTA of choice, and it replaces the existing one.

Re:Not Debian

[dabadab]

I think they switched to Exim by Potato, the previous default was smail.

two great stories that go great together

[knick]

A Washington Post article says Microsoft Windows is insecure by design. Quote: 'Between the Blaster worm and the Sobig virus, it's been a long two weeks for Windows users. But nobody with a Mac or a Linux PC has had to lose a moment of sleep over these outbreaks -- just like in earlier "malware" epidemics.

Of course, they were too busy upgrading/patching Sendmail.

Re:I use

[autechre]

Really? If you don't have any MTA on your workstation, how do you get all of the email messages to root telling you that things are wrong with your system? Or might that be why you are reinstalling all the time? :)

You could try Debian; not only does it not install Sendmail by default (I think they're on Exim now; used to be smail, IIRC), but it's designed to only have to be installed once, ever, which solves your other problem.

Old News

[Accipiter]

This is a security problem from March. Sendmail 8.12.9 was released on March 31st, correcting this problem.

Why is this being posted nearly half a year later? Solely to advertise Postfix?

Re:Old News

[aeoo]

Yes. Postfix should be a lot more popular than it is now, and so it could use more advertising.

Re:I use

[matuscak]

You dont mention which distribution youre using, but FWIW, on Red Hat when sendmail is installed it only accepts connections from localhost.

Postfix virus filter

[hey]

I love postfix. A while ago I added a filter to
stop executable (ie virus) content. And nobody
in my company got the recent SoBig virus. Here's the line:

/(filename|name)=".*\.(asd|chm|dll|com|exe|hlp|hta |js|ocx|pif|lnk)"/i REJECT Executable content not allowed

Re:Postfix virus filter

[Make]

you forgot .scr I think.

Re:Postfix virus filter

[Anonymous Coward]

You should add ".scr" (win32 screenblanker)

Re:Postfix virus filter

[frankie]

/(filename|name)=".*\.(asd|chm|dll|com|exe|hlp|hta |js|ocx|pif|lnk)"/i REJECT Executable content not allowed

Your list is way too short. There are lots more executable file extensions that should be blocked at the border.

Re:Postfix virus filter

[hey]

Ooops, you are right. I have another line that catches other extensions (I just forgot to post it here). My second line:

/(filename|name)=".*\.(scr|shb|shs|vb|vbe|vbs|wsf| wsh)"/i REJECT Executable content now allowed - you can place it in a zip

Other example scripts can be fond on the left-bottom of
here

I prefer to keep it simple. Ie not filtered for spam strings, etc. Just stuff catching content that is very very obviously bad.

Re:Postfix virus filter

[ryanvm]

Out of curiousity, does the REJECT message get sent to the host at the other end of the SMTP session or does it send an email to the "alleged" sender?

I ask because I'm tired of getting automated reprimands from servers for SoBig viruses that I never sent. (SoBig spoofs the sender.)

Re:Postfix virus filter

[cloudmaster]

The reject is sent back as a reject code (something in the 5xx range) to the sending mail server. That mail server will then treat it like any other reject message, probably by sending the message back to the return-path address (which is likely the "from:". It's not quite the same as sending a full email to the sender, but is probably just as annoying.

That's not much that can be done about that, though, as this is the same mechanism through wich you get notified that your intended recipient has gone over their mailbox quota or that you've mispeldd their email address. :)

Re:Postfix virus filter

[cloudmaster]

Even more fun than than that (in newer versions o' postfix) is this one:

/^Content-(Type|Disposition):.*(file)?name=.*\.(as d|bat|chm|cmd|dll|exe|hlp|hta|jse|lnk|ocx|pif|scr| shb|shm|shs|vb|vbe|vbs|vbx|vxd|wsf|wsh)/ REJECT Sorry, we do not accept .${3} file types.

Mostly I like that because you include the actual extension in the return message and it allows the string "file=blah.exe" in headers other than those two that might cause a problem

Note that I left .com out of the list because that one also catches messages with URLs attached (like, http://domain.com/). Since we mail URLs a lot where I work, that's not so good to block.

Re:Postfix virus filter

[oobar]

...and now thanks to the likes of SoBig, you get to contribute to the problem of filling up random people's inboxes with meaningless junk. If you're going to do this, you should also implement a rule to ignore or delete known email worms, otherwise you're just part of the problem.

Don't forget BIND.

[autechre]

First of all, the GNU compromise was a local user, not a result of the FTP daemon. They do not run wu-ftpd (and neither should you; in fact, don't run an FTP daemon at all, unless it's only anonymous, and then you could use publicfile).

Also, don't forget about BIND. This is pretty much the exact same situation as Sendmail vs. Qmail. The mainstream app is a big fat binary, and so is more difficult to audit. Why did they design it this way? Isn't this against the spirit of Unix?

To be fair, DJB's ideas of where binaries should go in the filesystem is...er. But you can put everything in /usr/local and run daemontools out of /var/service if you want (which is what I do). And if his license bothers you, there are other implementations arising, such as MaraDNS.

Re:Don't forget BIND.

[shoppa]

My information that the GNU alpha.gnu.org compromise was due to wu-ftpd came from this quote posted to slashdot after the compromise:

iSEC Security Research reports that wu-ftpd contains an off-by-one bug in the fb_realpath function which could be exploited by a logged-in user (local or anonymous) to gain root privileges. A demonstration exploit is reportedly available.

BIND was originally was an implementation in C of Jeeves, which was the original PDP-10 DNS implementation. This explains some of the cruft (but in fact I don't feel that BIND has all that much cruft).

Re:Don't forget BIND.

[shoppa]

It turns out that the wu-ftpd report for the crack of alpha.gnu.org on slashdot was in fact wrong, and in fact alpha.gnu.org wasn't even running wuftpd. It was "just" the linux kernel ptrace vulnerability and a local user.

Re:Don't forget BIND.

[autechre]

BIND 9 is supposed to be a complete rewrite, though it's by some of the same people (and Vixie cron, i.e. Paul Vixie) that worked on BIND 4 and 8, and it's still one big binary instead of several smaller ones.

Re:Milters? (MOD PARENT UP)

[A. Lynch]

This is good info... Always be sure to read the docs fully before saying X feature doesn't exist in Y product.

MTAs for desktop/client installations

[Florian]

For running an MTA on a desktop/client PC, I strongly recommend solutions like Nullmailer or, for computers with permanent Internet connectivity, ssmtp. Both work as just local gateways/bouncers to a remote SMTP server; they don't open any network ports and thus prevent remote exploits/attacks/spam relaying by design. Nullmailer offers local spooling (important for dialup connections) while ssmtp bounces everything immediately to the smarthost. Both are very small (ssmtp: 22k, nullmailer-send: 25k), ridiculously simple to configure even for people with low administration skills, both provide sendmail-compatibility to work with MUAs like mutt.

(Offtopic: A similarly nice, elegant solution for desktop/clients PC printing is pdq, which unlike lpd and cups runs only as a local spooler without opening a network port, and is lean (65k), dead-simple and functional. With nullmailer/ssmtp & pdq, I managed to close all ports (except of course SSH) on my two desktop PCs under Debian GNU/Linux without any firewalling. AFAIK, Debian is the only OS offering all the aforementioned pieces of software as part of its main distribution.)

Re:MTAs for desktop/client installations

[Anonymous Coward]

Gentoo has all three.

Just mentioning. I seem to also remember using them on a recent Red Hat box, though I can't say for sure if they were part of the distro.

Exim for me

[lordrich]

Well I'd previously used Sendmail, and struggled with it for a week trying to make it do what I wanted.
On Friday, I installed exim, exiscan, clamav, and spamassasin all from source in half a day. And it works perfectly.

Re:Exim for me

[Kevinv]

Yeah me too. I messed with Postfix on Debian for awhile. I got it to work but I wasn't real comfortable that I understood what I had done.

Switching to Exim was great, I thought the config file much better. When I rebuilt my server to Gentoo a couple of weekends ago, I moved to Exim 4.1 and thought the config even better.

Re:Sounds like anyone you know?

[Anonymous Coward]

"Sendmail has a long history of security holes, Sendmail isn't easy to configure. It lacks a user-friendly front end."

Sound like any Operating systems you know? [ehem, MS, ehem]

the difference is that the sendmail dev team FIXES the problems when they are discovered.

instead of calling them "features"

A question

[Overly Critical Guy]

The article should have been about a new sendmail hole, but the headline, for some reason, was about postfix, and the focus of the summary became "switch to postfix; it's great!" Why not just admit that sendmail had a hole and let us discuss it? Open Source has its faults too, y'know. You don't have to rush in and try to play it down by changing the headline to a competing app, giving a bunch of postfix links, and then acting like things aren't that bad.

Re:A question

[BrokenHalo]

The article should have been about a new sendmail hole

Well, Overly Critical Guy, the hole he mentioned was last March, and has been dealt with long ago (IIRC, immediately).

Given that, as the dictum states, all non-trivial programs have at least one bug, and that sendmail is definitely not what I would call a trivial program, what is there to discuss?

It's not as if the developers sat on their hands or hushed the matter up.

turning off confirmation that an addr exists

[Anonymous Coward]

In the example, the mailer says "ok" when a
user is there and something else when it doesn't
following "RCPT TO:". this allows someone to
enumerate users and then later use that info in
a brute force attack against other services.
How to turn off that behavior? (ie make it say
OK for everybody)

Re:turning off confirmation that an addr exists

[tlovie]

There's a flag in sendmail FEATURE(`delay_checks').
This has some side effects that and you should consider reading the help page for delay_checks

With qmail, this behavior is the norm. Additionally, vrfy only returns a "252 send some mail, i'll try my best."
But I'm sure that most people turn off VFRY and EXPN in sendmail.

Re:turning off confirmation that an addr exists

[CoolVibe]

With sendmail put:

define(`confPRIVACY_FLAGS',`authwarnings,noexpn,no vrfy')

in your sendmail.mc

Re:turning off confirmation that an addr exists

[CoolVibe]

that's novrfy without the space. Slashdot just loooooves munging configuration lines up. *grmbl*

.. in scripts?

[iantri]

I'm just wondering.. if you install a sendmail alternative (exim, let's say), will it break any CGI scripts you are using for your webpage that call on sendmail to send mail?

Re:.. in scripts?

[cloudmaster]

postfix is sommand-line compatible with sendmail, even going so far as to include a binary named "sendmail" for just that reason. I've got several CGIs that use that, just because they're no important enough for me to rewrite them.

I can't comment on other MTAs in that regard.

Re:.. in scripts?

[fyonn]

I can't speak for the other mta's, but with exim, no it won't. it emulates most of sendmail's flags and on freebsd, where sendmail is a mailwrapper, it ends up calling the exim binary to send the mail and all is well.

dave

Re:.. in scripts?

[IANAAC]

I can't speak for exim, but I know for postfix, sendmail is just a link to postfix (on RH).

Re:.. in scripts?

[kmactane]

Someone's already replied about how Postfix includes a command-line compatible binary named "sendmail" sepcifically for backward-compatibility. Qmail does the same thing. You can put Qmail's sendmail hook into /usr/bin (or /usr/lib, or wherever your particular system likes to keep sendmail(1)), or you can just tell your CGI and similar scripts to use /var/qmail/bin/sendmail. Either way, it all works just fine.

Re:.. in scripts?

[Anonymous Coward]

qmail has a sendmail wrapper...

mv /usr/bin/sendmail /usr/bin/sendmail.old
ln -s /var/qmail/bin/sendmail /usr/bin

CGIs, other scripts

[Kozz]

I have no problem with the principle idea of switching from Sendmail to something more secure like qmail, postfix, exim, except for the fact that nobody has brought up that nearly EVERY *nix distro has tools that depend on having *sendmail*. Perl modules, bash scripts, all look for the particular behavior of sendmail. Sure, qmail has a sendmail-like wrapper, but I've had problems in sending mail with qmail. Haven't wanted to try anything else yet. It's such a pain to get anything else working, I'd rather use the m4's and keep sendmail working "good enough".

Re:CGIs, other scripts

[Anonymous Coward]

See the reply to the post right above yours. :)

A little slow?

[baomike]

Did I mis something or was this problems dealt with
in MARCH 2003?

Any interesting problems from 2002?

mike

Re:A little slow?

[Anonymous Coward]

Ditto. This isn't very timely news. Didn't we all patch back in March?

This is all just FUD

[BrokenHalo]

Sure, sendmail has had holes found in it from time to time. But we should remember that it has been a very *long* time, and for most people it has been stable as a rock. And I have never yet met anyone whose system has been compromised as a result of these holes. We also shouldn't forget that whenever bugs have been found, they have been fixed immediately (if not before).

Compare this to the antics of "that corporation" who is quite content to leave bugs as "undocumented features". Could be this FUD is just a reaction to that "insecure by design" mudslinging.

Re:This is all just FUD

[wwest4]

Actually, it hasn't been that long. The latest security problems in sendmail were found in March.

Sendmail isn't awful - but some of its code is old, it's complicated, and it's richly-featured. All of these things contribute to an increased risk of bugs and vulnerabilities. In those respects, it's similar to some of those products by "that corporation," except that sendmail issues timely patches and the current developers, at least, care about security from the outset versus considering it as an afterthought.

Re:This is all just FUD

[BrokenHalo]

By a "long time" I meant that sendmail has been in use for one. The rest of your post actually indicates that you agree with me :-).

Re: This is all just FUD

[CryBaby]

And I have never yet met anyone whose system has been compromised as a result of these holes.

And I have never yet met anyone who died of cancer or AIDS. hmmm... those must not be anything to worry about either.

Re:This is all just FUD

[Anonymous Coward]

and for most people it has been stable as a rock.

And about as easy to configure as a rock, too.

Sendmail is a fucking piece of shit, and I'll be glad when the dinosaur admins finally wake up and realise that not everything old is good, and we don't have to deal with it anymore.

Re:This is all just FUD

[SuperFrink]

Sure, sendmail has had holes found in it from time to time. But we should remember that it has been a very *long* time,

Was March that long ago? Here's a historic list of holes and Dan Bernstein's list from 1993 to 1997.

And I have never yet met anyone whose system has been compromised as a result of these holes.

I have. It was last summer. I helped install a new system (Slackware running qmail).

We also shouldn't forget that whenever bugs have been found, they have been fixed immediately (if not before).

Definitely good to see however I still prefer the approaches taken by OpenBSD and qmail. That is: Build it right in the first place.

Sobig? use QMAILQUEUE + qmail-qfilters

[TomatoMan]

You should definitely build qmail with the QMAILQUEUE patch - this opens up a world of possibilities for customizing what happens to mail on the way in to your machine.

Combine this with qmail-qfilters, which allows you to daisy-chain simple filter scripts you can whip up yourself to examine messages and decide what to do with them. The site has some examples.

Sobig.* and other viruses with predictable patterns (like one of eight or so standard subjects and a body with other clues) can be blocked very easily with this.

MX Entry NOT required

[shiao]

According to the article, "Every mail server, or Mail eXchanger, must have a DNS entry for each domain for which it receives mail"

According to dyndns.org FAQ site, " we do not recommend that users wanting a basic mail configuration set up an MX. It is not necessary, and it is possible to make mistakes in the MX record that will cause mail to end up somewhere else."

I have a mail server running Postfix WITHOUT a MX record.

Re:MX Entry NOT required

[doon]

Technically correct. RFC states E-mail is supposed to be delivered to the the host specified in the MX record. If one doesn't exist, then mail will be delivered to the host pointed to by the A record. The problem here is if you don't have an A record for you base domain name, then it won't work.

Re:MX Entry NOT required

[CoolVibe]

Yep, and spammers abuse that a lot. That's why I block every mail that doesn't conme from a DNS certified MX. It might not keep all the spam out, but it certainly does help

Re:MX Entry NOT required

[doon]

My favorite spammer trick it to send to the high order mx's first, in hopes of getting around postini type services. We are an ISP, so we can't be too crazy with our filters. We try to connect back to the mx's/A record for the domain and see if they will accept mail for the from address? If the server doesn't accept mail for them, we put a line in the headers saying so. This way people can decide if they want to accept it or not.

What I like about Postfix

[Webratta]

You know what I like about Postfix? Its ability to easily use MySQL for transports and aliases. There are various howto's listed on the Postfix documentation/howto page and its enough to get you going if you're familiar with both Postfix and MySQL. I'm sure something similar exists for Qmail and the others, but I was suprised at how easy it was to set up with Postfix.

As to the Great MTA Debate, everyone is going to have their preferences and everyone is going to be needing something slightly different. I don't see the point in arguing. Joe Blow likes Qmail more than sex? Great, I hope the security and modularity works out for him. Jimmy Johnson likes the raw power of Sendmail and eats three milters for breakfast? Cool. Myself, I feel more comfortable with Postfix. As long as the sysadmins are competent and the security holes are patched, it's all good in my opinion

Re:What I like about Postfix

[Khlatu_Barada_Nicto]

I think Jimmie Johnson is more worried about Matt Kenseth than sendmail.

Qmail as a relay & smtp "firewall" host?

[Anonymous Coward]

A lot of sendmail users out there are using it not for any form of local MTA, but instead as an Internet SMTP gateway between the lawless outside Internet and their internal MS Exchange / Lotus Domino / Novell Groupwise email systems. None of their email users have local accounts on the gateway machine at all, the mail just flows thru it. These gateways also effortlessly handle complex sets of multiple domain names and stuff like username@domain.one and username@domain.two conflicts where two different users have the same username part of the address. While in transit thru that machine, stuff like Amavis, SpamAssassin and TMDA also act upon the emails flowing thru. These are pretty easy to install, configure and operate with sendmail as the MTA, and more recently, recipies for building such a machine around Postfix have appeared. I'm right now in the middle of building a Postfix-based system to replace my old sendmail-based machine which I've grown increasingly leary of keeping in operation. I run OpenBSD as the underlying O/S on these boxes.

Can Qmail do all these same things with equal ease and are there any good websites out there with detailed, mature step-by-step howto's like there are for sendmail and postfix? Or is the qmail state of affairs such that you still have to first become a qmail guru and then figure out all on your own how to plug all these pieces together manually? The sendmail and postfix based systems today can be set on in pretty short order by someone who isn't a rocket scientist, by simply following readily-available step-by-step howto guides. I haven't found any such guides for Qmail, except for systems that assume that all your user accounts are going to reside on that same machine (unix mail accounts) and that all your clients are going to get their mail via a POP3 or IMAP client. This does no good for those who run internal Exchange/Lotus/Groupwise systems.

Big Lose

[Anonymous Coward]

While it has been years since I have done sendmail, I remember it as being that I lost 2 things.
1) being cracked almost as easily as an XP box (it was 6 years ago), so it required constant update.
2) certain config tools work on sendmail only (but there are much better replacements in postfix and other mtas).
3) the speed and scalability. To this day, sendmail is the better choice for extreme loads, say 5000 users on up.
Postfix is a great choice for home all the way up to small-large businesses. I did not lose any capabilities (in fact gained some new ones).

Postfix+IMAP/POP+Webmin+Usermin=great system

[f1ipf10p]

I presently use this combination for many customers, and will continue to do so.

Postfix is much easier to deal with than sendmail. The configuration file "main.cf" is long but well documented, and it is often the only file you need to muck with.

Add Webmin and you can leave the system in the hands of a local admin without much training.

Add Usermin and basic webmail is painless.

Try it, you might like it.

WoooOOooO

[C_Kode]

Another VI (Postfix) Emacs (qmail) flamewar!

I guess that would make Sendmail SED.

The truth, instead of libel against sendmail....

[Anonymous Coward]

/.

Postfix is great. We all know that, hell, Wietse wrote it and he wrote TCP wrappers for linux.

Postfix has had security holes. They were fixed.

Sendmail can gruesomely difficult to configure because it can do ANYTHING. Most people do not need the raw power of sendmail. However, those that do can spring $100 for the sendmail GUI and it becomes butt-simple to configure. (Please don't bother with the jokes about Marshal's butt).

Sendmail has had security holes. They were fixed. In fact, Sendmail has had more bugs fixed than any other mailer, so we could be just as illogical as the original post and say it is obviously is the most secure mailer.

Qmail's brilliant but difficult creator, Dr. Bernstein, has posted a reward for finding security holes in Qmail. According to rumor, he has refrained from paying that reward by the simple expedient of not accepting any allegations of security holes. I am not qualified to judge the truth of the rumors as I have not studied the code. I prefer the license terms of Sendmail and Postfix (Qmail comes with source code, but is not Open Sourced).

The slashdot denigration of sendmail for security problems is undeserved. Acknowledging and fixing security holes should not be a subject for ridicule, it ought to be admired! Sendmail is ancient, proven, mature, pick your favorite word.

Postfix is excellent. It stands on its own merits and doesn't have to take swipes at sendmail.

If you want to diss sendmail, you should be dissing the monolithic design and dependency on *nix (since the *nix security model SUCKS - suid root is an atrocity).

Having a long record of bug fixes simply means the code has been thoroughly scrutinized and tested under fire!

--Charlie

OpenBSD and Apache

[hdw]

I have to disagree a bit when it comes to the OpenBSD and Apache issue.

Apache is included in the standard install but it's default switched off.
If there's a security problem with Apache, then it's an issue with apache, not OpenBSD.
And nowadays it's even better, when you switch apache on it starts chroot jailed unless configured otherwise.

All showing the fundamentals of security.
If you don't use it, don't start it.
Configure it to run unchrooted _only_ if you have to.
Don't add any modules or functions that you don't intend to use.

This is in stark contrast to several other software/OS/dists that ship with a bells and whistles ready to run and you have to lock them down to get rid them.

// hdw
ps.
I still think it's a bug that OpenBSD allows root login over ssh as default.
ds.

Re:OpenBSD and Apache

[Anonymous Coward]

ps.
I still think it's a bug that OpenBSD allows root login over ssh as default.

Oh you're a real cock smoking faggot aren't you? What the fuck's wrong with a root login over ssh. IT'S CONVENIENT. I don't want to have to su or some other stupid shit just to admin the box. That would mean more keystrokes and more time. Just give me what I fucking want! An easy box to admin where it does most of the work for me and provides a slick GUI that can be customized with skins so I don't get bored at work. Speaking of which... how come non of you brainiacs has come up with a GUI based ssh client for Linux/BSD? PuTTY for Windows is totally awesome, managing ssh and telnet sessions should be just as easy on Linux or BSD! Get with the 21st century people!!! I don't want to have to bring up a fucking bash shell and type in the ssh or telnet commands. Or use the history commands to get back to a previously entered session. I want to point and click on a list of configured hosts. And I want to be fucking root if I log in remotely!!!! Jesus the parent post really cheesed me off!! I want to fart in that asshole's mouth and make him lose his lunch. This dork is probably so anal he winds up being multiple sessions deep in his xterms just so he doesn't log in as root. What a fucking assclown. Get a life mother fucker! Gawd I hate people like you!!!!!

sendmail is NOT that popular

[ChrisCampbell47]

While Sendmail runs half the mail servers in the world

According to http://cr.yp.to/surveys/sendmail.html and http://cr.yp.to/surveys/smtpsoftware6.txt, Sendmail has long been trending towards less and less hosts running it. As of his last survey two years ago, it was at 42%. And if you look only at "serious" MTAs, those for sites that have heavy mail volumes, you'll probably see even less Sendmail.

other points about qmail aside...

[dpilot]

>Also, it doesn't require that you install all the author's other tools in order to have a functioning MTA.

This one does it for me. I currently use Exim, which also drops in for sendmail and is reasonably secure. If/when I want more security, I'll probably go Postfix because of the simple drop-in.

Security is never unimportant, but for an internal-only MTA for a family of four that accepts no external connections, it's secondary. I will however agree that had I been running Sendmail, the March problem would have had me.

Re:seriously though...

[Mhumble]

Exactly what I was thinking. Please people get over the "open source will solve the world security problems" way of thinking. It's a pipe dream

Damn Bill Gates and his insecure code!!

[TigerTime]

oh wait, nevermind.

Note: The name is "qmail", not "Qmail".

[Anonymous Coward]

http://www.lifewithqmail.org/lwq.html#whatitis

Oh, I forgot! This is /.. Nobody RsTFM.

Re:Note: The name is "qmail", not "Qmail".

[dasmegabyte]

Oh shut up. I capitalized qmail because it was at the beginning of the sentance. Or are you claiming that Dan Bernstein is actually e e cummings and I should drop all grammatical rules when referencing him?

Re:Note: The name is "qmail", not "Qmail".

[Trepalium]

There's a convention that when the first letter of a product name is intentionally not capitalized, that it isn't capitalized even at the start of a sentence. Both www.qmail.org and cr.yp.to/qmail.html refer to it in this way. English is silly. Hacker english is sillier.

That's exactly what's wrong with sendmail

[mortonda]

The config file is so arcane you have to use an ugly macro language to generate the config file. What's up with that?

Postfix is a breeze to set upeasy installations, and very mild to set up complex installations.

Beef w/RedHat

[gosand]

Companies like Red Hat have found such bugs in the Linux kernel, sendmail, apache, samba, etc, etc because they are looking for them, fixing them, and patching their user-base proactively.

I have a beef w/Redhat. Can someone here maybe explain to my why they issue patches the way they do? They don't update the version number of the package when they apply a fix, so there is no way to tell if you are running a patched version or not. Quite annoying. Yes, there are ways to keep track of it yourself, but I don't see any reason why they don't indicate the patch version in the package numbering scheme.

Re:Beef w/RedHat

[cowbutt]

Can someone here maybe explain to my why they issue patches the way they do? They don't update the version number of the package when they apply a fix,

Yes, Mark Cox of Red Hat answers your question here.

so there is no way to tell if you are running a patched version or not. Check the CVE references given in the errata announcements against the vulnerability report you're working to mitigate.

--

Re:Beef w/RedHat

[bogie]

Of course they update the version number. What are you basing this on? Feel free to look at your 8.0 and 9.0 cds then compare them to some of the packages on the Red Hat errata page.

If product xxx2.3.2-4.i686.rpm is flawed, RedHat will update that product with xxx2.3.2-8.i686.rpm. You almost will never see a "2.3.3" because Red Hat backports fixes to the current product. They correctly won't ship new untested code by just shipping whatever new version is available without the flaw. Major Package numbers are only updated to signify new code, the numbers on the end are the only ones which go up in their security fixes. They are the version numbers.

Re:Beef w/RedHat

[ajs]

They do this for the exact same reason that Debian does the same thing. They back-port security- and bug-fixes that they consider essential to their customer-base, but they do not "upgrade" the software.

Thus, Red Hat's Linux kernel v2.4.20-18.9 might well be 90% of 2.4.21, since it has many of the fixes from it, but it's not *actually* 2.4.21 and thus should not be considered a peer with that release.

This allows you to take an up-to-date SRPM from a project site or from a later Red Hat release and re-compile it on your existing platform, and still have the dependency-graph work correctly.

Re:Beef w/RedHat

[datan]

so is it better to use up2date or apt-get update && apt-get upgrade?

Replacing SENDMAIL does not eliminate problem.

[digrieze]

NOTE: I occasionally do system security audits, this problem is one of my favorite targets.

Just because you use a sendmail replacement (qmail, etc.) does not mean you've eliminated your vulnerability. Most distributions install SENDMAIL by default set to accept local input only. This is necessary for configuration, but also leaves it open to anyone that can launch a local process. If sendmail is used temporarily until it is replaced then it may be left open to external input also.

If you use a replacement for sendmail then you should remove sendmail from the system. If you cannot remove it due to dependencies by other code then you should insure it is up to date and patched, even if you're not using it for mail routing as it is still vulnerable.

The worst systems I've seen are older production systems where SENDMAIL has been replaced and left on the system (either due to negligence or necessity) and not maintained "since it's not used anymore". (and you just wouldn't believe how many sysops out there that don't know what's really running on systems set up be predecessors and that they make some very bad assumptions about, like, we don't use SENDMAIL, so it's not on the box)

Any binary on your system, especially this one, needs to be maintained or you're asking for trouble. And worse, if you haven't documented what's on the system you'll really be out in left field not even knowing what to patch!

Re:Replacing SENDMAIL does not eliminate problem.

[Kevinv]

Most of the installs I've done for postfix and exim (I prefer exim) replace sendmail completely and setup a link from /usr/sbin/sendmail (or whereever) to the replacement. Both postfix and exim will accept the same commandline parameters as sendmail (although they ignore some of them) so this won't break any locally installed software that expects sendmail to be available.

Yes, and

[Sycraft-fu]

Windows has an alternative setup for Mozilla. Go to Mozilla, open installer, follow instrucitons. Equally easy yet few people do it. If somehting is up and running and working, most users will say "fuck it" and stick with that.

Re:Yes, and

[johnnyb]

No, it doesn't. You have to download and install Mozilla. Postfix comes preinstalled on RH, you just have to switch using a single command, and then restart the mail server. It's very, very easy.

I take it that you've never read a bat book.

[emil]

In the life of sendmail, write-only cf files are a recent innovation.

There is still a huge amount of legacy material on modifying cfs. The perils of modifying the path to the local delivery agent (for example), or removing DaemonPortOptions (which has greater risks) are easily mitigated.

Please approach the subject with a more evenhanded point of view, and be aware of the historical perspective.

a good comparison of all the major mailers

[stinkfoot]

http://www.mailsoftware.cjb.net/

"major" being: courier, sendmail, postfix, exim and qmail.

it looks like it's about a year old, and has some missing information, but it's a place to start for anyone looking to switch MTAs.

Awesome, but not easy to use

[MasTRE]

Postfix is not easy to use. It is probably the best MTA out there. That is not in question. But to say any proper mail system, such as Postfix, is easy to use is like saying Windows is a secure OS.

There is a steep learning curve with Postfix, just as with most/all other MTAs. And there is probably far less printed documentation out there than there is for Sendmail. But there is a lot of on-line documentation and what comes with the package, although terse, is also quit excellent. The same goes for the people on the mailing list - as long as you RTFM and you're still having a problem, they are glad to help.

You get what you put in. Put in the time and learn Postfix and you'll have an awesome MTA that can do many tricks and isn't plagued by the issues associated with Sendmail.

Sendmail news flash! IMMEDIATE READ!

[buss_error]

...which this ain't. It isn't news, and nerds have already patched. So what is this, a postfix ad?

qmail - unfixed since v1.03 (1998)

[buchanmilne]

To be fair, I havent tried postfix

Well, it's pointless comparing any MTA to sendmail, so what is the point of your post?

Postfix implements many of the ideas in Qmail, but
-is a drop-in replacement for sendmail (ie external commands are supported, many config files are common)
-free software (DJBWare isn't free)
-supported by most linux distros
-scales well (with support for LDAP, SQL etc out-the-box)
-doesn't unbundle mail

For information on why qmail is bad, see:

http://www-dt.e-technik.uni-dortmund.de/~ma/qmai l- bugs.html

sendmail for legacy admins

[buchanmilne]

I can see that some ISPs have a need for sendmail due to legacy UUCP-customers (yes, someone still uses UUCP)

Postfix supports UUCP, no excuses! (yes, I have some boxes running Postfix/UUCP)

Don't Use Qmail

[buchanmilne]

The Qmail author offers money for any holes found. So far he hasn't had to pay a cent.

Not because his software is so good, but because he doesn't agree that DoS vulnerabilities qualify as "holes".

And there are a lot of other reasons not to use Qmail.

Re:Don't Use Qmail

[AnotherBlackHat]

Not because his software is so good, but because he doesn't agree that DoS vulnerabilities qualify as "holes".

Not that I'm a fan of qmail, but I think most people would classify a DoS vulnerability as a "bug" not a "hole".

I don't think DJB certifies his software as bug free, but then, no on else does either.

If you count DoS as a vulnerability, then all MTAs have "holes".

-- this is not a .sig

Re:Don't Use Qmail

[buchanmilne]

Not that I'm a fan of qmail, but I think most people would classify a DoS vulnerability as a "bug" not a "hole".

If it would result in a DOS under conditions where other MTAs would not suffer a DOS, IMHO it's certainly not just a 'bug', it's a serious bug, and most other authors issue bug fixes, and vendors provide patches for this.

I don't think DJB certifies his software as bug free

No, but people here are claiming he does ($500 reward etc etc).

If you count DoS as a vulnerability, then all MTAs have "holes".

Well, that's one mine doesn't have.

Postfix and SMTP-AUTH

[rjh]

I'll use Postfix just as soon as someone puts up some correct and current documentation about how to get it working with SASL (particularly, Cyrus-SASL's latest release) to allow SMTP-AUTH for authorized users.

I'm a university student and I'm often on a DHCP connection. I grab my mail off my home box using POP3s and I want to reply to it, but I can't since my university server requires that all outgoing mail be from "myname@example.edu", not my home domain of "rjh@homedomain.org".

So I have Sendmail set up right now to do SMTP-AUTH and everything works great. I get to use my home Sendmail server from anywhere in the world without it being an open relay. Love it. Unfortunately, Sendmail blows, securitywise. I've often been wishing I could go back to Postfix, but the documentation on SMTP-AUTH with Postfix is embarassingly scanty. USENET has been absolutely no help. Google can't find any current and accurate documentation beyond "you need to use Cyrus-SASL". Even dead-tree Postfix books have been useless.

So. Anyone want to throw me a bone here and tell me just how the $#(&! I can get Postfix + SMTP-AUTH working?

Re:Postfix and SMTP-AUTH

[Kevinv]

Switch to Exim. I use SMPT-AUTH (CRAM-5) with it. It was a breeze to setup. I just added:

begin authenticators
cram:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${lookup{$1}lsearch{/etc/exim/allowed_auth}{$value }fail}
server_set_id = $1

to the end of the config file. I keep the passwords in the /etc/exim/allowed_auth file (make sure it is readable by the mail uesr ONLY, not world or group readable. Not writable by anyone.

In the relaying section you need to have:

accept authenticated = *

which means you can relay from any IP in the world if you authenticate first. You can restrict that down to particular subnets if needed.

Not on any decent linux distros

[buchanmilne]

Is Sendmail still used because it ships as the default mailer with almost every flavor of Unix?

Yes. Yes it is.

No, SuSE and Mandrake have been shipping Postfix by default for a few years (Mandrake at least since 7.1). Of course, sendmail is still available and supported (pity, otherwise there may be space for other secure mail servers ...).

I think it's only the Redhat users who get an insecure MTA by default ...

It seems Debian may have also seen the light ...

I'm not ditching Sendmail because...

[Anonymous Coward]

I need milter and UUCP, and I need them to work together. (And yes, there is a real reason I use UUCP! SMTP is not allowed over my ISP's firewall)

Re:sendmail Unnecessary for legacy

[pHDNgell]

I actively use UUCP with my postfix installations have done so for years.

I also have two primary MX servers in two parts of this country routing mail using tables that exist in a replicated LDAP server...and virtuals (although I have my virtuals in just plain replicated virtuals table because I find it a bit easier to manage currently).

No, you don't need sendmail.

Postfix is the default in SuSE 8.2

[lessthan0]

Postfix became the default mailer in SuSE 8.2. It has been the default mailer in Libranet forever. Red Hat makes it easy to switch to Postfix from Sendmail with a simple switch script.

I evaluated mailers in 2000, choose Postfix as the best and have never gone back. It is very powerful, fast, and secure. And you can edit the configuration with a plain text editor.

Now, if sendmail was twice as fast or had some other great advantages, then maybe the extra pain would be worth it, but why make your life harder than it has to be?

Looks like it's fixed in manyf Linux disributions

[leighklotz]

It looks like it's fixed in many Linux disributions and you don't have to downlad raw sendmail yourself. For example, ISS reports it's already fixed in updates from RedHat for 6.2 through 8.0 and presumably for 9.0 as it was released later. Other vendors have similar reports. Check out the ISS link.

Newbie using Postfix

[Gareman]

Coming from the Microsoft world, I wanted to try setting up a home network using Linux and open source software. Red Hat with the default Postfix and Squirrelmail took a weekend to setup, with no past mail server experience (BIND taking up most of my time). Postfix online instructions are concise and it's easy to administer for a novice, especially with Webmin. I ended up selling my "Postfix" book on Ebay after the initial installation.

That this will also be the de-facto standard on OSX means that Postfix will be the alternative mail server to running Exchange.

In defense of Sendmail...

[swordgeek]

OK, I'm not about to claim that postfix, qmail, or whatever you want don't have their places. In fact, I'd be quick in line to argue for them replacing sendmail in many cases.

However, I am sick and tired of hearing about how difficult sendmail is. It is NOT difficult to manage, it is NOT difficult to configure. It IS, however, difficult to LEARN.

Yes, it's a big, complex, massively powerful and massively detailed piece of software. If you understand and know sendmail well, then there's nothing difficult about it. At least, no more difficult than any other MTA.

The article didn't mention the best feature

[Eric Smith]

If you need to run a backup MX for a lot of domains, you don't have to configure them all manually. You can just tell Postfix that it's allowed to backup domains that have MXes on specific networks. For instance, my Postfix main.cf includes:

smtpd_recipient_restrictions = permit_mynetworks, permit_mx_backup, reject
permit_mx_backup_networks = 64.15.260.112/27, 282.66.92.0/22, 67.91.305.33/32

(specific addresses changed to protect the innocent, and yes, I know that a byte can't exceed 255, that was deliberate)

This tells Postfix to accept mail for any domain that has an MX in one of the specified networks. So whenever I add a new domain to one of my primary MX servers, I don't have to change the configuration on my backup MX servers at all.

Sendmail is just too hard to configure

[Anonymous Coward]

Given that sendmail is rather rich in features, which one of those do you honestly use on a day to day basis? The truth is, its very complex, archaic, and outdated. That's where Postfix comes into play. Its more secure and easy to configure.

I use postfix because of the simple fact that its VERY easy to configure, more secure, and just plain better. As for sendmail, after reading the manual for hours, I still had no idea where to begin thinking about how to modify the configuration files.

If security is important to you, try using Qmail. It is so secure (so the author claims) that he is willing to offer a cash reward to anyone who can find an exploit in a stock distribution. I must say, its not very robust in features, and has a number of limitations to maintain its securty. Postfix turns out to be a good combination of both security and features, as well as ease of use.

It is popular indeed.

[Anonymous Coward]

It appears that Yahoo actually bases their MTA on Qmail, as I can tell from the extended details from the mail that is sent to me from Yahoo accounts.

Sendmail bashing - Slashdot's favorite activity

[guacamole]

I am sorry, but this slashdot story looks like an blatant and biased ad for Postfix that also undeservably bashes Sendmail. The security problems mentioned in the story are relatively old. This problem has been found and fixed in March. So, why are these advisories making it into slashdot headlines today? Talk about sensassionalist journalism. I'll stick with sendmail. Thank you very much.

other viabilities

[CAIMLAS]

I use exim for everything, never had a (real) problem. (That is, anything outside me goofing up :P) Not knowing much about how the various MTAs compare, I have to ask: does anyone know how and why EXIM does/does not compare well against postfix/sendmail? Certainly seems viable to me.

Newspapers not so wrong?

[MS]

Sendmail "handles an estimated 75 percent of the Internet's email traffic."

Assuming each e-mail passes on average 3 MTAs, and sendmail is used on 50% of those servers, that gives:

• .50 (probability first server rung sendmail)
• .50*.50 = 0.25 (probability second server runs sendmail, if first didn't)
• .50*.50*.50 = 0.125 (probability third server runs sendmail if first two didn't)

Summarizing: in 87,5% of cases, the e-mail was handled (= routed through) by at least one MTA running sendmail.

If sendmail is deployed on 40% of the servers, the same reasoning gives a total of 62,4%. So the newspaper talking about "routing" and not about the percentage of servers running sendmail, may be correct.

My 2c.

Re:Popular open-source packages with security hole

[Kevin DeGraaf]

Right off the top of my head are these long-standing open-source packages with long histories of security holes: wu-ftpd [...] sendmail [...] vixie-cron

Wow, how could you forget the most obvious one?

The three you mentioned are indeed bad, but BIND is definitely, by far, the most bug-ridden, insecure, shoddily-designed piece of trash ever to embarrass the open-source community. No bitchfest about bad software is complete without mentioning BIND.

Between vixie-cron and BIND, I'd support a law prohibiting Paul Vixie from ever touching a computer again. Kinda like Kevin Mitnick's probation, but with actual justification this time around...

Anyway, a big "thank you" goes out to DJB for freeing the world from the mess that is BIND (and Sendmail, for that matter)!

The qmail offer

[crucini]

That reward is just a way of publicly backing up DJB's belief in his code quality. I would think it's obvious that the motivation of anyone researching a qmail vulnerability is the advancement of knowledge and the recognition. By publicizing this award, Bernstein has increased the attention on this issue, guarranteeing more recognition for the person who claims it.

The award is significant, not for its amount, but because it's a very rare public declaration by a software author/vendor that his code is secure.

Re:seriously though...

[erikdotla]

Explain to me then why a Default install of Exchange 2003 (RC2) on Windows 2003 resulted in a completely open relay, against which several thousand spams were sent before I realized what was happening. The authentication systems in 2003 are widly complicated compared to before. It used to be things were restricted by IP or Domain Username.

Now, it's like you can do this operation if you've inhereted the rights from a parent process which was launched by some other process that was launched under the system user, and you have a groups policy entry that dicates that rights are allowed to be inhereted by tokens of your mom and this and that, and only if the Active Directory account is in a group that is part of a membership that is part of a brotherhood that lives in the right forest that has been granted the authoritah to log on under the alternate credentials under which your SMTP process is running. Or something like that. Trying to figure out "who can send mail" is utterly absurd.

Re:Courier - trouble with invalid MIME headers

[Anonymous Coward]

This is no longer an issue in newer versions of courier. See http://www.courier-mta.org/courier.html :

"opt BOFHBADMIME=action

Set default disposition of mail with invalid or corrupted MIME headers. Possible settings for action are: accept - accept and pass on the corrupted message, untouched; reject - reject and return the mail as undeliverable; wrap - "wrap" the message as an attachment, that must be separately opened (this is the default action). This setting applies to mail that's generated locally, or which is sent from IP addresses that do not have an explicit BOFHBADMIME setting listed in the smtpaccess configuration file. smtpaccess can be used to set BOFHBADMIME for specific sending IP address ranges only. See makesmtpaccess(8) for more information."

This article is flamebait

[strobert]

Okay, come on /. editors. this thing is not a new one. the vulnerability is from March. so if you want to talk about postfix (which I have switched to at work and in the process of at home) then fine say so.

but don't post such a misleading article that sounds like there is a enw exploit. that just isn't responsible.

Also, although postfix is easier to use and has more features in other areas (like easier to tie in things like virus scanning, mysql based virtual mail domain handling, etc.) sendmail supports more mail transports.

Yes those transports are now basically extinct, but give credit where credit is due. I am, tired of hearing everybody bash sendmail without giving it the respect it deserves. yes its code is old and has had issues. like most software projects you learn a lot the first time around (and even DJB fanatics should realize that qmail was written with the lessons learned from sendmail in mind -- whther conscious or subconscious).

So is it time for people to be moving on yes. Is it proper to sell people on this idea by basically lying and ignoring the past no.

Software freedom matters.

[jbn-o]

Qmail is non-free software; distributing modified versions is prohibited. One can distribute patches to an unmodified Qmail and acquire the same result, but some people are unwilling to give up the freedom to publish modified versions of programs. By contrast, Sendmail and Postfix are free software.

There is also an enormous amount of support for the product available.

I don't know what constitutes an "enormous amount of support", but support is also available for Sendmail and Postfix online and through consultants.

A `user-transmitted worm' ?

[Nailer]

Um, that's an oxymoron.

Re:Courier - trouble with invalid MIME headers

[ahacop@wmuc.umd.edu]

Thanks for the heads up. I'll have to try it out again...maybe I'll switch back!

switch switch switch switch switch

[J--n]

Gee, Glenn. I wonder if we can get a bunch of slashdotters to take a software they've used forever and get them to switch to another one.