Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
The Internet

Sendmail 8.10 Public Beta Released 57

Charles Ying writes "sendmail.net is reporting that Sendmail 8.10.0 Beta has been released to the public. The Sendmail Consortium hopes to get more wide spread testing from the open source community. Sendmail 8.10 has a lot of new features such as IPv6 support, SMTP AUTH, multiple mail queues, improved anti-spam capabilities, and updated LDAP support. "
This discussion has been archived. No new comments can be posted.

Sendmail 8.10 Public Beta Released

Comments Filter:
  • by Anonymous Coward
    Yes it IS a "Big Deal". Regardless whether you love or hate it, the 8.10 release has some very important features. The SMTP AUTH (RFC 2554) support closes the roaming user holes that uninformed mail hosters use as an excuse to run open relays. Because 8.10 Sendmail has this feature, all the popular MUA's will adopt it, which in turn will convince the holdout MTA developers to implement it. The War against SPAM now has a powerful new tool. Spoooooon!
  • Just a plug for Exim [exim.org], a GPLd MTA that is easy to configure, but still quite flexible.

    Sendmail is still necessary for certain special cases, like when you need BITNET support, or something else out of the ordinary.

    But, I think for most users, Exim is a better choice.

    If you haven't played with Exim before, you really ought to check it out.

    --
    Interested in XFMail? New XFMail home page [slappy.org]

  • While sendmail might be bloated, I think it has GOT to be the most complete, and configurable piece of software on earth. As well as being a major success story for the whole opensource revolution thing-a-ma-jig.

  • by Suydam ( 881 )
    SKip the paranoia. Sendmail is one of the biggies when it come to Open Source success stories. Not to mention it's staggering market share.

  • Sendmail may not be as hard to configure as most people think, but it IS riddled with security holes. Or at least, has been in the past, and most likely is now and will be in the future.

    Qmail is simple and elegant. I think that there are three basic problems with Qmail, however:

    1. Because there is no one right way to do things in qmail, trying to set up anything nonstandard can be confusing, if only because the qmail site lists many, many different sources of documentation for qmail, each of which says to do something different. That means that you have to understand alot about qmail (and the 15 other daemons that people have written to monitor, start, log, stop, police, etc qmail) to know which parts of a particular piece of qmail documentation applies to your site (are you running splogger? Are you using watch? fastforward? daemontools? countless other bits and pieces which your installation of qmail may or may not have?).

    2. The qmail author seems to want to rewrite everything rather than use anyone else's code. libc is not used in qmail (or if it is, only a teeny little bit), in preference to the author's very cryptic, bizarre, and almost completely undocumented "replacement". So hacking the qmail code means puzzling over very strange, nonobvious, and undocumented C functions.

    3. qmail spawns a separate process for just about everything. Kinda reminds me of the early days of web servers which spawned a separate process for every connection. I can't see qmail scaling to very large sites with a multiple-processes-per-email model.

    On the other hand, qmail is *very*, *very* secure, and is, like I said, simple to install (especially with the RPM). It is also very good about logging what it is doing and a single person can understand, without too much difficulty, what is going on in the qmail system. And its performance is certainly adequate for small to medium sized sites.

  • The problem with the sendmail.cf file is that the .cf file was designed from the start to be parsed quickly by the program, not to be human readable. The only concession to human-readibility that the .cf makes is the comments. For a long-lived server, startup time is neglible compared to the runing time of the process, so for the long-lived instance of sendmail (the one that receives mail and processes the queue at regular intervals) why not make it a human readable file anyway? Plus the fact that servers are much faster now means that the overhead of the parsing time is very small.

    Why doesn't sendmail use Berkeley DB for the main config info anyway? It already uses it for the aliases and other config files in /etc/mail. If speed in loading config info is so important, slurping the data in directly from a DB file would be faster than parsing text.
  • I can answer that question!

    (conspiracy theory)
    The _real_ reason that the .cf file is so complicated is so that Sendmail, Inc. can sell Sendmail Pro to everyone, with their nice GUI configuration software. No more editing .cf when you're in a hurry, no more running m4 to update the .cf, just click that there Sendmail logo on the desktop and go clicky-clacky till it works!
    (/conspiracy theory)


    (old man voice) Back in my day, we didn't have none o' tham gooeys these kids are all crazy about...we used a hex editor on a VT100 to modify the sendmail binary directly...AND WE LIKED IT!"
  • I don't think that my post put sendmail up on a pedestal at all. There's nothing that implies that it should be shielded by critique, I mentioned nothing about Microsoft and I mentioned nothing about it being open source.

    Every major piece of software, be it in the NT or UNIX camp, has security holes in it. Every document you read should say "if you got with your software, check with your vendor because there's bound to be security holes in it". It goes without saying almost (qmail might be an exception, since no one has collected the cash prize for exploiting it as far as I know).

    And yes, I admit that I don't fully understand what every single rules set does in my .cf file. Sue me. I also don't understand what every single piece of code that is in the linux kernel does but I use that anyways. Do you read and understand all the source code you use? Or even better, are you using a closed source application? Do you know what IT'S doing internally? Do you test ever buffer in every application to make sure it won't overflow and smash the stack? I don't. I don't have the time to do that - I'd never get anything done.

    I can't religiously defend sendmail because it has, historically, had its problems. Perhaps I'm wrong to use such an application to deliver my mail. The reason I continue to use it is a) it works out of the box with my IMAP package and has rulesets for delivery specifically with the Cyrus stuff from CMU, b) it has LDAP support for delivery lookup, c) newer versions will have SASL support for authentication and d) I find it simpler to setup than qmail. To get the functionality I want out of qmail, I have to download the core package, use a bunch of addons that people have contributed, do a bit of hacking, and then still not have a product that works quite as well as I want it too. Most definitely its my own ignorance of using qmail but for my situation, sendmail works.

    I'm not saying that qmail sucks or that sendmail rules. All I'm saying is that for what I want to do, sendmail works fine. For some sites, that still have UUCP or BITNET, sendmail is one of the only options. If the number one rule for designing a mail server is "You must use a MTA that has no history of security exploits", qmail wins and sendmail loses. My past experience in getting qmail to work with my setup (LDAP/PAM) wasn't good and thats why I continue to drag around the "dead beast" known as sendmail.

  • by KmArT ( 1109 ) on Friday October 22, 1999 @04:02AM (#1595105)
    Sendmail seems to generate a lot of hate and a lot of love, from its detractors and supporters, respectively. How many of those who use qmail have ever setup and administered a sendmail install? And how many sendmail admins have ever setup and used a qmail install? Both have their pros and cons. Both were designed differently - one came from way back in the day when the world was a bit freer (as far as computer security goes) and as a result, its had many exploits. I don't think that Eric Allman will ever suggest that sendmail was coded with security first in mind (and thats no excuse for not being secure). Because of that, the sendmail approach has been to add new features, patch bugs, and end up with a MTA that can do anything (but is bloated).

    There are somethings that sendmail, because of its "bloated" quality can do well. Ever try to do mail via BITNET or UUCP with qmail? Probably not - I'm not sure it can be done. But sendmail has hooks for those mechanisms.

    Qmail is (argueably) easier to install, has a nice mailing list manager and IT WAS DESIGNED WITH SECURITY IN MIND. Sendmail wasn't. Thats not excusing its security holes - its just noting that the environments that shaped the two MTA is different. And perhaps its time to move away from a MTA that was designed wrong from the start. But you can disable alot of the unneeded features of sendmail if you want.

    This is a near religous war (akin to emacs vs. vi). But for those of you who argue that sendmail has a difficult config file - have you ever read the README files on how to set it up? I'm working on installing a new mail server now, built around the Cyrus IMAP package and sendmail 8.9.3. Compiled Cyrus and supporting libraries (libsasl) on Tuesday and got it running. Compiled sendmail yesterday - install BerkeleyDB 2.77, got sendmail source, uncompressed and untarred, cd sendmail-8.9.3/src, ./makesendmail to generate Makefile, edit Makefile to point to Berkeley db stuff, make, make install, cd ../../cf/cf, create a 10 line .cf file, m4 miconfig.mc > sendmail.cf, HUP it and I have a MTA that hands off everything but a few local accounts (like root) to cyrus. Its got antispam features out of the box, it uses LDAP, its reasonably fast, and I did it in my spare time - cyrus install was about one hour and sendmail was about the same (less if you don't count the interruptions).

    All the sendmail.cf file amounts to is an expansion of a ton of m4 macros. The .cf files are not difficult to generate at all - like I said, ten lines and I have a fully functional mail server. I don't profess to know what all the rules do - but I don't necessarily have to - it works.

  • Ever try to do mail via BITNET or UUCP with qmail?

    Weird. I'd bet noone mentioning BITNET *knows* anything about it :) If I knew it, I would try it with qmail yes! I've run uucp over ssh with qmail, I've used FidoNET with qmail. No problem. My only problem with sendmail was that you can *fix* it to do something you want it, but you'll never understand it completely. On the other hand, if you take a few hours, and read all (included) qmail docs, and you know Unix, you can do *anything*, and you understood qmail totally.

    If I let myself summoned with qmail bashing, let me share a few resources on it:

    BTW, let me mention, Dan (the author of qmail) is the Math Professor on University of Illinois at Chicago, who sued the government to not restrict him distributing his crypto source at his web page (for his students!).

  • I don't want to claim there's nothing wrong with qmail, but the arguments you show are not quite true:
    1. Because there is no one right way to do things in qmail,

    Ok, this might be true; but having things done in many ways is only confusing at first, i.e. bad from the user interface point from view. Alas, experts *prefer* things to be done any way they want. Or do you say perl is also bad? :)

    2. The qmail author seems to want to rewrite everything rather than use anyone else's code.

    Ok, bad from the engineering point of view, but the code he builds is superior from the viewpoints it needed rewriting. Not libc he avoids to use (it's quite difficult to do that in a portable Unix program), but stdio. Stdio is not quite designed for reliability (i.e. buffering, error handling), and security (overruns). His code is not quite nonobvious, I'd rather call it genuinely great. Too bad he doesn't have time to reinvent every part of Unix :)

    3. qmail spawns a separate process for just about everything.

    You missed a qualifier: qmail spawns a very small separate process for just about everything. I think Ken Thompson, or some other old Unix guy said that if people understood fork() better, we would not need multithreading. Now, DJB *does* understand what is efficient in Unix, and small, cooperating processes are efficient, let me tell you. It is scalable really; although most of the top-volume email sites does not use it directly, it's just because no shrink-wrapped MTA does exactly what they want. hotmail.com uses/used qmail only for one of the in/outcoming directions, AOL uses sendmail, but on quite a few servers -- if I had 45 incoming servers, I could even run SMTP server written in BASIC on them.. :) For quite shocking loads however, qmail just works fine.

  • by embobo ( 1520 )

    There was no such requirement when I took my test (circa Solaris 2.5.1). They may have changed it. The questions that stuck me were about that over-enginerred saf and the horrible nis+.

    I've heard that there are test that rank you above the certified solaris admin peon level. One of those tests might have such a question but I don't think they are for the general public.

  • by Evangelion ( 2145 ) on Friday October 22, 1999 @03:20AM (#1595109) Homepage
    I'm not saying sendmail is a bad program because of that but I do think its a major part which could be changed in order to make it a little more userfriendly.


    Being an end user I really saw no need to use a full blown mailserver which is capable to support a company with over 2000 employees


    Sendmail is not about 'positive user experience'. It's about dealing with mail. Those who actually have to deal with sendmail (i.e. Unix network admins) are likely not too concerned about how much of a positive user experience they're getting from thier config files. They're most likely worried about whether or not Mr. Dumbass Veepee will be able to send mail.


    It's not a user's program.

  • by Tet ( 2721 ) <.ku.oc.enydartsa. .ta. .todhsals.> on Friday October 22, 1999 @05:15AM (#1595110) Homepage Journal
    But the program which actually scared me off due to its allmost unreadeble configuration file has allways been sendmail.

    Which configuration file would that be? sendmail.cf? Even Eric Allman (author of sendmail) says he treats sendmail.cf as a binary file. Stick to the M4 files that are used to generate sendmail.cf and you'll be fine. They're certainly readable.

  • Sendmail's config doesn't usually need to be tweaked much. It usually works fine for most configurations right out of the box. sendmail.cf can be scary, but there's a benefit in being able to control how every piece of mail is handled
    on your mailserver. But if you don't need that power then don't mess with sendmail.cf. You rarely have to.

    Qmail is not a breeze to install and configure either. I've tried both, and I prefer Sendmail.
  • IMHO, qmail is pretty much as complicated as sendmail -- just the complexity is expressed differently. After all, the things people want to be able to do with their email are complex.

    And yes, D.J. Bernstein writes code that is ... not like anybody else's on the planet. Fundamentally, he doesn't *trust* anybody else's code, so he reinvents everything. While a lot of it is documented, DJB suffers from an extreme case of 'intellectual arrogance' -- qmail is not designed to be easy to understand (internally) if you're not as smart as DJB. Plus, too many things are 'obvious' to him that aren't necessarily to other people, so he doesn't explain them.

    An example: his instructions say to use 'csh' to run qmail, to call the startup script by doing 'csh -cf /var/qmail/rc'. No explanation is given. However, if you *don't* take his advice, you're in trouble. qmail doesn't ignore SIGHUP. Children of csh are protected from SIGHUP by default; children of other shells aren't. You're supposed to realise this without needing an explanation.

    Qmail might seem to spawn a new process for everything, but it doesn't spawn as many as you think. Instead, it uses what some call 'Bernstein chaining' after its creator; each program does its thing and then exec()s its successor, reincarnating itself in a succession of roles in a single process.

    There's still a lot of processes forked (one per smtp connection, etc) but forking tiny processes isn't as expensive as you might think it is. Forking big processes is the killer. It's not a multiple-processes-per-email deal, though -- more like one process per email. That's not really any more than sendmail does.

    You're completely wrong on qmail's performance, however. It kicks the ass of sendmail performance wise, just like most of the other sendmail replacements. It's sendmail that doesn't scale, not qmail. Some of the biggest email servers in the world use qmail; Hotmail uses qmail for mail sending, for example (though not receiving, AFAIR).
  • The fact that Hemos posted it at 7:18 in the morning, as the first thing he did would make me think it gets slightly more preference than other stories, but I reckon it's still a relevant article to slashdot.

    --
  • > One final thing... I heard rumours that to be Sun certified you have to be able to write the sendmail.cf from *scratch* is this true or just someones warped imagination?

    I don't know if it's true or not, but if it is, it's certainly very very twisted. Evil. It gives a whole new meaning to the word "geek".

    --

  • Have you tried postfix [postfix.org]? It's another good alternative to sendmail. Personally, I think qmail is pretty easy to install.

    The thing about sendmail is that it comes with every single distribution of any kind of UNIX that I know of - I hardly ever have to actually compile it. And yes, it does work straight out of the box, but that's no surprise; you generally have to tweak the configs depending on exactly how you want sendmail to act.

    --

  • Does anyone here have any experience with Sendmail PRO? How good is the user interface at hiding the complexity of sendmail.cf? Does it manage to hide the complexity while still exposing the power of sendmail? Is it a good solution for a 50-100 user network?

    At $895 it may sound a little expensive - but have you looked at the pricing for Exchange server lately? A 50 seat license will set you back $4,859.

    I am definitely not against paying for software - but is it worth it? (Sendmail PRO, that is... you didn't think I was talking about Exchange, did you?)


    ----
  • by decaym ( 12155 )
    A few days ago there was a discussion on "Ask Slashdot" about IPv6 [ipv6.org] and Linux support. One of the biggest complaint was the lack of IPv6 support in most of the applications that run under Linux. It's nice to see here that some application developers are seeing the value of getting early support for IPv6 integreated into their core product offering. Once you've tackled Sendmail, BIND, Apache, and an FTP server, you have the most important tools for a good IPv6 server offering.
  • One of the most frequently mentioned complaints about Sendmail is the setup and maintenance of the "sendmail.conf" file. Some mention was made earlier of a better editor in the Sendmail PRO (the commercial offering) version. Excuse me? You are telling me that nobody has come up with an open source front end for doing the Sendmail configuration? Something along the "make menuconfig" interface for the Linux kernel would be wonderful for turning on and off options, setting hard coded constants, and compiling the finished configuration. Has anyone seen any work along these lines?
  • As the other posters have suggested, I recommend you try something like Postfix or Qmail instead of Sendmail. Just because it is open source doesn't automatically make it a good program -- it has survived on tradition,, if someone released something like sendmail today they would be laughed out of the room!
  • Some of the problems I have with sendmail you already mentioned.

    It was not designed with security in mind, and you all still use it? If this was a M$ product, you all would have ripped it apart, but because it's *open source*, suddenly it's should be shielded from critique? It is suddenly "good enough"?

    I read all the HOWTOs and documentation I could find. I even have the O'Reilly Sendmail book. Everything doc start with "if you got your sendmail with your distribution, download a new version because there are bound to be a security issue with yours". And I still don't know how to set it up.

    And you set up a piece of software that could be full of security holes, and you don't know how the rules works? Is that a good idea?

    Sendmail might have been good in its days, but I really don't see why you want to drag around a dead beast anymore.
  • Well, let's see. the M4 front end for generating configs came with 8.6(?). I'm not saying it's pretty, but I have a 12 line m4 file that generated configs used on 2000 machines (and three more .mc files for the rest of them).


    Oh yeah, change OSTYPE and the 4 config files were used on 12 different architectures. Easier than figuring out each vendor's little hacks.

    Open Source is cool!


    So m4 isn't really pretty, but frankly, once you get the sendmail config file done, unless you redesign your network or move the machine, the cf file just doesn't get changed. Do I want some GUI that shows me some of the stuff? How good will it be as a side project from someone who, once they've written the GUI, doesn't really need it?

    Frankly, i'm MUCH more efficient with vi and the sendmail operations guide next to me than I am trying to find something in a GUI. Do I really want "what would you like Timeout.Urgent set to [1d]?" queries (times 1000 options)?

    If you really WANT a gui and the other stuff pro offers, get it. It costs about what I charge in a day. It's worth while to let jimmy the operator have at it.

    If you want a happy fluffy system that holds your hand each step of the way, well, unix just ain't it. Sorry. It's here for us geek mechanics who like the silicon grease under our fingernails. Oh yeah, it doesn't drive as slow and pokey as those prefabs, it can do things that perhaps nobody thought of 2 years ago (the biggest Windows innovations I've seen have been streaming media and that's been around, better, for YEARS with multicast).

    So grab a wrench, dig in and see that by putting some effort into learning the m4 tool that you can get some really powerful things done. sendmail, I use it to pre-process ipfilterd and syslog.conf files.

  • Lesse:

    Sendmail 8.9 came out about 2 years ago.

    8.10 beta is out now and, given a long beta cycle, would probably be released near year end or early next year (who's gonna change key software a month before y2k?). 8.10 has LOTS of changes, partly cause sendmail.com is paying people to work fulltime on the OSS version (kool). Reading the notice they sent, as a beta release, they can still make feature changes, so there may be more (if (client==exchange) {sleep 10;continue;}). So...

    based on that, I'd guess that 8.11 would come out sometime in 2002 or so.



    How long before 8.10.0beta7 is out? No guess. It's beta software. Real beta, not like Netscape/AOL or microsoft beta, but beta like "help us find bugs and work on this test version of the software" beta. It's running on the home machine as of noon, handling 10's of messages a month.

  • Sendmail marketshare is greatest than {Apache,Linux,NT,PalmOS,BeOS,AmigaOS,...}.

    All things that got new version posted on /.

    Only BIND is more important to the Net than sendmail.

  • Speaking of beer, as well as a testament to sendmail's configurability, I just about fell out of my chair when I saw on the 99 bottles of beer page someone submitted an entry for sendmail!

    (quick summary: this site is basically a collection of programs in EVERY programming language on earth, practically, that print out the song "99 bottles of beer on the wall", in a loop, all the way down to 0 bottles on the wall.)

    Check out sendmail's [ionet.net] entry.

  • by Szoup ( 61508 )
    Yes.

    Is that the right answer? Do I win a prize? Get real, would ya! Of course if would get posted. News about a new version of sendmail (beta or otherwise) is news for nerds, whether you use it or not. And even if it is bloatware, some of us do use it, I can guarantee that.
    -------------------------------------------
  • Being an end user I really saw no need to use a full blown mailserver which is capable to support a company with over 2000 employees (assuming sendmail can handle this btw)


    I ran a Sendmail/UofW POP3 server for Ford for about 2 years. At it's peak, it had over 7000 mailboxes on it, and was recieving about 100,000 messages/day. This was on a dual Ultrasparc (166Mhz) w/ 256MB of RAM and a boatload of disk. It had a consistant load-average of about 1.1. I think sendmail can do 2000...

    ;)
  • As a Sendmail, Inc. employee, I have to say it's worth it. 8^)

    The biggest feature of Sendmail Pro is the GUI front end to the sendmail.cf (actually the .m4) and map files. As a consultant, I am building lots and lots of client configurations, and without the GUI, I'm, quite honestly, lost. But with the GUI it is very easy to set up and maintain a sendamil.cf. *Plus* you can then delegate the maintainance to another user who may not be completely sendmail savvy, but the online help associated with the GUI (with numerous pointers to appropriate sections of the bat book) helps a lot.

    The map editor is currently simplistic. But (AFAIK) that's being worked on.

    Another huge feature associated with Sendmail Pro is support. If the open source sendmail breaks, who do you call? You can post to the sendmail.org mailing list or comp.mail.sendmail, and *hope* that someone replies. That is the one real downfall of open source (IMO).

    With Sendmail Pro, we have real live bodies who do phone and email based tech support. We have consultants who can assist with setup and configuration/customization. For the base price, there's one level of support. You can opt to spend more, and get better levels of support. I can't say what those costs are (I don't know... I'm just one of our consultants... not a sales dude).

    But many companies like spending that money when it gives them a body/organization they can point to (even if they never need to).

    Regards,

    Richard
  • What does Exchange server have to do with Sendmail?
    Apples and oranges, pal. There is NO comparable product on the market for Exchange other than Domino. As far as groupware is concerned, they're the only two noticable players in the game...i.e. they own the market.
    It's amazing how well people can twist anything into being a discussion on how shitty Microsoft products are.
  • And they're stupid for doing it. We originally ran Notes just for email...just as moronic.
    Someone once said that running Exchange just for email is like "driving in a nail with a nuclear warhead". Very appropriate...


  • Perhaps. But if a program is focused on corporate businesses that does not mean the program doesn't have to be userfriendly. On the contrary; the more userfriendly a program is the more money a company can save. Just think about it; if I need a mta and I can choose between two programs; one program does the job but the admin needs to follow a course for one day but the other can also do the job but the admin allready stated he can handle it as is. I think I know what some managers would choose. This is an extreme example but I do not agree with your statement that programs for corporate businesses can easily lack some userfriendly-ness.
  • I "used" sendmail my self in the 'early' days when I had RedHat installed but wasn't ready to dive into the other parts of the system. I was sort of impressed that the default configuration seemed to do anything I wanted, I only fiddled in the aliases file from time to time, and that was the end of that.

    Up untill the moment where I felt the need to learn more about the whole system and start fiddling with other options like mail, news, firewalls, etc, etc. I never had any major problems configuring programs like INN (I'm using INN stand alone to fetch & send my usenet messages, you don't need 'suck' and such if you know INN), ipfwadm/ipchains, etc. But the program which actually scared me off due to its allmost unreadeble configuration file has allways been sendmail.

    Don't get me wrong here; I'm not saying sendmail is a bad program because of that but I do think its a major part which could be changed in order to make it a little more userfriendly. I know there are lots of programs around which can do most of the configuration part for you but I don't like that sort of stuff. Simply due to the fact that I like to have control over my computer and thats exactly why I like Linux so much. To throw this control away (sort of) sounds kinda silly to me.

    At the moment I'm using QMail myself since I found the setup and configuration a breeze compared to sendmail. Being an end user I really saw no need to use a full blown mailserver which is capable to support a company with over 2000 employees (assuming sendmail can handle this btw). But its allways nice to see that there is still development going on and I think I'll take a quick peek in the weekend. Never hurts to keep up with the facts, even if you don't like the program in question all that much.

  • Why not use the much better 100% sendmail compatible program PostFix [postfix.org]. It has better performance, easier (much easier) configuration and is easy to install? At least all of you sendmail users out there should give it a try.

    For the record - I have nothing to do with the PostFix project, I'm just impressed since it's a much better program.

  • by x00 ( 82065 )
    Huh?

    If you'd actually *read* the page you might not have wasted your breath.

    Okay, so this isn't exactly earth shattering news. And sendmail *may* be a tad bloaty, but I've run sendmail on half a dozen servers for a few years now and I've never had any problems, apart from my own stupidity.

    Okay, so the configuration file is a real dog, but thats what the M4 configuration is there for. Although I do wonder why you have to create a config file to create a config file, it works and works well.

    This new version looks to be building upon sendmail for the better, IMHO.

    One final thing... I heard rumours that to be Sun certified you have to be able to write the sendmail.cf from *scratch* is this true or just someones warped imagination?
  • by x00 ( 82065 )
    I don't know if it's true or not, but if it is, it's certainly very very twisted. Evil. It gives a whole new meaning to the word "geek".

    I know... thats about what I thought.. Its like something I'd come up with...!

  • Anyone wanna make any any bets on how soon 8.11 comes out.
  • Suydam: sendmail [...] has GOT to be the most complete, and configurable piece of software on earth.

    Now playing on a computer near you: EMACS: The Extraterrestrial.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...