Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: "Forward to " in .forward mishandled. Keywords: forward Message-ID: <1991May9.021611.26191@mp.cs.niu.edu> Date: 9 May 91 02:16:11 GMT References: <22524@shlump.lkg.dec.com> <22537@shlump.lkg.dec.com> Followup-To: alt.flames Organization: Northern Illinois University Lines: 159 In article <22537@shlump.lkg.dec.com> jc@sppip7.lkg.dec.com writes: >Hey, I get to be the first one on my block to followup this, my own >article! Among the various flames that I received, one actually had >a simple solution to the problem. > >Anyhow, one respondant (Neil Rickert ) suggested that >the right place was in ruleset 3, and that I should add: > RForward to $+ $:$1 Let me make it perfectly clear. I DID NOT suggest this as a solution. I suggested it as a rule which would have this effect if somebody was really silly enough to use it. My proposed solution was RTFM. It never really occurred to me that you might actually be stupid enough to treat that as a solution. >I actually added this and also > Rforward to $+ $:$1 Since sendmail does case insensitive matching this was superfluous, and even more silly. >One of the better flames came from rickert@cs.niu.edu along with his >answer: > >> Having the words "Forward to" inside .forward would seem stupidly redundant. > >This is similar to a lot of the other responses. I'd like to make the >observation that if you think that adding explanatory English comments >to a file is "stupid", then I don't want you working on any software If you really like adding explanatory words, try adding the words 'Login as: ' just before each entry in /etc/passwd. That should make the passwd file easier to understand. >that I send out to customers. Lots of people have similar feelings, and >there are frequent characterizations of Unix programmers as the type that >are either unwilling or unable to communicate in a human-readable tongue. > >Having words like "Forward to" in a .forward file certainly is redundant. >But it isn't stupid. In a perfect universe, communication systems wouldn't Actually, it isn't so much redundant as it is stupid. If you cannot tell the difference between a configuration file containing formatted data in the form expected by software, and a file intended to give explanatory information to human readers, you are in this business way out of your depth. Maybe you should take that early retirement option before your employer finds out. >need redundancy to function properly. This is not a perfect universe, at These extra words "Forward to" ARE NOT redundancy to make the system function properly. Properly put, they are somebody throwing a monkey wrench into the works. Think of that rewrite rule as a protective buffer against this particular monkey wrench. But if you keep going you will have more monkey wrenches than you can possibly buffer against. >least not in the corner where I reside, and redundancy is an important part >of successful packages hereabouts. For instance, it's real useful, when >looking at a bunch of files in /usr/lost+found, to be able to edit them >and get a hint as to what they were and what needs to be fixed to recover >from the damage. Maybe you aren't concerned with making your systems robust You would be better off looking at the system logs to find out why anything finished up in lost+found in the first place. The redundancy in this case should come from a good system backup procedure. >There's also a major problem with TFM that several people suggested I R. >Firstly, "man -k forward" says "forward not found". Nextly, the mail(1) >and aliases(5) entries mention .forward, but give no hint whatsoever as >to the format of a list. On some nearby Sys/V machines, there is a manual The aliases(5) pages had just finished describing the format of the list in connection with entries in the aliases files. The author's presumably didn't think they would have to deal with someone so incompetent that he couldn't remember for a few lines. >page for .forward, and it shows the "Forward to " syntax as optional, as >well as describing its use in /usr/spool/mail/foo. So RTFM would lead us I suppose you expect the Toyota manual to set the standard for Volkswagens too. >to believe that this is "normal" (whatever that means) syntax for .forward, >on the grounds that it is documented in the only manual pages that say >anything at all about the .forward format. It's documented everywhere >for the /usr/spool/mail/* files, of course, which only leads users to >believe that this is the "normal" syntax for forwarding on Unix systems. Just as well you didn't pick up a PC manual first, or you might have been trying in vain to look at \usr\spool\mail\* . >One real stumbling block for people here was: They were already familiar The real stumbling block is somebody who is not qualified to sweep the floors playing make believe and pretending to be a systems administrator. >Now I can understand how this might come about. After all, .mailrc is a >config file for one package (the Rand mailer); .forward is a config file Brilliant. Actually .mailrc has nothing to do with the Rand mailer. It is the user startup file for the Berkeley mailer (/usr/ucb/Mail). >for another (the Bell Labs mailer), so why should they be similar? And >in the case of sendmail (whose manual page mentions neither .forward nor >.mailrc), why should it even read these files, and if it does, why should While you are playing make believe, and pretending to be a system administrator, why don't you read the system administration manual for sendmail. You just might find something about .forward there. I hope it doesn't say anything about .mailrc, though, since that file has nothing whatsoever to do with sendmail. >The answer to these semi-rhetorical questions are quite straightforward >from most users' viewpoints. They are trying to get mail delivered, and >they don't need all the confusion that email seems determined to heap on >them. Invariably, they ask why the @#$*&^ software developers don't get Maybe they should buy a postage stamp, and use the US mail. With all the criticism of the mismanagement of the Postal service, it is probably much better run than your machines. >their acts together. Few of them, in my experience, have much patience >with all this email nonsense, especially when the email "experts" make >is to abundantly clear that they have little but contempt for the stupid >users. This arrogant attitude comes out quite clearly from the Internet Most email administrators I deal with have great concern about the problems of average users. It is the stupid administrators they hold in contempt. >There's no way I can justify this to any customers. But I can at least >thank Mr. Rickert for being the first one to show a solution. Now if I >could easily propogate it to everyone's sendmail.cf files... I sincerely hope that nobody else who reads this group is so stupid as to think of that rule as a solution to anything. >(Actually, I've had some fun explaining that these mailers probably use >different formats because of the look-and-feel lawsuits which will soon >make it illegal for any two programs to accept the same input formats >or generate similar output... ;-) I guess your knowledge of the law is as infinitesimal as your knowledge of Unix administration. -------------- In the meantime, I too have had some fun producing this flame. Serve you right for trying (unwittingly no doubt) to publicly embarrass me. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940