lan_csse@netrix.nac.dec.com (05/08/91)
Well, I don't know if this is a bug or a feature, but it did just waste
an hour or so of several people's time, and it'd be nice to know if there
is a feasible solution or if we just mark it up as Yet Another Bizarreness.
The systems involved are assorted DEC Ultrixes, releases 3.1 thru 4.1, on
VAX and MIPS hardware. The sendmail.cf files are pretty close to what is
on DEC's distribution tapes.
A fellow here decided that a particular pseudo-user on all our machines
("nm", our Network Manager) should support a mailing list. One of the
time-honored ways of doing this is via the $HOME/.forward file, so he
created such a file for nm:
echo Forward to u1.m1.lkg.dec.com, u2.m2.nac.dec.com >.forward
and so on. He did a test message, and it failed. His machine uses the
sendmail daemon, and when we did a bunch of tests, after getting past all
the confusion of deciphering the "Mail -v" output, we eventually realized
that the problem was that sendmail was telling m1 to send the mail to:
RCPT To:<Forward to u1.m1.lkg.dec.com>
and m1 had no user "Forward to u1", so it failed. We deleted the "Forward
to" from the .forward file, and it worked fine.
Now, despite the fact that we know a workaround, we are somewhat miffed
by the fact that every other mailer we can find handles the "Forward to"
in the obvious ways. If we use the uucp/att mailers, the originating mailer
strips it off. If sendmail talks to a DECnet mailer, the recipient mailer
strips it off. But if it is sendmail at both ends, it fails because neither
has the sense to discard the "Forward to". Despite the claim that sendmail
is so horribly complicated because it is such a super intelligent mailer,
it seems to be the only one lying about that fails to treat these two words
as comments.
Or is it? Sendmail is of course configurable like you wouldn't believe,
so it seems likely that there's something that can be done in sendmail.cf
that would tell it to discard these English comments like other mailers
do. Maybe we could even get it to discard equivalent phrases in other
languages. But damned if I can find anything in TFM that hints at how
one might go about making the change.
Is there a way to get sendmail to behave in the obvious manner here? Is
it possible for a mere human to understand how to do it? Or are we stuck
with just documenting that "Forward to" should not be used if sendmail is
involved? Am I wasting my time even asking?
Please answer by email if possible and I'll try to summarize (if I can make
sense of the answers). This news access is somewhat tenuous, and I'm not
sure I'll see posted answers.
BTW, don't bother telling me about /usr/lib/aliases; I am quite familiar
with it. The argument that "Method X doesn't need to work because method
Y is available" does not impress me at all. If sendmail reads the .forward
file at all, it should process it correctly, and "correctly" in this case
means being compatible with the other mailers that use it. If this is
indeed configurable, then the default setup should be compatible with the
other mailers.karl.kleinpaste@osc.edu (05/09/91)
lan_csse@netrix.nac.dec.com writes: One of the time-honored ways of doing this is via the $HOME/.forward file, so he created such a file for nm: echo Forward to u1.m1.lkg.dec.com, u2.m2.nac.dec.com >.forward ...we eventually realized that the problem was that sendmail was telling m1 to send the mail to: RCPT To:<Forward to u1.m1.lkg.dec.com> and m1 had no user "Forward to u1", so it failed. If you RTFM aliases(5) and get to about page 3 (or so it is on this SunOS 4.1.1 machine; similarly placed for any sendmail installation), you will find this paragraph: | Automatic Forwarding | When an alias (or address) is resolved to the name of a user | on the local host, sendmail checks for a .forward file, | owned by the intended recipient, in that user's home direc- | tory, and with universal read access. This file can contain | one or more addresses or aliases as described above, each of | which is sent a copy of the user's mail. On a nearby DEC 5500 (I think) running a recent Ultrix incantation, the man page is actually much more abbreviated but still reads: | After aliasing has been done, local and valid recipients who have | a ``.forward'' file in their home directory have messages for- | warded to the list of users defined in that file. Nowhere will you find any reference to the use of the phrase "Forward to." In fact, I was unaware that _any_ UNIXish mailer _except_ the patently braindead and simplistic /bin/mail on SysV boxes understood the phrase "Forward to," and even there, it must be in the mail file /usr/mail/userid, and not in ~userid/.forward. (That is, unless this is something new for SysVRel4, which I have yet to see firsthand.) .forward is and always has been documented as containing a set of usernames only, never once it having been suggested that it contain some pointless commentary about forwarding, given the purpose for which the file exists anyhow. As for "compatibility with other mailers," it's not an issue of compatibility as far as I can see, since one can already describe not less than 3 ways of handling the matter -- there is no standard to which to adhere. 1. "Forward to someplace" in /usr/mail/userid. 2. ~userid/.forward containing "someplace." 3. Potentially, based on your comment, ~userid/.forward containing "Forward to someplace." Hardly any standard present, and hardly worth adherence. --karl
rickert@mp.cs.niu.edu (Neil Rickert) (05/09/91)
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 <rickert@cs.niu.edu>) 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 <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
igb@fulcrum.bt.co.uk (Ian G Batten) (05/09/91)
In article <22524@shlump.lkg.dec.com> jc@sppip7.lkg.dec.com writes: > time-honored ways of doing this is via the $HOME/.forward file, so he > created such a file for nm: > echo Forward to u1.m1.lkg.dec.com, u2.m2.nac.dec.com >.forward I have never heard of anyone doing this before. There is the ``Forward to'' convention used in /usr/mail for System 5 machines, but .forward files have always contained addresses alone. ian
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (05/10/91)
In <22537@shlump.lkg.dec.com> lan_csse@netrix.nac.dec.com (CSSE LAN
Test Account) writes:
After all, .mailrc is a config file for one package (the Rand
mailer); .forward is a config file for another (the Bell Labs
mailer), so why should they be similar?
After all, the moon is made of one material (Green cheese), and the sun
is made of another (Banana juice), so why should they be similar?
--
Rahul Dhesi <dhesi@cirrus.COM>
UUCP: oliveb!cirrusl!dhesi