Subject: Returned Mail: User Unknown 71 Date: Thu, 11 Apr 91 13:00:22 EDT From: Steve Strassmann straz@media-lab.mit.edu To: UNIX-HATERS Subject: pain, death, and disfigurement ############################################################### # # READ THESE NOTES BEFORE MAKING CHANGES TO THIS FILE: thanks! # # Since aliases are run over the yellow pages, you must issue the # following command after modifying the file: # # /usr/local/newaliases # (Alternately, type m-x compile in Emacs after editing this file.) # # [Note this command won't -necessarily- tell one whether the # mailinglists file is syntactically legal -- it might just silently # trash the mail system on all of the suns. # WELCOME TO THE WORLD OF THE FUTURE.] # # Special note: Make sure all final mailing addresses have a host # name appended to them. If they don't, sendmail will attach the # Yellow Pages domain name on as the implied host name, which is # incorrect. Thus, if you receive your mail on wheaties, and your # username is johnq, use "johnq@wh" as your address. It # will cause major lossage to just use "johnq". One other point to # keep in mind is that any hosts outside of the "ai.mit.edu" # domain must have fully qualified host names. Thus, "xx" is not a # legal host name. Instead, you must use "xx.lcs.mit.edu". # WELCOME TO THE WORLD OF THE FUTURE # # # Special note about large lists: # It seems from empirical observation that any list defined IN THIS # FILE with more than fifty (50) recipients will cause newaliases to # say "entry too large" when it's run. It doesn't tell you -which- # list is too big, unfortunately, but if you've only been editing # one, you have some clue. Adding the fifty-first recipient to the # list will cause this error. The workaround is to use:include # files as described elsewhere, which seem to have much larger or # infinite numbers of recipients allowed. [The actual problem is # that this file is stored in dbm(3) format for use by sendmail. # This format limits the length of each alias to the internal block # size (1K).] # WELCOME TO THE WORLD OF THE FUTURE # # Special note about comments: # Unlike OZ's MMAILR, you -CANNOT- stick a comment at the end of a # line by simply prefacing it with a "#". The mailer (or newaliases) # will think that you mean an address which just so happens to have # a "#" in it, rather than interpreting it as a comment. This means, # essentially, that you cannot stick comments on the same line as # any code. This also probably means that you cannot stick a comment # in the middle of a list definition (even on a line by itself) and # expect the rest of the list to be properly processed. # WELCOME TO THE WORLD OF THE FUTURE # ################################################################### FIGURE 1. Excerpts From A sendmail alias file

72 Mail Sometimes, like a rare fungus, Unix must be appreciated at just the right moment. For example, you can send mail to a mailing list. But not if someone else just happens to be running newaliases at the moment. You see, newaliases processes /usr/lib/aliases like so much horse meat bone, skin, and all. It will merrily ignore typos, choke on peril- ous whitespace, and do whatever it wants with comments except treat them as comments, and report practically no errors or warnings. How could it? That would require it to actually comprehend what it reads. I guess it would be too hard for the mailer to actually wait for this sausage to be completed before using it, but evidently Unix cannot afford to keep the old, usable version around while the new one is being created. You see, that would require, uh, actually, it would be trivial. Never mind, Unix just isn’t up to the task. As the alias list is pronounced dead on arrival, what should sendmail do? Obviously, treat it as gospel. If you send mail to an alias like ZIPPER-LOVERS which is at the end of the file, while it’s still gur- gitating on ACME-CATALOG-REQUEST, sendmail will happily tell you your addressee is unknown. And then, when it’s done, the new mail database has some new bugs, and the old version—the last known version that actually worked—is simply lost forever. And the person who made the changes is not warned of any bugs. And the person who sent mail to a valid address gets it bounced back. But only sometimes. STEP 4: Put the mail into the correct mailbox. Don’t you wish? Practically everybody who has been unfortunate enough to have their mes- sages piped through sendmail had a special message sent to the wrong reciepient. Usually these messages are very personal, and somehow uncan- ningly sent to the precise person for whom receipt will cause the maximum possible damage. On other occasions, sendmail simply gets confused and can’t figure out where to deliver mail. Other times, sendmail just silently throws the mail away. Few people can complain about this particular sendmail mannerism, because few people know that the mail has been lost. Because Unix lies in so many ways, and because sendmail is so fragile, it is virtually impossible to debug this system when it silently deletes mail: