Date: Thu, 1 Feb 2001 15:12:04 GMT From: Cliff Sarginson <cliff@raggedclown.net> To: "Andre Hall" <ahall@pcgameauthority.com>, "Dragos Ruiu" <dr@kyx.net>, "Christopher Farley" <chris@northernbrewer.com>, "Fenix" <fenix@xs4some.net>, <freebsd-security@FreeBSD.ORG>, <freebsd-questions@FreeBSD.ORG> Subject: Re: sendmail vs. postfix question Message-ID: <E14OLP2-0005FC-00@post.mail.nl.demon.net>
next in thread | raw e-mail | index | archive | help
I want to endorse the comments below. The author of Postfix has produced a realy solid, fast and secure mail system. You may be interested to know he also authored tcp-wrappers and the (in)famous satan program. He also personally answers many of the questions on the postfix-users@postfix.org mailling list. browse the archives on deja if you are curious.. Cliff > I once was faced with the same dilemma as you were. I finally decide to the > Postfix way have not regretted my decision one bit. It was the easiest and > fastest configuration I had experienced, a definite plus over Sendmail. From > my first experience with Sendmail I always been displeased with how arcaic > it is, especially if you need to make changes. Postfix's configuration file > is very user-friendly- you don't have to be a rocket scientist to make > changes. Straight and to the point. You can also find an abundance of > support on the author's site. It's really based on personal preference. > I hope my two cents helps you > > ----- Original Message ----- > From: "Dragos Ruiu" <dr@kyx.net> > To: "Christopher Farley" <chris@northernbrewer.com>; "Fenix" > <fenix@xs4some.net> > Cc: <freebsd-security@freebsd.org>; <freebsd-questions@freebsd.org> > Sent: Thursday, February 01, 2001 3:22 AM > Subject: Re: sendmail vs. postfix question > > > > On Wed, 31 Jan 2001, Christopher Farley wrote: > > > Fenix (fenix@xs4some.net) wrote: > > > > > > > I have a little question about sendmail vs. postfix .... > > > > Are there any known recent problms with sendmail security ? > > > > what about postfix ? > > > > > > Sendmail is a large, monolithic, complicated program that runs as > > > root. Historically, it has been responsible for some of the most > > > notorious and widespread security holes on the Internet, but I > > > don't believe there are any (known) gaping holes in it today. > > > Sendmail configuration is complicated and arcane -- it is the > > > subject of one of the thickest books in the O'Reilly catalog. > > > Actually, configuring sendmail is not that bad once you understand > > > it -- you edit a human-readable config file which is processed by > > > the m4 macro processor to build the much less human-readable > > > sendmail.cf file. However, if you are like I am, and infrequently > > > make configuration changes to your mail server, it may take more than a > > > few minutes of grepping documentation to make even a tiny change. > > > > > > Postfix has a different architecture, but strictly conforms to the > > > 'sendmail api'. That is to say that Postfix is more or less designed > > > to be a drop-in replacement for Sendmail. Postfix is actually > > > several small, specialized daemons that do not run as root (!), > > > which has some positive security implications. Configuration of > > > Postfix is very easy; there is no m4 macro processing here! I have > > > always been able to make it do what I need it to do, although my > > > needs aren't very great. According to my ISP (visi.com), Postfix > > > outperforms Sendmail. > > > > > > > Postfix performance exceeds sendmail performance on equivalent boxes in > all my > > experiences in terms of just about any metric you care to use, and I use > it > > exclusively these days. As anecdotal evidence, once when I configured it > on a > > very fast machine and sent a lot of mail through it, I had a large ISP > call up > > and complain that I was DoSing their mail server.... It was just postfix > being > > its normal, speedy, efficient self, and they had some NT lameware mail > relay.... > > > > As far as security, given how much I rely on it, I recently(last year) > decided > > to re-audit its code, and after a couple of days spent looking for format > > strings and other stuff I decided to discontinue the audit... Mr. Venema's > code > > is so rigorous that it even passes _internal_ data between routines > through > > filtering and cleaning functions (how paranoid is that :-) if that's any > > indication of how it's built up. > > > > I personally think very highly of it. (Besides, I really would be fine > > if I never have to look at another arcane sendmail ruleset ever > > again... :-P ) > > > > cheers, > > --dr > > > > -- > > Dragos Ruiu <dr@dursec.com> dursec.com ltd. / kyx.net - we're from the > future > > gpg/pgp key on file at wwwkeys.pgp.net or at http://dursec.com/drkey.asc > > > http://cansecwest.com > > CanSecWest/core01: March 28-30, Vancouver B.C. ------------^ > > Speakers: Renaud Deraison/Nessus Attack Scanner, Martin > Roesch/Snort/Advanced IDS, > > Ron Gula/Enterasys/Strategic IDS, Dug Song/Arbor Networks/Monkey in the > Middle, > > RFP/Whisker2.0 and other fun, Mixter/2XS/Distributed Apps, Theo > DeRaadt/OpenBSD, > > K2/w00w00/ADMutate, HD Moore/Digital Defense/Making NT Bleed, Frank > Heidt/@Stake, > > Matthew Franz/Cisco/Trinux/Security Models, Fyodor/insecure.org/Packet > Reconaissance, > > Lance Spitzner/Sun/Honeynet Fun, Robert Graham/NetworkICE/IDS Technology > Demo, > > Kurt Seifried/SecurityPortal/Crypto: 2-Edged Sword, Dave > Dittrich/UW/Forensics, > > Sebastien Lacoste-Seris & Nicolas Fischbach/COLT > Telecom/Securite.Org/Kerberized > > SSH Deployment, Jay Beale/MandrakeSoft/Bastille-Linux/Securing Linux > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14OLP2-0005FC-00>