Security-Fix Sendmail 8.12.9 Released

bahamutirc writes "Yet another security problem was discovered by Michal Zalewski in Sendmail 8.12.8, 'a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable.' Apparently somebody jumped the gun and posted before Sendmail had a chance to notify anyone, so they had to release it today. Go grab your source." Here's the CERT advisory.

Comments

See

[Exiler]

This is why every variable should just be a long int darnit

Re:See

[saskboy]

long int foo = 87;
long int foobar = 2;
long int foofoobar = 0;

foofoobar = (long int)foo / foobar; //???

Re:See

[Anonymous Coward]

Ummm, that wouldn't be too good for memory.

Re:See

[cide1]

Depends on the level of optimization. Many compilers will allign variables on the native processors word size, at a high enough level of optimization. I think Visual C++ actually has this as a size vs. speed tradeoff. This is one of several reasons that the sizeof a struct is not neccessarily the sum of the size of it's components.

An int is normally defined as the most natural size for the target architecture. Hence, on intel, int and long int are both 32 bits. I do not like to use this nomenclature, and instead, I put in my header files something like

typedef unsigned long int n32;
typedef signed long int s32;
typedef unsigned short int n16;
typedef signed short int s16;
typedef char s8;

and whatnot, so that I know exactly what I'm getting. This also helps when it comes time to port to new architectures, cause all your changes are just a header file, as long as you don't need the benefit of a longer word size.

About the only time I use something other than 32 bit ints is when I'm reading or writing from 8 or 16 bit hardware registers, when writing lowlevel drivers, because there is normally no speed differance.

Re:See

[Anonymous Coward]

glib is a wonderful thing

Re:See

[dabootsie]

There are some fundamental problems with using that approach for purposes of portability. Namely, the fact that a byte isn't always an octet of bits. In fact, the only thing the C standard guarantees you is that a byte is at least 8 bits wide.

You could have an architecture with an 11-bit byte, which would make your typedefs impossible to satisfy. All code that depends on on a byte being exactly 8 bits wide (eg: a bit field that undergoes rotation), will have to be completely rewritten to get it to work on that arch.

Truly portable code does not make assumtions on things that aren't guaranteed by the C standard.

That said, 8-bit bytes are by far the most common. Just don't expect that header file to save you if you have to port to an esoteric architecture.

Re:See

[cide1]

Good point, I'll keep this in mind next time I'm working on a PDP/11 (heh, thats older than me) (36 bit word size). I think it was Peter Van Der Linden, of Sun fame, who said "Code isn't portable, it is only ported"

When porting code, you can almost always use a larger type, so if I was porting from an 11 bit architecture, to a more "normal" (If powers of 2 is really normal), I would make sure to use 16 bit ints, (as an initial stab, to truly do it right, you have to read each individual line of code, and understand the logic). A lot of risk is taken when moving from a 36 bit word size to 32, because the number that your integers roll-over at is now 16 times small.

Your example of a bit-field that goes under rotation just sounds dangerous to put in any code. I try to avoid things like that, because 5 years ago, who would have thought that all kinds of code would be ported from 32 and 64 bit Solaris and HP-UX to 32 bit Linux?

Better than exchange still

[fuqqer]

Nuff said.

Re:Better than exchange still

[Anonymous Coward]

and who are these sad excuses for human beings?

I bet they're not spending their saturday posting on slashdot.

Oh, btw, they're called 'girls'. HTH

Good.

[liveD ehT]

I'm glad they kept this SM exploit fairly quiet. You would have thought it would become public and cause lots of mischief, but now that there is a fix, I suspect they will release what the problem was in more detail. So we can encourage people to upgrade, right? :)

~ The Devil

Re:Good.

[Anonymous Coward]

I'm glad they kept this SM exploit fairly quiet. You would have thought it would become public and cause lots of mischief, but now that there is a fix, I suspect they will release what the problem was in more detail.

If this was a Microsoft problem and they kept it quiet you would have been ranting and raving right now, right?

Re:Good.

[liveD ehT]

You wouldn't have? :)

Re:Good.

[dbarclay10]

If this was a Microsoft problem and they kept it quiet you would have been ranting and raving right now, right?

Were it a Microsoft problem, they would have known about it six months ago and not told anybody.

Were it a Microsoft problem, three months ago their customers would have started reporting the problem (along with the exploits people had been trying to use), and Microsoft would have denied everything.

Were it a Microsoft problem, four months after discovery they would have released a patch which broke almost every system, and the advisory would have stated that risk was "minimal", despite the fact that they'd known about the problem for four months and people had been actively using exploits for two months.

Were it a Microsoft problem, six months after their initial discovery they would have finally released a patch that worked ... and charged you for it.

Thank you CERT.

[edunbar93]

Patched and there's only 3 comments posted. Damn I'm good! :)

I would like to thank CERT for sending this security notification on a Saturday that I was working, rather than on a Saturday that I was not.

Re:Thank you CERT.

[liveD ehT]

I would like to thank CERT for sending this security notification on a Saturday that I was working, rather than on a Saturday that I was not. I will let them know.

~The Devil

Well you just do that

[Anonymous Coward]

Be sure to remind sendmail users that you're doing it!

Re:Well you just do that

[Anonymous Coward]

Okay! I will.

Attention Sendmail Users: I'm going to go grab Qmail now.

You musn't patch today!

[jerryasher]

It's patch every other day; today isn't any other day, you know.

Too late sendmail monkeys!

[Dogun]

I switched to postfix last time! MWAHAHAHAHA!

Sendmail....

[Chester K]

Sendmail: The IIS of Open Source.

This is the straw that breaks the camel's back. I'm changing to another MTA.

Re:Sendmail....

[SgtPepper]

Qmail is small, fast, easy and secure.

Re:Sendmail....

[dissy]

> Qmail [qmail.org] is small, fast, easy and secure.

Yes but qmail and postfix dont do near as much as sendmail.

Most of the people using sendmail (Myself included) use it because its the only option for our needs.

Until qmail and/or postfix reach the feature set of sendmail (or come anywhere near it) it will remain useless to me.

Thank you for preaching, please drive through.

Re:Sendmail....

[Anonymous Coward]

might I suggest qmail...

I cut my teeth on sendmail back in '88. Back then there was WIZ, DEBUG, uudecode, the program mailer, and a myriad of other security holes that nobody really paid any attention to since the world was mostly connected via UUCP (anybody remember uumap?). I threw out my last 4.2BSD (yes 4.2BSD) sendmail documents that Eric wrote last year (along with the new! spiffy! m4 doc).

I got fed up two years ago and made the jump to qmail. Haven't had a single security concern to worry abount since then, and with qmail's SPAMCONTROL patch I love watching the spam stop at the front door so to speak.

Despite all of the security focus in the last decade, sendmail is *still* just as broken today as it was back then. The more things change, the more they stay the same... /usr/lib/sendmail -bt -d21.20
3,0 I%hate!sendmail

- an ex-sendmail-bug-of-the-month club member

Re:Sendmail....

[kuroth]

> What does [sendmail] do that [qmail] doesn't?

It gives you something to do on Saturdays. See, the sendmail team knows how tedious it is to do things like spend time with your wife and kids, play fetch with the dog, wax the car, and mow the lawn. Therefore, every two to four weeks, they release a fantastic new remote exploit, so you can spend your Saturday patching stuff or running your package management program of choice.

This stands in start constrast to qmail. If you were running qmail, you'd have no choice but to spend all that annoying "quality" time with your friends and family. Secure and reliable? Honestly, I don't know what DJB was thinking.

Re:Sendmail....

[Vainglorious Coward]

qmail and postfix dont do near as much as sendmail.

And sendmail doesn't do as much as Exchange, so what's that got to do with it? The major weakness of sendmail compared to qmail is precisely that it's a monolithic beast that tries to do everything. Qmail's approach is to have small modules that perform one task, and perform it well (and securely - still no claims on the security guarantee in six years).

Thank you for preaching, please drive through.

Seems to be that like many others, it's the author of qmail that's your problem, not the actual software. So go on, tell us : what features does sendmail provide that can't be found in other MTAs?

Re:Sendmail....

[slamb]

Yes but qmail and postfix dont do near as much as sendmail.

Care to provide examples? I've never seen anyone actually come up with a useful thing you can do with sendmail but not postfix, for all the times people have said this.

Hell, even if you do have to patch Postfix's C source, it's probably still easier than doing whatever in sendmail's m4-preprocessed cf files. I have written a patch to Postfix, and it was not difficult.

Re:Sendmail....

[dissy]

Perhaps I just dont know the undocumented tricks of those mail servers.

If anyone could give me either detailed instructions on how to translate from sendmail to qmail/postfix configs, or a good website that explains this, I would be most grateful.

Please do keep in mind my only experence with qmail or postfix was reading the documentation to see how hard it would be to convert my sendmail setup, and seeing most of the features i need not being listed, i didnt bother setting them up.
I am not at all familiar with the config files used by either.

I am also assuming in this post one IS familiar with sendmail.
Where i simply say virtusertable, that would of course be /etc/mail/virtusertable.

I use the short names assuming you know what i mean. In a reply, please use the long form when describing qmail/postfix, as i have no clue whats what :)

My current setup uses sendmails virtusertable for all domains i handle.
There is never an instance where mail sent to user@domain will just deliver to the account user, which is sendmails default method of delivery.
Every domain i have in my cw file is in virtusertable.

That said, the features I need are:

Fall-through addresses

in sendmails virtusertable if you add @domain.com
if the email address doesnt match a specific entry in virtusertable for a domian, it will then deliver using that rule.

Configurable bounce errors

I have some addresses (and some domains fall-through address) have entrys as:
@domain.com error:nouser No such user
which returns the correct error code and the text message above.

Delivery to a piped process

in sendmails aliases file you can add an entry such as
somealias: "|/path/to/an/app"
and sendmail will execute that program passing the email to its stdin.

Backup mail spooling

Where the server accepts mail for a domain but doesnt attempt to deliver it locally, just forward to a mail server with a higher(lower) MX priority.

Support 'list' forwards

IE staff@domain.com -> account1, account2, outside@emailaddy.com
Sendmail does this really ghetto by using both virtusertable and aliases, as only aliases can have multiple places of delivery, but virtusertable can send domain mail to an alias easily enough.

Access controls for relaying

I use IP addresses to control who can send mail out through the mailserver (Only machines in my IP space, as well as a couple friends statics are on the list)
I would be interested in smtp-auth in the future but until I finished the server transistion I would want the functionality to remain as-is, and inform my users later for new and added features, preferably without having to say older features will no longer work.
Doing without smtp-auth would also be fine with me.

Domain mirroring

In sendmails virtusertable, if you have say 3 domains that use the same mappings, you can do the following:

user1@domain.com user1 ...
user99@domain.com user99
@domain.com error:nouser No such user

@domain.NET %1@domain.com
@domain.ORG %1@domain.com

Then you only need to manage one list (for com) and if you sent mail to user1@domain.org it would rewrite it as user1@domain.com

Also for local delivery, the mailer would need to work with procmail.
Im sure qmail and postfix both do, so that shouldnt be a problem. Just wanted to mention it incase..

If qmail/postfix really can do everything above, then i stand corrected, but would ask either for a source of good documentation, or just an explnation on each point for how to do it the qmail/postfix way.

Thanks

Re:Sendmail....

[dissy]

> And sendmail doesn't do as much as Exchange, so what's that got to do with it?

If i was using exchange and needed all its features, and someone told me to change to sendmail because it would be better, I would make the same reply as i just did.

I dont need exchanges features, but do need sendmails. Changing to qmail/postfix (assuming they really dont have all the features of sendmail) isnt an option, yet thats what everyone is telling me to do.

Thats what it has to do with it :P

> So go on, tell us : what features does sendmail provide that can't be found
> in other MTAs?

The poster I replied to also replied to me asking that question.
I responded with a large post listing them all.

It should be here:
http://slashdot.org/comments.pl?sid=58903&c id=5623 856

Re:Sendmail....

[dissy]

> Care to provide examples?

http://slashdot.org/comments.pl?sid=58903&cid=56 23 856

Already did in reply to another user :)

I would be most greatful for any help proving me wrong.

Re:Sendmail....

[j3110]

I only see two things that you ask for that I'm not using Qmail for right now.

I hate setting up qmail, but it even has an easy to use web interface for configuring those things.

I haven't tried domain mirroring, but I'm sure you can do it with a simlink.

I don't know if anything else can do piped mail processing. If you ask me, I think that's a security risk in itself.

Re:Sendmail....

[0x0d0a]

Send the above post to the qmail/postfix mailing lists and see what happens.

I can tell you that postfix definitely works with procmail. :-)

Re:Sendmail....

[mosch]

You can do all of those things with postfix. Either contact the postfix mailing lists, or a decent consultant for more details.

Re:Sendmail....

[bafu]

Most of the people using sendmail (Myself included) use it because its the only option for our needs.

Until qmail and/or postfix reach the feature set of sendmail (or come anywhere near it) it will remain useless to me.

Unless you are a serious user of milter features (an extensive MIMEDefang setup, for instance) I think you'll find a switch to postfix or qmail to be a net plus. The learning curve probably won't be as bad as you assume... just set up a test server someplace and see what's actually involved in getting it to do what you want.

As a longtime sendmail admin myself, I think I can understand your resistence: "Why screw with a working mail setup?" But when you have to keep sweating repeated vulnerabilities in a huge process that runs as root, you have to start wondering how elastic the definition of "working" has become. Anyway, stop reading config docs and give one of the modern MTAs a real test drive! ;-) You'll probably be pleased.

Re:Sendmail....

[Anonymous Coward]

Qmail does all of these, and I bet the other MTAs do as well. There's plenty of useful documentation at qmail.org on how to migrate. I find it bizarre that you consider these features to be unusual in at MTA. I consider them necessary and normal.

"Fall through addresses" (default delivery instructions)
put "example.com:alias-example-com" in /var/qmail/control/virtualdomains
put default delivery instructions in ~alias/.qmail-example-com-default

"Configurable bounce errors"
You can do this either with piping to a bounce program, or via any of the appriopriate patches linked from qmail.org.

"Delivery to a piped process"
Just put |cmd in the .qmail file which corresponds to that rule.

"Backup mail spooling"
Put the domain to spool for in "rcpthosts" but not in "locals" or "virtualdomains".

"'list' forwards" .qmail files may contain any number of recipients, be they pipes, users, files, or Maildirs.

"Access controls for relaying"
This is controlled via ucspi-tcp, the socket interface preferred for qmail. It's very simple and powerful, and there are patches for doing elaborate things like "pop before smtp" to allow roaming users to relay without authentication.

"Domain mirroring"
Just point your virtuals at the same alias. here's your /var/qmail/control/virtualdomains:
example.com:al ias-example
example.net:alias-example

Qmail ONLY works with procmail. It requires procmail for local delivery.

What makes Qmail seem so difficult is that it's DEAD SIMPLE. When comparing to sendmail, I used to get confused. How can it be this easy? I don't understand! Well it is. It took me a few weeks to get out of my sendmail mindset, but once I did, I was glad.

Re:Sendmail....

[ldspartan]

Although I am not a qmail expert by any stretch of the imagination, I'm pretty damn sure you can do all of that with qmail combined with vpopmail, a reasonably popular virtual-user package (GPL, of course).

Fall-through addresses: Done easily in vpopmail.

Configurable bounce errors: bounce-saying in the .qmail file for that address.

Delivery to a process: put "|/bin/appname" in your .qmail file.

Backup mail spooling: Put the domain you want to be a secondary for in /var/qmail/control/rcpthosts, make sure it doesn't appear in locals.

"list" forwards: Put multiple addresses in your .qmail file, on seperate lines.

Access controls for relaying: Done with ucspi-tcp by setting environment variables based on IP of clients.

Domain mirroring: one command with vpopmail; 'valias'.

All of this is well documented in "Life with Qmail," a great reference.

--
Phil

Re:Sendmail....

[dissy]

> All of this is well documented in "Life with Qmail," a great reference.

I will defiantly check that document out.
My main problem before was the only place i knew to look for docs was qmails site itself. Now hopefully that i know what to look for...

But i do have one question:

> Fall-through addresses: Done easily in vpopmail.

As a fall through address is something that is basically a method to deliver mail, how can a popper do this at all?

Mail comes into your MTA, not your popper :}
(I think im just misunderstanding)

Also, I dont use pop or imap myself at all. I still use pine (and no i will not change heh)

But what i mean by fall through address is, for example:
friend@domain.com friend123@hotmail.com
otherfriend@domain.com somewhere@otherisp.com
@domain.com dissy

so if its not directed to friend@ or otherfriend@, i get it delivered to my spool (Or forwarded, or whatever.)

It would seem to me this step is required in order to put the mail somewhere on the system (vs bouncing it) so that a popper could get to it.

Thanks for the advice thou!

Re:Sendmail....

[slamb]

I would be most greatful for any help proving me wrong.

Looking at that list, most of your stuff deals with sendmail's virtusertable. Postfix's virtual map does the same thing. The only thing I don't know that it supports is domain mirroring, but you could accomplish that by preprocessing the virtual file a bit.

The alias file format is the same as sendmail's. (Well, not quite true; it supports two file formats; one is the same.) Everything you can do with sendmail you can do there, though you need to keep in mind that it happens as user Postfix.

The other stuff, you just need to go through the documentation more thoroughly. It'd be a waste of my time and yours to give a not-quite-as-good version of what it says. But Postfix can do those things.

Re:Sendmail....

[witwerg]

This is just a really quick overview because there are a few things I would have to lookup again for postfix, and don't quite have time to write a fully detailed essay(good for postfix 1.11).

Main Configuration/Documenation

Most of the configuration is done with /etc/postfix/main.cf and /etc/postfix/master.cf. The first sets configuration variables, and the second one sets up the various daemons which are used for queuing, delivering, sorting, and sending mail. The primary documentation are the man pages that come with it, and /usr/<documentation directory>/postfix. Also see www.postfix.org for FAQ's, HOWTO's and mailing lists.

Tables

Postfix supports a wide variety of Table types. sendmail uses "hash" I think.. But you can also have tables based around mysql or ldap, for example. I use LDAP almost exclusively. So my knowledge is very much specialized about that behemoth. Anyway, when I say specify a table this is done in the form

• TYPE:LOCATION

The Type is the type of table/format being used. The Location is simply one of several things

1. For simple tables like gdbm or has it is the location where the table is on the disk,
2. For mysql it's the location of a configuraiton file for the mysql table(i think)
3. For ldap it's the name of the ldaptable and there are additional configuration variable to setup.

For backwards compatibility, hash:/etc/alias is normally setup as an alias database.

Virtual Stuff

Also note the following distinctions that I used, I hope this doesn't confuse anyone reading the other documentation.

• Virtual User -- an address in a fake domain that gets routed to other addresses these are done by creating virtual tables. The configuration variable virtual_maps is set to set space-delimited list of tables to use as virtual tables. So hash:/etc/.../virtualusers should get the map working(I think). Remeber the man pages are very good. See virtual(5) for more.
• Virtual Mailbox -- a user in a fake domain that gets routed to it's own mailbox, but has no associated user account on the machine. This gets more complex, however, as you have to set locations, gids, uids, transport(the method of delivery). See virtual(8)

Fallback Address or "Catchalls"

Catch-alls operate like in sendmail, add an entry to a virtual user table in the variable virtual_maps with the "key" @domain.com. However, since virtual mailboxes are done after virtual_maps they aren't very compatible with catchalls.

Configurable bounce errors

I'm not sure this there is a way to completely customize the return error, but adding an entry domain.com (not @domain.com) the actually data doesn't matter,, just the entry so set it to unknown for readability. This creates a postfix-style virtual domain which should reject unknown users with the appropiate error. see virtual(5).

Delivery to a piped process

Yes you can. You have to edit the /etc/postfix/master.cf in order to setup the service for delivery. Here are some examples:

cyrus unix - n n - - pipe
flags=R user=cyrus argv=/usr/sbin/cyrdeliver -e -m ${extension} ${user}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

Backup mail spooling

In postfix these is a transports map that has three fields: domain(key), transport(service to deliver), nexthop(next machine in chain). An entry has a form the actual data for the entry is in the form tra

Re:Sendmail....

[Vainglorious Coward]

...my only experence with qmail or postfix was reading the documentation to see how hard it would be to convert my sendmail setup...

I don't see anything unusual in your list. Do you think there aren't qmail users who have widely varied and specialised needs? I'm not going to pretend that you won't have to do any reading and learning in order to migrate to qmail, but that's very different than claiming that only sendmail has the features you need. Unfortunately, I am unable to give you step-by-step instructions, but given that you're intelligent enough to understand how to configure sendmail, you shouldn't have any problem starting with the qmail home page and proceeding from there. Also good is life with qmail.

Re:Sendmail....

[Vainglorious Coward]

Also, I dont use pop or imap myself at all. I still use pine (and no i will not change heh)

Switch to using maildir anyway. Seriously. Pine will work with maildir format, but now you can also hook other stuff on top : courier to provide imap service (I always do it over ssl myself), and web access (again over ssl) with either sqwebmail or squirrelmail. Best of all worlds!

Re:Sendmail....

[bcrowell]

I decided to bite the bullet and replace sendmail with qmail. Having gotten partway through the process and learned a little about it, I'm now not so sure it's a good idea:

• Qmail isn't free-as-in-speech. It has some goofy license that doesn't allow redistribution of modified sources. In other words, you can't fork it. This is such a drastic deviation from the way the world of open-source software normally works that it really gives me doubts about using the software.
• On my FreeBSD server, installing qmail would apparently require a reboot (because of daemontools). Holy cow -- what is this, Windows? Since when does installing Unix software require you to reboot your server??
• Can't get any response from the cr.yp.to server when I try to download ucspi-tcp, which is another package that qmail depends on.

Re:Sendmail....

[dohcvtec]

There is never an instance where mail sent to user@domain will just deliver to the account user, which is sendmails default method of delivery.
Heh, apparently my employer's ISP is too stupid to realize this factoid. We (being a small company, where the suits handle IT stuff) have our email handles by our ISP, where we have username@ourcompany.com addresses. However, at least half of the spam I get is addressed to username@ourisp.net. I always knew this is what was happening, but I never realized exactly why. Apparently, if these idiots would smarten up and do as you do and have a virtusertable, my inbox would be a lot less cluttered :) The real pisser is that most people are clueless enough to think that this ISP actually provides good service.

Re:Sendmail....

[thogard]

Before you go bashing sendmail, why not go through all the sendmail patches (say post V5) and see what they fixed. Then find out if your MTA might have that issue and if so, was it fixed. You may find that many sendmail bug fixes are to workaround bugs in things like the local delivery agents.

Most sendmail patches are to work around bugs in the OS or libraries. Some of the race conditions patches that were patched long ago also exist today in other MTAs. If you look closely, you will see that some of the sendmail patches for race conditions also appear in things like INN and Apache.

The biggest security problem on deamons is they need root to bind to a low port. In most OS's its trival to patch them to allow programs to open low ports if they are a memeber of a group that equals the port id. A trival fix and the many of the problems would go away forever but it breaks an old "security" hack.

Re:Sendmail....

[prog-guru]

That said, the features I need are:

Here is another, no way to run the queue manually.

IMO, the biggest problem with Sendmail is too many people run it as a daemon, you only need that if you intend on accepting mail from the network. Either don't run it as a daemon, or bind it to 127.0.0.1, if you need better performance (like on a big webserver).

On a side note, you can run Qmail as a daemon, and install sendmail with submit.cf, then it will seamlessly send mail through your Qmail server when executed by scripts and stuff. It doesn't even need to be setuid root anymore.

I bet if Qmail were as widely used as Sendmail, people would find more bugs, it's really more like security by obscurity.

Re:Sendmail....

[ldspartan]

vpopmail is a MDA (delivery agent). qmail hands off deliveries for virtual domains to vpopmail, which then actually handles the delivery stage.

And yes, you can still access things via Pine, or Mutt, or IMAP, or POP3, or what have you. The mail is stored in the Maildir format, which is tremendously superior to mbox.

And yes, you can set the 'default' rule for a domain; be it to bounce, or deliver to a user.

Re:Sendmail....

[Electrum]

Qmail ONLY works with procmail. It requires procmail for local delivery.

Wrong. qmail can use procmail to deliver to /var/mail. It can natively deliver to mbox or the much superior Maildir.

Re:Sendmail....

[Electrum]

As a fall through address is something that is basically a method to deliver mail, how can a popper do this at all?

Mail comes into your MTA, not your popper :}
(I think im just misunderstanding)

You are misunderstanding. vpopmail is a virtual domain manager for qmail.

Re:Sendmail....

[Electrum]

Qmail isn't free-as-in-speech. It has some goofy license that doesn't allow redistribution of modified sources. In other words, you can't fork it. This is such a drastic deviation from the way the world of open-source software normally works that it really gives me doubts about using the software.

Nice troll. qmail has no license. Thus, you are only restricted by copyright law. You are free to install and use the software. You are also free to distribute patches. How does this negatively affect your usage of the software?

On my FreeBSD server, installing qmail would apparently require a reboot (because of daemontools). Holy cow -- what is this, Windows? Since when does installing Unix software require you to reboot your server??

Wrong:

# cd /usr/ports/sysutils/daemontools
# make install clean
# mkdir /var/service
# ln -s /var/service /service
# cd /usr/local/share/examples/daemontools
# cp svscan.sh.sample /usr/local/etc/rc.d/svscan.sh
# chmod +x /usr/local/etc/rc.d/svscan.sh
# /usr/local/etc/rc.d/svscan.sh start

Can't get any response from the cr.yp.to server when I try to download ucspi-tcp, which is another package that qmail depends on.

He lists all network outages on the front page of the server. I don't see any listed for the last four months. Perhaps you should try again.

Re:Sendmail....

[maw]

Incorrect. You can certainly start svscan without rebooting your computer. However, saying "reboot" is a lot easier than explaining how to do it.

Re:Sendmail....

[LinuxHam]

Either don't run it as a daemon, or bind it to 127.0.0.1, if you need better performance (like on a big webserver).

Sendmail installs in RH (maybe more) have been configured exactly this way since 7.3 or earlier. May have been 7.2. During my 4-day RHCE class, I actually had to show the class (and instructor) how the default install was changed to INCLUDE a line in sendmail.cf causing sendmail to only bind to lo. Otherwise, without that line, sendmail will bind to all interfaces. I think it was a great idea for improving security without reducing functionality for end users.

Re:Sendmail....

[tigga]

qmail experience could be frustrating at least..
You have to install qmail, tcp-ucspsi, vpopmail, ezmlm, daemontools, maybe some other programs and patch, patch and patch to achieve about the same functionality as sendmail has. And not everything could be done anyway.

Besides that with sendmail you have all configuration files in /etc/mail directory and with qmail you have files all over the place - /var/qmail/control directory, /etc/tcp.smtp.cmd, ~alias/ and .qmail files in user directories.
One more inconvenience I encountered with qmail - all spool files are named as their inodes. If you move them to different partition or server then filenames no more relate to inode numbers - your spool screwed up..

Re:Sendmail....

[Tet]

And sendmail doesn't do as much as Exchange

Equally, exchange doesn't do as much as sendmail. They both have different feature sets, which overlap in places, but each does some things that the other doesn't. But then the two aren't really comparable in the first place. Sendmail is a pure MTA. Exchange isn't.

Re:Sendmail....

[pchown]

Exim does all this. The domain mirroring would be done in a rather different way, but the effect is the same. Everything else is pretty similar to Sendmail.

Exim has some nice features of its own, too. You can tell it to verify senders by calling their MTAs and starting the process of delivering a reply. (The process is stopped before they actually get anything.) This catches a lot of spam; my log file is full of messages from Hotmail saying that hotsex123@hotmail.com has exceeded its quota...

Exim can also pull addresses out of SQL databases, and use Perl to control message routing. This is tremendously flexible for large sites. For example a company's main gateway could have an SQL database that is used to map joe@bigcorp.com to joe@london.england.bigcorp.com and so on. I once developed a system where users were created with a CORBA remote procedure call. The Exim end worked like a dream; providing POP to these accounts was a pain.

Some while ago, I looked at Postfix because it's bundled with RedHat. As far as I can tell, it's nothing like as flexible. I really wish RedHat would bundle Exim instead, because it's a pain to go looking for Exim RPMs. :-(

Re:Sendmail....

[bcrowell]

Thanks for the technical info!

Nice troll. qmail has no license. Thus, you are only restricted by copyright law. You are free to install and use the software. You are also free to distribute patches. How does this negatively affect your usage of the software?
True or false? -- It's illegal for me to modify the source code and redistribute the modified version.
True or false? -- Qmail complies with OSI's open source definition.

Re:Sendmail....

[Electrum]

True or false? -- It's illegal for me to modify the source code and redistribute the modified version.

How does this negatively affect your usage of the software?

True or false? -- Qmail complies with OSI's open source definition [opensource.org].

How does what OSI thinks negatively affect your usage of the software?

(I have at least a dozen machines running qmail. These magic problems don't affect me or anyone else I know that runs qmail. Yahoo! runs qmail. It doesn't seem to affect them either.)

Re:Sendmail....

[3247]

Fall-through addresses

~alias/.qmail-domain-org-default

Configurable bounce errors

in .qmail-*:
|echo "Error message (#a.b.c)"; exit 100

Delivery to a piped process

in .qmail-*:
|command

Backup mail spooling

add the domains to /var/qmail/control/rcpthosts but not to /var/qmail/control/locals; maybe also set up /var/qmail/control/smtproutes.

Support 'list' forwards

Add the addresses to ~alias/.qmail-address, you can even redirect bounces by setting up ~alias/.qmail-address-owner.

Access controls for relaying

See the qmail FAQ.

Domain mirroring

Just let all of the domains point to the same user, e.g. in /var/qmail/controls/virtualdomains:
domain.org: domain-org
domain.com: domain-org
domain.net: domain-org

What exactly is it that qmail can't do?

Re:Sendmail....

[apdt]

erm.... I'd like to challenge you on one point:

Qmail ONLY works with procmail. It requires procmail for local delivery.

In my experience, procmail is not required at all for qmail. I have several sites using qmail that don't use procmail.

I suppose it may be necessary if you want to do delivery into /var/spool/mail/$USER. I've never wanted to do that though. If you need mbox delivery, why not just use ~/.email or something similar.

Re:Sendmail....

[apdt]

even better than that, just create the following symlinks:

/usr/lib/sendmail -> /var/qmail/bin/sendmail
/usr/sbin/sendmail -> /var/qmail/bin/sendmail

to use qmail's supplied sendmail wrapper.

Re:Sendmail....

[apdt]

I bet if Qmail were as widely used as Sendmail, people would find more bugs, it's really more like security by obscurity.

A couple of points about that statement:

-Qmail claims to be the number 2 MTA on the internet (although I haven't seen any figures to back that up). I think that counts as widely used.
-The qmail code is significantly smaller than sendmail, so by the laws of statistics alone, it will fewer flaws.
-There was a reward of $1000 offered to anyone who could find a verifiable security hole in qmail that went unclaimed for 3 years.

On the whole, qmail has a pretty good track record with only one minor bug that I've heard about(I started using it at version 1.03, so I can't speak for earlier versions.)

Re:So?

[alitaa]

if you dont care, dont read it...
go back rebooting your exchange "server"

Sendmail advertisement

[statusbar]

"Providing hackers with security holes for DECADES" --jeff++

Re:Sendmail advertisement

[Waffle Iron]

How about: "Over 22 years without no remote hole in the default install."

Is Sendmail still worth it?

[mnmn]

I fought with the M4 format of sendmail.cfg for a while in setting up a complex system before switching to qmail. Ive tried postfix too, but I still see diehard sendmailers around.

For one, sendmail is really not intuitive. If youre given a server youve never seen before and have to alter some fancy configs in it, could you do it faster than if it were say qmail? Maybe if I stare at M4 pinfo I could begin to get it, I gave up early there.

Secondly these security problems.

So beside the fact that sendmail is the standard, quite mature and very flexible if you know how to config it, does it have any big edge over postfix or qmail that everyone should know about?

And can the sendmail developers be brave trailblazers and finally change the config file syntax to just text words like httpd.conf?

Re:Is Sendmail still worth it?

[Just Some Guy]

For one, sendmail is really not intuitive. If youre given a server youve never seen before and have to alter some fancy configs in it, could you do it faster than if it were say qmail? Maybe if I stare at M4 pinfo I could begin to get it, I gave up early there.

That's not insightful; that's personal opinion. Sendmail's m4 configuration is pretty logical and editable for me, but I have no idea how to alter a running Qmail setup. Does that make Sendmail better than Qmail? No. It makes me better at running Sendmail than Qmail.

Re:Is Sendmail still worth it?

[Jordy]

And can the sendmail developers be brave trailblazers and finally change the config file syntax to just text words like httpd.conf?

My main sendmail config file is a whole 32 lines long and includes SMTP authentication methods, blacklists, load avg checks, privacy options and of course the delivery mechanism.

The only thing I don't have that I've been thinking about adding is LDAP support, but that's only another line in my conf file and modification to where all the db maps point to.

I have trouble sharing your confusion in configuring something that needs so few options in a typical setup.

So beside the fact that sendmail is the standard, quite mature and very flexible if you know how to config it, does it have any big edge over postfix or qmail that everyone should know about?

Mmm, I would have thought being standard, mature and extremely flexible would be enough.

Just buy sendmail from sendmail.com if you don't know how to configure all those really advanced options like priority boosts for certain types of messages, different delivery paths based on if a message has attachments (virus scanners are too slow to handle all messages in big environments), quarantine of potential spam for manual review by administrators (very useful in companies), or manually tune outgoing queues to force sendmail to do MX lookups for up to 5 minutes 10 seconds before attempting to dequeue a message with more than 1000 addresses to reduce bandwidth usage (the same mail server handling multiple domains can send to two users using only one message body).

They give you a nice little GUI that makes everything nice and easy to configure. Not to mention a high availability solution and a stupidly high volume mail solution.

Advisories, more like invatations to exploit

[Neophytus]

Developers recently have been getting fed up with security "advisories", that include an exploit, being posted on most "security" websites before they have even been notified. Unfortunatly this leads to many script kiddies getting their kicks from "owning" a popular site before they have been patched, and probably many of the websites that exist exist purly for this purpose. Sendmail are just the latest people to fall victim from this.

Re:Advisories, more like invatations to exploit

[grokBoy]

Well, the Full-Disclosure list that I am involved with was one of the ones that received the premature announcement, but I'm sure you'll agree that even with the follow-up it was far from anything that provided a remote exploit. The tone of the thread seemed to indicate that there was already interest in this 'in the wild' before it was disclosed to the lists in question, in any case. Kudos to the Sendmail team for getting the fix out so promptly.

requisite 'switch' message

[Anonymous Coward]

To avoid all this people should change to {postfix|qmail|smail|other}. It doesn't have this problem.

Sendmail

[drizuid]

Alot of people suggest just switching to something else. Obviously, they don't want to. I use sendmail all the time, I love sendmail. If this was a windows app, i might switch, but being opensource as it is, when the holes are discovered, they are patched pretty quickly. I don't really see much point is saying switch to qmail or something else, people who want to use sendmail will keep using it.

Re:Sendmail

[khuber]

I don't understand why anyone would run sendmail as their MTA with all the alternatives. It's insecure by design -- it's a monolithic suid root program. It's inefficient and it's difficult to configure.

Why? For the love of SMTP, why??? j/k

-Kevin

Re:Sendmail

[axxackall]

but being opensource as it is, when the holes are discovered, they are patched pretty quickly

Usually people suggest you to switch to postfix, qmail and courier - all three are open source as well.

I'll add that Courier's major developer is a very arrogant persont ignoring real life things and that gives you a quite good MTA with no support whatsoever.

The major complain of Qmail users (acrttually admins) is very similar: the major developer is concentratied on revolutionary new version of his program, so no big improvement or serious bug fixes for about two years in the current release.

As for Postfix, I love it's flexibility "up and down" - it's extremely easy to configure a home-based mail server as well as a corporate distributed mail system. It has very clear design and bery simle (still power!) config syntax. Development is not frozen, so are the developers. Besides, it's still has a support for both mailbox formats.

Few surveys and polls (one of them) I did demonstrate the trend that most of former sendmail users switch namely to Postfix. No need to mention that most of MTA switchers are moving from sendmail :)

people who want to use sendmail will keep using it

The good news is that most of people do not want to use sendmail. Thay want to use MTA. Therefore, when they think about alternatives, they may notice that sendmail is not the only opensource MTA. And it is not the best one. That's why there is growing stream of MTA switchers.

But it is not a bad news. It's a challenge for sendmail developers. Now they have to either redesign their child or to choose another open source project where to develop further their own skills. Either is choice is good afterall.

Re:Sendmail

[tigga]

I don't understand why anyone would run sendmail as their MTA with all the alternatives. It's insecure by design -- it's a monolithic suid root program. It's inefficient and it's difficult to configure.

It's not true - it is not suid for a couple years. Only daemon listening on socket is running as root. Delivery is done by process running as smmsp user.

I don't know what you mean about inefficiency..

Sendmail pretty easy to configure for simple use and hard for complex use.
With qmail you need to install some additional programs and configure them separately. Then you may find you need to patch qmail because it was not updated since 1997. Then you may find some functionality in sendmail which just not existent in qmail or very inconvenient for use...

For the love of SMTP

I hope it's a figure of speech - sounds very perversive ;)))

Sednmail holes are GOOD

[Adam9]

See, they give you much needed practice of patching services at a proper pace! Patching it every 2 weeks or so is great practice for every administrator. Every good admin should have at least 1 box with sendmail on it. See, a few years ago I put on qmail. Now my patch skills are severely lacking. When this advisory for sendmail came out today, I said "that's enough, I'm falling behind. I'm going back to sendmail." I think I'll be much more happier now.

Re:Sednmail holes are GOOD

[shepmaster]

Hmm, this is modded 4, Insightful...

Somebody forgot how to read sarcasm... :)

Re:Sednmail holes are GOOD

[rsax]

You are absolutely right, what the hell am I doing running all these servers with NetBSD and Apache. Windows 2000 and IIS, here I come!

Re:Sednmail holes are GOOD

[0x0d0a]

Sarcasm can be insightful.

Re:Sednmail holes are GOOD

[Adam9]

Have you ever spellchecked a post then see typos on it right when you hit the submit button? It hurts.

qmail

[Jesus IS the Devil]

Not a fun thing to always be on the lookout for sendmail exploits. After the thousandth's exploit, I finally got my ass in order and switched to qmail. Much better and easier to configure too!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Dear IT Workers

[I Am The Owl]

Please stop using Sendmail. I'm tired of my favorite IRC networks being DDOSed by machines whose administrators were too incompetent to use a real MTA.

Thank you,
--The rest of the fucking Internet

Re:Dear IT Workers

[khuber]

qmail isn't real open source. It has a weird license that doesn't allow you to distribute modified source! postfix or exim are better alternatives for that reason.

Re:Dear IT Workers

[Dionysus]

qmail is open source. The source is open for all to see. It's not Free Software.

Then again, being both Free and Open doesn't seem to help Sendmail in being bugfree. So much for all bugs are shallow...

Re:Dear IT Workers

[Anonymous Coward]

Qmail is a real MTA? Wow... At least the people running Exchange know when they're running an ugly hack. Qmail users believe whatever that fuckwit djb tells them. Both "MTAs" suck hard.

Re:Dear IT Workers

[Xtifr]

qmail is open source. The source is open for all to see. It's not Free Software.

Qmail is free. The source is free for all to see. It's not Open Source.

Both those statements are true. Informally, you can say that qmail is free and open source - it costs no money, and you get access to the source. Formally, though, it's neither Free nor Open Source - it violates the Free Software Foundation's definition of Free Software, and the Open Source Initiative's definition of Open Source.

But I think it's extremely disingenuous to mix and match the formal and informal definitions like you did. The fact is that the qmail license is extremely annoying, and doesn't accomplish what its author wants (because patching and compiling are easily scriptable). But in practical terms, it is pretty close to being Free/Open Source. If you want to say that licensing isn't necessarily just black-and-white, and that qmail's license is a light shade of grey at worst, I'd agree.

Then again, being both Free and Open doesn't seem to help Sendmail in being bugfree. So much for all bugs are shallow...

Yes, well, absolutely. No Silver Bullets and all. But qmail is as free and open as it is for good reason too. The qmail vs sendmail comparison clearly shows that design remains an important element of software development. But all that "better methodology" stuff comes from the Open Source folks - you're actually quoting OSI founder ESR. The Free Software folks just think Free is morally superior - which, in my opinion, is a matter of opinion, and not subject to formal debate, whether you agree or disagree.

Re:Dear IT Workers

[Anonymous Coward]

Because we all know that the Open Source Initiative trademarked the term "Open Source".

No, wait, they tried but were smacked down by the government for trying to take ownership of a common term.

qmail is open source that is not "OSI(tm) Approved".

Re:Dear IT Workers

[clarkc3]

i'm just tired of administrators who leave their sendmail boxes as open relays so that people can do that - and also every person who tries to push qmail and postfix down my throat

Sourceforge Out of Business

[Anonymous Coward]

Looks like sourceforge has been hacked. There site is permanently donw for maintnemce

Qmail and postfix hippies: shut the hell up please

[CoolVibe]

First, this is about sendmail, not postfix or qmail. Yes we know your MTA is vastly superior and yes, it does your laundry and even makes coffee.

But that still doesn't make sendmail bad. Software has bugs. Your precious MTAs have bugs too. As a matter of fact, sendmail works. It has worked for decades. It's still around. And it will stay around for decades more.

Before y'all jump up and say: "Look! a possibly remote exploit!". Read the advisory. This will be VERY hard to exploit, besides your test lab where you control the address space and eventual host naming that just MIGHT overflow something, and then you need to figure out if it's even possible to do something more fun other than let some sendmail spawned child crash, whoopdeedoo.

Although it's not impossible to do, I still maintain that admins should patch their systems, but you don't have to rush. I don't see script kiddies exploting this one in the coming time yet. And besides, my data isn't worth crap either, so I'm harly a target.

So qmail and postfix zealots, shut the hell up please. We know. Yes, qmail and postfix are nice, and yes, they have some merits over sendmail and yes, I sometimes choose to prefer them for some jobs, but the inverse is also true. Right tool for the job and all that. Now be happy with your MTA and be done with it. Geez, it's only a mail server.

Anyone know if . . .

[bedouin]

this Redhat advisory from a couple weeks ago already addressed this issue?

Re:Anyone know if . . .

[weave]

I doubt it, because I just took the redhat SRPMS and applied the sendmail-provided patch and it applied cleanly...

Re:Anyone know if . . .

[arget]

It does not.

This is new.

What's the difference

[donscarletti]

What's the difference between sendmail and telnet?

You need a password to get root access through telnet!

*ducks barrage of rotten fruit*

But seriously, and without the bad humor, it makes me wonder why everyone allways sees X as the bloated, non-scensical, anacronistic piece of junk that is holding LINUX/BSD back. Hell at least I can understand a XF86Conf-4 file (although the old style XF86Conf file is still rather infuriating).

Re:What's the difference

[dougmc]

What's the difference between sendmail and telnet?

You need a password to get root access through telnet!

Minor nit -- most OSs won't let you login as root via telnet, and haven't done so for a while. So you'll need more than a password -- you'll need a user account, it's password, and THEN the password for root (for su'ing from once you're in.) Depending on the OS and configuration, this user account may need to be in the `wheel' group.

HTH.

Re:What's the difference

[Anonymous Coward]

Hey, you're still a teenager... someday you'll understand sendmail.

All Linux users should be using postfix

[0x0d0a]

I can't understand why any general-purpose distros still ship sendmail. Qmail is good too, though I prefer postfix.

Sendmail takes (on my system) a thousand-line config file just to have sane settings for the modern world. It has a horrendous security history.

Postfix has non-dumb defaults, is quite secure, and I cannot see why anyone wouldn't use it.

Re:All Linux users should be using postfix

[clarkc3]

Postfix has non-dumb defaults, is quite secure, and I cannot see why anyone wouldn't use it

Theres always the people who have used sendmail for years and years and just feel comfortable with it - fixes usually come out very quick anytime a problem is diecovers and once you are used to configuring it - recreating a custom sendmail.cf file takes less than a minute.

sendmail may have a thousand line config - but theres really only 50 or so lines at most people will ever need/want to change - there was only about 10 I ever had to edit for my config.

Mandatory Postfix ad

[Anonymous Coward]

Hi!

Is your sendmail buggy? Would it be time to change to Postfix?

Only $0,00.

Re:Qmail and postfix hippies: shut the hell up ple

[PeterM from Berkeley]

Guess what, you are not "hardly a target". Script kiddies will hack your machine purely to have another platform to run DDOS attacks from, or to hack into yet other machines.

It doesn't matter who you are or what data you have. If you have an IP address, you are a target, period.

Re:Qmail and postfix hippies: shut the hell up ple

[Anonymous Coward]

This one bug doesn't make sendmail bad. The fact that it's had scores of bugs does.

It's "only" a mail server, but what about a company whose email contains very sensitive information? They may feel safe using, say, smtps and imaps, but if sendmail isn't secure, they're sunk. In addition, getting on a mail server may allow access to a local network filled with insecure windows boxes. Oops.

You seem to be way too attached to sendmail. There are better alternatives available, so why not use them? I broke off from sendmail years ago, happily.

You should not create such an attachment to software; I use OpenSSH currently because it's free and works. I won't pretend it's not bug-ridden, though, and if something better comes along, I will switch because I care about security. I don't care if I've been using OpenSSH for years.

Re:Qmail and postfix hippies: shut the hell up ple

[0x0d0a]

Geez, it's only a mail server.

And it's only an editor.

And it's only an operating system.

Come on, without fans of programs, the world would be lots less exciting.

Although it's not impossible to do, I still maintain that admins should patch their systems, but you don't have to rush. I don't see script kiddies exploting this one in the coming time yet. And besides, my data isn't worth crap either, so I'm harly a target.

Yeah, I used to say the same thing until I had a box get broken into.

Re:Qmail and postfix hippies: shut the hell up ple

[dougmc]

If you have an IP address, you are a target, period.

I have an IP address. 127.0.0.1 is mine.

I dare you to hack into this IP address and do something awful to it! I double dog dare you!

I'll even leave sendmail running to help you get in!

I use qmail

[spun]

After researching sendmail, postfix, and qmail, I settled on qmail for it's speed and security. I can't count the number of times I had to upgrade sendmail in the past. I have never heard of a single remote exploit affecting qmail.

Re:I use qmail

[Gothmolly]

And if you find one, DJB will pay you.

Re:I use qmail

[Anonymous Coward]

But only after he publicly insults you. He's an arrogant fuck and his "solutions" (especially djbdns) are a kludge. He seems to have issues with RFCs that everyone else is ok with too (djbdns vs. the world).

Re:I use qmail

[Anonymous Coward]

Are you sure? Check the conditions

If this bug had been found in qmail, it wouldn't count.

Unofficial patched sendmail SRPM

[Laven]

http://videl.ics.hawaii.edu/~warren/fedora/sendmai l-8.12.8-2.fdr.1.80.src.rpm

I converted the security patch to a unidiff and applied it to Red Hat's latest sendmail errata SRPM for Red Hat Linux 8.0. Use at your owk risk.

sendmail security

[Billly Gates]

55 flaws in the code, 55 flaws in the code....

Take one down debug it around 58 flaws in the code...

All open source MTAs suck

[Anonymous Coward]

- sendmail is one huge, bloated, insecure POS.
- There's been no new qmail version for YEARS. Everything you need to add you have to search for on the web and patch it in, with patches conflicting and everything
- exim claims to be easier to configure than sendmail but in reality just replaces the $)(%")( with plain text
- The author of courier is an arrogant prick and I haven't found a way to use virtual domains without it being an ugly hack
- postfix is awfully documented and awkward to use with all its backward-compatibility hacks ...and one last thing: WHO CARES ABOUT SYSTEM USERS? I'd guess 99,9% of all mail today is delivered via dedicated mail systems. Why is every single mail system out there system-user-centric and can only be taught virtual domains with ugly hacks and impractical aliases files?

Re:Qmail and postfix hippies: shut the hell up ple

[Anonymous Coward]

You sound like a frustrated MS marketing slave ...

Good choice!

[Anonymous Coward]

I've been using qmail 1.03 since 1999. Pretty nice to not have to upgrade software every few months because of security issues!

Re:Sendmail.... Opps Hit submits too soon

[witwerg]

Here's the proofread formated version

This is just a really quick overview because there are a few things I would have to lookup again for postfix, and don't quite have time to write a fully detailed essay(good for postfix 1.11).

Main Configuration/Documenation

Most of the configuration is done with /etc/postfix/main.cf and /etc/postfix/master.cf. The first sets configuration variables, and the second one sets up the various daemons which are used for queuing, delivering, sorting, and sending mail. The primary documentation are the man pages that come with it, and /usr/<documentation directory>/postfix. Also see www.postfix.org for FAQ's, HOWTO's and mailing lists.

Tables

Postfix supports a wide variety of Table types. sendmail uses "hash" I think.. But you can also have tables based around mysql or ldap, for example. I use LDAP almost exclusively. So my knowledge is very much specialized about that behemoth. Anyway, when I say specify a table this is done in the form

• TYPE:LOCATION

The Type is the type of table/format being used. The Location is simply one of several things

1. For simple tables like gdbm or has it is the location where the table is on the disk,
2. For mysql it's the location of a configuraiton file for the mysql table(i think)
3. For ldap it's the name of the ldaptable and there are additional configuration variable to setup.

For backwards compatibility, hash:/etc/alias is normally setup as an alias database.

Virtual Stuff

Also note the following distinctions that I used, I hope this doesn't confuse anyone reading the other documentation.

• Virtual User -- an address in a fake domain that gets routed to other addresses these are done by creating virtual tables. The configuration variable virtual_maps is set to set space-delimited list of tables to use as virtual tables. So hash:/etc/.../virtualusers should get the map working(I think). Remeber the man pages are very good. See virtual(5) for more.
• Virtual Mailbox -- a user in a fake domain that gets routed to it's own mailbox, but has no associated user account on the machine. This gets more complex, however, as you have to set locations, gids, uids, transport(the method of delivery). See virtual(8)

Fallback Address or "Catchalls"

Catch-alls operate like in sendmail, add an entry to a virtual user table in the variable virtual_maps with the "key" @domain.com. However, since virtual mailboxes are done after virtual_maps they aren't very compatible with catchalls.

Configurable bounce errors

I'm not sure this there is a way to completely customize the return error, but adding an entry domain.com (not @domain.com) the actual data doesn't matter, just the entry is importent,so set it to "unknown" for readability. This creates a postfix-style virtual domain which should reject unknown users with the appropiate error. see virtual(5).

Delivery to a piped process

Yes you can. You have to edit the /etc/postfix/master.cf in order to setup the service for delivery. Here are some examples:

cyrus unix - n n - - pipe
flags=R user=cyrus argv=/usr/sbin/cyrdeliver -e -m ${extension} ${user}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

Backup mail spooling

In postfix there is a transports map that has three fields: domain(key), transport(servic

supported fix for Red Hat 6.2?

[green pizza]

Does anyone happen to know if Red Hat will be releasing a patch for version 6.2 of their distibution? I suppose I could patch it manually, but it'd be nice to stick with Red Hat fixes until I migrate to a newer version early this summer.

I ask as I belive this weekend is the offical EOL for 6.2 errata.

Re:supported fix for Red Hat 6.2?

[Anonymous Coward]

Seriously.. If it isn't supported, download the sendmail.src.rpm file from redhats errata, apply the patch and compile. I'm sure that if you look around enough there's got to be redhats config in there somewhere...

I still choose Sendmail as my MTA

[please explain]

Sendmail gets a bad name sometimes from folks who gave up on it for various reasons (Too hard?). Sometimes some of these "administrators" can't tell the difference between a Message store and an MTA. /var/mail is not sendmail!

I personally like the way the sendmail community handles these issues when they arise. 2 reports in a row is a bummer, but the frequency is exaggerated. I respect the fact that there are other open source MTAs and think they can be made to work well too (postfix, qmail, exim, etc...).

Please keep in mind that this MTA was around when the network was more of a community (not a lot of .com) and having an open relay was normal. Think ARPAnet.

Sendmail pioneered lots of the AntiSPAM/AntiSPAMMER features that are taken for granted today (advanced relay control, ip to dns a record verify, DNS blacklisting etc...).

There are reasons why many (think mega sized corporations around the world) use sendmail in front of their message store systems (Exchange, Notes, Cyrus, /var/mail, etc...). Think scale and way beyond systems for only 10s of thousands or less.

It has/provides:

The ability to use LDAP information for routing.

The ability to use LDAP instead of a flat Alias file.

LDAP intelligence at the port 25 gateway (Think not have unreturnable bounce messages traveling all the way into the network and then getting stuck at your message store) A smart MTA at the gateway will break the connection and not waste time trying to pass the message through.

Pass based (w/crypt options) SMTP Authentication

Certificate base SMTP authentication

Unlimited relay control options (rule sets and milters)

Built in SMTP encryption (TLS/SSL) with support for PKI systems

Multiple queues and deterministic queuing (queue groups)

Fallback MX (this is huge for failover)

Mid-protocol conversation filtering (Milter, do all of your attachment stripping and message scanning without adding extra hops).

Capable of sending email just as fast as any other MTA without violating RFCs (do you really not want to commit your data to stable storage?) and putting your data at risk.

SMTP pipelining (why open a new connection each time?)

Active development with developers developing to the RFC/IETF's standards and the needs of today's internet.

Ability to be configured to avoid port 25 Denial of service attacks that other MTAs are vulnerable to.

My 2 pennies, just another opinion, now leaving verbose mode...

Re:I still choose Sendmail as my MTA

[Anonymous Coward]

Please keep in mind that this MTA was around when the network was more of a community (not a lot of .com) and having an open relay was normal.

But that is the major PROBLEM with sendmail. Or, do you mean we should continue to use a program with a bad design for today's world _because_ it has a bad design?

Re:I still choose Sendmail as my MTA

[please explain]

I'm not sure how you have come to believe that sendmail has a bad design. That one sentence from the entire post does not support your assumption.

Sendmail led the concept of relay control (see antiSPAM stuff in the original post) because of the fact that it was there when the network (a.k.a. the internet) went through this change.

"Official" qmail has seen no development since 1997 so many modern features are not implemented (such as TLS) and I don't think there is any prospect of serious delvelopment from now on.

Take a look at an example installation at qmail.org. All those small programs need their own config files. The example install at qmail.org had 34 config files to configure

Sendmail is currently more likeley to keep up with the evolution of e-mail standards.

The sendmail open source has a 20+ year legacy. It has been rewritten 4 times from scratch. It's large feature set is a function of the equally large and diverse user community it serves. Believe it or not, some people still use the DECNet and UUCP delivery settings.

Sendmail continues to evolve, argueably more rapidly and for the better than any other Open Source MTA.

I think an anonymous post with an unsupported claim of a bad design is designed to spread FUD. I call that a bad design.

Re:I still choose Sendmail as my MTA

[shadowpuppy]

Sorry Sendmail still sucks. This vast feature set set is why I use sendmail but it still sucks.

1. The sendmail configuration system is outdated. It cryptic from ground 0 and doesn't get any better. Perhaps this what important back in the day but now its just stupid.

2. The documentation is outdated. The defacto source for sendmail information is the O'Rielly Senmail boo, but Sendmail has made a few revs since then. There are important items missing from the book. Although I can and have hunted down the info I need online and in the source, it's a poor substitute.

3. I'm not really fond of the sendmail code in and of itself. It's written in a poor style. If the function is a few screen fulls and there are hidden variable declarations of single character variables used a few sreens down, it sucks. Personnally I believe if a function grows to a few screen fulls it's a sign it needs to be shot.

Re:I still choose Sendmail as my MTA

[please explain]

I would say that what sucks is not sendmail. What sucks is the many MTA/SMTP developers writing code that violates the RFC for SMTP and breaks things. Many firewalls do this (SMTPfixup was a good way to break mail routing) and so do other "appliances". This is why sendmail has had to stay as flexible as possible in order to keep email routing itself in a usable state.

To address your points:

1. The configuration system is M4. M4 is not sendmail. Sendmail uses M4. The configuration system is one of the reasons why sendmail has the vast feature set that keeps you using it. This can be improved, I agree, but I'm personally happy that support for LDAP and encryption were given priority because M4 works i.e M4 is not broken. If you administer sendmail for a company, you can get a comercially supported version that is QA tested and easy to configure. Easy to configure does not change the fact that email in general is hard. Those who try to simpify with "I installed this in two seconds and it runs" statements have probably never had to do this for a two merged corporations that acquired a 3rd company all with different internal messaging systems. Sendmail is the only glue for all of the domains, auth, provisioning, and routing mess that this type of business activity can create.

2. There is a brand spanking new Sendmail O'Rielly book that was just released. It does cover the important topics. This is not a fun read.

3. This is an open source project. Like any other open source project, you can dream of shooting it or contribute. Maybe your size of function preferences don't apply to sendmail. You'll only know if you ask the sendmail developer community. They have always given me an accurate answer when I've questioned why some things were done in a certain way. It's usually not their fault, but they will ack if there is something they need to do.

Re:Qmail and postfix hippies: shut the hell up ple

[Anonymous Coward]

Hear hear! Same with all you Linux/Apache operators. Yes, we know that NT4.0/IIS is hopelessly unpatchable and responsible for the wasting of untold gigabyte hours of bandwidth due to worm propogation and becoming willing DDOS zombies, but please shut the hell up about your superior software. Geez, it's only software on an Internet that we all have to share. Thank you.

Re:Qmail and postfix hippies: shut the hell up ple

[CoolVibe]

I _do_ use postfix, and yes I also _do_ use Qmail. I also use exim in some places. And yes, I use sendmail too. They are MTAs, and MTAs aren't complex beasts, well they can get complex, depending what you are planning to do with it. I'm not anymore attached to sendmail as you are. I'm just voicing the irritation over the brainless "Ooh, sendmail has a bug, let's plug [insert MTA of choice]" jammering out here.

About my "attachement to sendmail": It's all dependant what the machines job is. Read my post again. Every MTA shines somewhere. Qmail is nice if you have LOTS of users/mailboxes, postfix and exim are nice if you have a heavily loaded box that has to shift a lot of mail, and sendmail is just great for everything else. That's my right-tool-for-the-job attitude.

I guess you only read the subject line of my post, and then just concluded I must be some rabid sendmail user (a.k.a. Slashdot Knee-Jerk). Well, you're wrong :)

Why I don't like qmail

[mcrbids]

1) Qmail doesn't follow convention. Forget inetd, DJB uses his own, goofy "tcpserver". Never mind any other services you have on the machine, and pray to god they don't conflict. You *can* get qmail to work with xinet.d, but good luck getting all the (much needed) features working, since with xinet.d you get an open mail relay by default.

2) There are like 5 different programs, each with different user accounts (qmaild, qmaill, qmailp, qmialq, qmailr, qmails, vmail, etc) - all running from the same !@#!@ bin directory! Talk about confusing as !@#! hell when you want to audit permissions!

3) Qmail has a truly hideous license. Yeah, it's "open source", but you can't redistribute changes!!?!

This means:

4) If you want something decent (such as LDAP support,antivirus filtering or integration with SpamAssassin, etc.) you have to apply 57 god-knows patches to the "official" qmail source, and in just the right order to get everything working.

5) The log format is different than sendmail's. While this is understandable, it means that all these neat reporting tools for sendmail can't be used.

And finally,

6) Administering Sendmail on RH Linux is a breeze. up2date sendmail; /etc/rc.d/init.d/sendmail restart takes care of most of it.

-Ben

Re:Why I don't like qmail

[Silas]

1) Qmail doesn't follow convention. Forget inetd, DJB uses his own, goofy "tcpserver". Never mind any other services you have on the machine, and pray to god they don't conflict. You *can* get qmail to work with xinet.d, but good luck getting all the (much needed) features working, since with xinet.d you get an open mail relay by default.

You can use qmail with inetd if you want. But inetd is a potential security hazard; why would you complain about an alternative that improves that situation?

2) There are like 5 different programs, each with different user accounts (qmaild, qmaill, qmailp, qmialq, qmailr, qmails, vmail, etc) - all running from the same !@#!@ bin directory! Talk about confusing as !@#! hell when you want to audit permissions!

Have you ever used an operating system called "Linux"? Some people would say that it has some complexities to it, but most agree that those complexities are well worth the security, robustness, and highly configurable nature of the OS. If you want plug-and-play, you shouldn't be running a mail server.

3) Qmail has a truly hideous license. Yeah, it's "open source", but you can't redistribute changes!!?!

Yeah, when are they going to pass USA Patriot Act III that requires the license YOU like to be applied to every software package we all use?

4) If you want something decent (such as LDAP support,antivirus filtering or integration with SpamAssassin, etc.) you have to apply 57 god-knows patches to the "official" qmail source, and in just the right order to get everything working.

Agreed that the qmail source lacks a few key features that make it extendable in the way you might expect. Time to fix: 15 minutes to apply the right patches. A reason to not use qmail? Depends on what else you can do in 15 minutes.

5) The log format is different than sendmail's. While this is understandable, it means that all these neat reporting tools for sendmail can't be used.

Try saying this with a straight face to an IT decision maker: "We've chosen to avoid software package X because the log file output is different from other stuff we use."

6) Administering Sendmail on RH Linux is a breeze. up2date sendmail; /etc/rc.d/init.d/sendmail restart takes care of most of it.

See #2. I really am happy for you if you're happy with sendmail. But that's not an argument for others not to use qmail.

OSX 10.2.4 is vulnerable to this exploit

[Anonymous Coward]

It looks to me like OSX 10.2.4 is vulnerable to this exploit. The CERT advisory says all version previous to 8.12.9 and I'm pretty sure OSX uses 10.12.6. Can anyone confirm this? It is disabled by default, so it is not large issue. Anyone care to bet as to how long for a security patch?

HOLY SHIT

[I Am The Owl]

You remind me of the Nerd in a Shoe!

multignometerm

[Anonymous Coward]

THANK GOD! for MGT

Login to all servers "File -> All Bonded"
run commands and your done!

Re:Qmail and postfix hippies: shut the hell up ple

[Anonymous Coward]

The problem is that sendmail has to be patched for a new bug every 2-3 weeks. Qmail is still at 1.0.3 and hasn't been updated for years - no security-related bugs have been discovered.

With the current track record I think we can agree that sendmail has had tons of bugs. Since you are claiming that qmail has them to - please point us to ONE.

As for patching - do you guarantee that you will personally update every single mailserver you install, anywhere, forever, without any support agreement or compensation? If not you just proved my point.

Re:Qmail and postfix hippies: shut the hell up ple

[CoolVibe]

The problem is that sendmail has to be patched for a new bug every 2-3 weeks. Qmail is still at 1.0.3 and hasn't been updated for years - no security-related bugs have been discovered.

Not yet, anyway... But read on:

With the current track record I think we can agree that sendmail has had tons of bugs. Since you are claiming that qmail has them to - please point us to ONE.

Claiming *any* piece of software is bug free is naieve. Sure there are bugs. They might not be straightforward to find, but sure, they're there. You clearly don't develop much, you would've known this if you did.

What's worse is that there might be Qmail related exploits around that we are not aware of. Surely the blackhats will not disclose those bugs and we will probably never hear about it from them. If a MTA has a "flawless" security record, I'd be worried. Has anyone ever properly audited the Qmail code, besides DJB? It's kinda like claiming you've never been broken into. It might just be the case that you have had an intrusion, but you never noticed.

Also, you clearly exaggerate the rate of security related bugs in sendmail nowadays. Sure it has its bad spots, but then for years it's fine. Yes I patch and maintain the boxes I set up. I would be a crappy sysadmin if I didn't.

Too Cool for Secure Code

[bill_mcgonigle]

Interesting how we just had this article the other day.

I know some places process alot of mail with sendmail and need all the speed they can get, but the monster sites seem to have gone to qmail anyway. Considering the speed of my computer vs. the speed of my 'net pipe, I don't have much of a load on my mailserver, which leads me to ask:

Does anybody know of a good mailserver written in a higher-level language?

This is what, the 82nd remote root-exploit in sendmail due to C coding problems? Let's see something written in Perl or Python or Java, even.

Re:Too Cool for Secure Code

[hurtta]

Does anybody know of a good mailserver written in a higher-level language? This is what, the 82nd remote root-exploit in sendmail due to C coding problems? Let's see something written in Perl or Python or Java, even.

I do not think that there exists full Mail Transport Agents written with perl or python. However, some written with java exists, I think.

But check it yourself, of course.

The best sendmail fix out there...

[supabeast!]

Would be for them to stop releasing fixes. The same goes for BIND versions 9. These programs are endless thorns in the sides of the internet, and the developers of said programs would be doing us all a favor if they would just stop developing, pull the source off of the internet, and tell the world to use software that was coded to be secure.

Re:Qmail and postfix hippies: shut the hell up ple

[Russ Nelson]

qmail has no security holes. There's $500 sitting on the table for you if you can find a security hole.
-russ

Re:Qmail and postfix hippies: shut the hell up ple

[CoolVibe]

Like I said to some anonymous coward, you'd be pretty naive if you claim that a piece of software has no (possibly security related) bugs at all.

All software has bugs. Bug-free software and hardware do NOT EXIST

In fact, the fact that nobody claimed that award, does not mean that Qmail is bugfree. Do you really think that some blackhat will give away an advisory? He couldn't care less about $ 500, he can intrude into Qmail boxes that are deployed widely and thought to be secure. That's priceless.

Of course that's speculation, but still. I'd be laughing my ass off if it were true.

Re:Qmail and postfix hippies: shut the hell up ple

[CoolVibe]

Of course that's speculation, but still. I'd be laughing my ass off if it were true.

Clarification: I of course don't intend malice. I just never agreed with DJB's money for bugs scheme, because it will cause the adverse effect of what he's trying to achieve. I don't agree with his licensing either.

M4

[Osty]

M4 gets a bad reputation because of Sendmail. However, M4 is pretty cool, and quite useful. For example, I've used it in the past as a way to add includes and macros to SQL code (SQL code being built in a build environment, generally object defintions and stored procedures, run through the command line tool for whatever database you're using). That let me abstract out common pieces of code, minimizing copy&paste errors.

In general, M4 is just a macro processor, where there are some pre-defined macros, and you can define your own macros as well as changing various behaviors of M4. For example, to use my SQL example above, it was trivial to change M4's quoting characters to {} from `' (Because the `' quoting conflicted with SQL's '' quoting), and it was necessary to prefix M4 builtins with m4_ because SQL has some similarly-named functions (len(), for example). This was trivially done and stored in a "freeze" file for easy retrieval later. Write your M4 code to the changed definitions, and run M4 by specifying the freeze file. In essence, that's all Sendmail is doing -- Sendmail has defined some M4 macros, and you just use those macros to create your config. In Sendmail's case, the macros are poorly documented, and that makes configuration a real bear. But that's not M4's fault. It's Sendmail's.

Re:Qmail and postfix hippies: shut the hell up ple

[Electrum]

What's worse is that there might be Qmail related exploits around that we are not aware of. Surely the blackhats will not disclose those bugs and we will probably never hear about it from them. If a MTA has a "flawless" security record, I'd be worried. Has anyone ever properly audited the Qmail code, besides DJB? It's kinda like claiming you've never been broken into. It might just be the case that you have had an intrusion, but you never noticed.

qmail has no security holes. Hundreds, if not thousands, of people have read the source code. Many people hate DJB and would love to find a security hole in his software. No one has found any.

Instead of making wild claims about non existant security holes that no one knows about, why don't you read the source code yourself and find out why it is secure?

Uh huh

[poopdik]

Yeah.. when it's a Windows problem people jump on Microsoft's shit like it were pussy, and they weren't gay..

But when it's Sendmail.. for christs-fucking-sakes.. a software that has had an eternity in comparison to "get secure".. still has problems. And I love the respectful, informative tone to the Slashdot post. Fucking cunt hypocrits.

You're just the same

[Vainglorious Coward]

>...[accusations of qmail/postfix zealotry]...[scads of hand-waving and speculation about bugs in qmail]... I don't agree with his licensing either.

This last sentence shows how you are just as much a zealot as those you started this thread by castigating. But let's keep this focussed on sendmail. To take you back to your original claim (and I'm not disputing that different MTAs have different strengths), tell me : in what situations do you settle on sendmail as the solution? What strengths does it have and in what circumstances is it the best choice? (I have my own answer, but I'll save it just in case you can't come up with one)

Re:You're just the same

[CoolVibe]

I answered that in a reply to another post.

Comment removed

[account_deleted]

Comment removed based on user account deletion

changelog says

[hurtta]

Changelog says:

SECURITY: Fix a buffer overflow in address parsing due to
a char to int conversion problem which is potentially
remotely exploitable. Problem found by Michal Zalewski.
Note: an MTA that is not patched might be vulnerable to
data that it receives from untrusted sources, which
includes DNS.

Is that something to do with char == signed char versus char == unsigned char ?

Re:changelog says

[hurtta]

From: Michal Zalewski <lcamtuf@ghettot.org>
To: <bugtraq@securityfocus.com>

<...>
The impact is believed to be a root compromise. I've confirmed this is a
local issue, and my initial impression is that a remote attack possibility
is not that unlikely. Only platforms with 'char' type signed by default
are vulnerable as-is,
<...>

love or hate sendmail.....

[nighty5]

just patch it and move on...

sendmail was delivering mail long before the first source line of qmail was created, a little credit where credit is due.

I use qmail quite extensively, however what bugs me the most, is the significant amount of effort required in patching the souce to allow qmail to do anything fancy besides the basic functionality of delivering mail.

Re:love or hate sendmail.....

[TheLink]

Well I haven't needed to do much patching at all.

BUT most importantly, I haven't needed to patch AFTER installing and configuring. Same for the other DJB stuff. Patches would be to add _features_.

In contrast the ISC stuff is practically in the same category as MS stuff as far as I'm concerned.

Given how DJB is, I'm sure there are tons of people just longing to find an exploit just to stick it to him (I'm sure he knew that too).

And because it's been quite a number of years since my first install, without any patches necessary, I figure I made a good decision.

What does commercial sendmail cost?

[petej]

I did just try to buy sendmail from sendmail.com for a someone for whom I was doing some work, and we couldn't figure out how to do it from the website. There's no product or price list, certainly no "purchase online" section. You have to engage a salesperson, and the guy for whom I was working thought it was too much trouble to have to do phone-tag just to find out how much it would cost. He's still a sendmail user, but only the free version.

Morality

[chrysalis]

Don't queue mail with sendmail.
Send mail with Qmail.

No you didn't

[Vainglorious Coward]

I can't find anything other than this comment in which you say "sendmail is great for everything". You may call that an answer; seems like zealous idiocy to me.

Re:No you didn't

[CoolVibe]

Learn to read. I said "Sendmail is great for everything else", which means small setups that don't have lots of users and doesn't have to move mass amounts of mail about.

Whatever...

Re:No you didn't

[Anonymous Coward]

hrm?

I always found sendmail config's hard to parse in my head ( don't even try me on that m4 gibberish :p), and for small setups usually resorted to exim or qmail instead, as the time taken to configure it, was much less...

These day's I standardise on exim, because *I* think its replaced (for me anyway) sendmail as the jack of all trades... :)

Re:No you didn't

[Anonymous Coward]

Reading abilities don't have to be very sophisticated to realise that you're still talking bullshit. You haven't answered the question because you are unable to. You are the zealot you accuse others of being. Psychologists call this "transferrence" - seeing your own faults in others.

Hippy

Irresponsible Disclosure? Hardly!

[Anonymous Coward]

Look, here's the thing. Read the disclosure on Full-Disclosure and you'll see that it was obviously an integer overflow, but also that it was obviously easy to fix. One line. One typecast. Not rocket science.

The actual discussion was started by the availability of the patch.

Does it really take six days to change a typecast that leads to a root compromise? Does if you're sendmail!

Bravo, to those of you who believe in full disclosure, and boo, to those who call you irresponsible. The irresponsible parties here are Sendmail. Why the hell were they delaying for days when they already had World's Simplest Patch?

They make it sound like someone posted an exploit, which is demonstrably not true. The early disclosure was the disclosure of the patch.

Problem with patch for 8.12.8

[Bastiaan]

I tried to patch 8.12.8 with the supplied patch set. But it failed because the file offsets were way of (e.g. in sendmail/conf.c hunk 1 is at 466 instead of 300 something).
Anyone else having the same problems?

Re: 36 bits

[some guy I know]

[...]next time I'm working on a PDP/11 [...] (36 bit word size).

The PDP-11 has a 16-bit word size.
I think that you are thinking of the PDP-10.

Re:Qmail and postfix hippies: shut the hell up ple

[Russ Nelson]

All software has bugs. Bug-free software and hardware do NOT EXIST

Interesting. So ... find a security hole in qmail. Not only will you be $500 richer, but you'll cease to be considered an idiot by your betters.
-russ

Last Post!

[alpg]

*** A NEW KIND OF PROGRAMMING ***

Do you want the instant respect that comes from being able to use technical
terms that nobody understands? Do you want to strike fear and loathing into
the hearts of DP managers everywhere? If so, then let the Famous Programmers'
School lead you on... into the world of professional computer programming.
They say a good programmer can write 20 lines of effective program per day.
With our unique training course, we'll show you how to write 20 lines of code
and lots more besides. Our training course covers every programming language
in existence, and some that aren't. You'll learn why the on/off switch for a
computer is so important, what the words *fatal error* mean, and who and what
you should blame when you make a mistake.

Yes, I want the brochure describing this incredible offer.
I enclose $1000 is small unmarked bills to cover the cost of
postage and handling. (No live poultry, please.)

*** Our Slogan: Top down programming for the masses. ***

- this post brought to you by the Automated Last Post Generator...