msir@sulu.cc.rochester.edu (Mark Sirota) (08/21/90)
Sometimes, and I do mean sometimes, our sendmail seems to be ignoring
.forward files, and delivering locally instead.
This is happening under SunOS 4.0.3, using Sun's sendmail 4.1 (that's the
version number that the $v macro gives, anyway). I've only seen it happen
on one system, but that doesn't mean it's not happening elsewhere. The home
directories on this system are remote-mounted by NFS.
The .forward files seem to work most of the time; it's just the occasional
letter than gets delivered locally. They don't seem to happen in batches;
time doesn't seem to have anything to do with it, and I just basically have
absolutely no idea what could be going on.
Any suggestions are most welcome.
--
Mark Sirota - University of Rochester Computing Center, Rochester NY
Internet: msir@cc.rochester.edu
Bitnet: msir@uordbv.bitnet
UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msirmsir@sulu.cc.rochester.edu (Mark Sirota) (08/22/90)
In article <9012@ur-cc.UUCP> I write: > Sometimes, and I do mean sometimes, our sendmail seems to be ignoring > .forward files, and delivering locally instead. > > This is happening under SunOS 4.0.3, using Sun's sendmail 4.1 (that's the > version number that the $v macro gives, anyway). I've only seen it happen > on one system, but that doesn't mean it's not happening elsewhere. The > home directories on this system are remote-mounted by NFS. > > The .forward files seem to work most of the time; it's just the occasional > letter than gets delivered locally. They don't seem to happen in batches; > time doesn't seem to have anything to do with it, and I just basically have > absolutely no idea what could be going on. Maybe I should clarify this. The problem is *not* file permissions, as many people have suggested to me by mail. The .forward files in question are readable by everyone. It's more like the .forward file seems to be intermittently disappearing. Two people suggested that the NFS mount might be having problems at those times; this sounds reasonable but I don't have any proof. /var/adm/messages does not contain any NFS, RPC, or sendmail errors anywhere near the time of the misdelivered messages. -- Mark Sirota - University of Rochester Computing Center, Rochester NY Internet: msir@cc.rochester.edu Bitnet: msir@uordbv.bitnet UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir
haynes@ucscc.UCSC.EDU (99700000) (08/22/90)
Just to report that I've had the same problems on a MtXinu More/BSD
system.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chroniclemsir@sulu.cc.rochester.edu (Mark Sirota) (08/22/90)
In article <9012@ur-cc.UUCP> I write: > Sometimes, and I do mean sometimes, our sendmail seems to be ignoring > .forward files, and delivering locally instead. I really appreciate all the mail I'm getting regarding this problem. It's unfortunate that almost everyone is answering a question that I didn't ask. Let me try to rephrase it. > This is happening under SunOS 4.0.3, using Sun's sendmail 4.1 (that's the > version number that the $v macro gives, anyway). I've only seen it happen > on one system, but that doesn't mean it's not happening elsewhere. The > home directories on this system are remote-mounted by NFS. The problem is *not* that the home directories aren't available. They are *ALWAYS* mounted. In fact, they are mounted before the sendmail daemon starts up, so it has nothing to do with delivery at boot time before the directories exist. The problem is also *not* file permissions - the .forward files in question exist and are readable by everyone, including root, so it has nothing to do with root privileges on an NFS-mounted filesystem. As I said before, It's more like the .forward file seems to be intermittently disappearing. Two people suggested that the NFS mount might be having problems at those times; this sounds reasonable but I don't have any proof. /var/adm/messages does not contain any NFS, RPC, sendmail, or reboot messages anywhere near the time of the misdelivered messages. Once again, I appreciate everyone's comments here. But it's not as simple as you all seem to be hoping... -- Mark Sirota - University of Rochester Computing Center, Rochester NY Internet: msir@cc.rochester.edu Bitnet: msir@uordbv.bitnet UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (08/23/90)
In article <9012@ur-cc.UUCP> Mark Sirota <msir@cc.rochester.edu> writes: >Sometimes, and I do mean sometimes, our sendmail seems to be ignoring >.forward files, and delivering locally instead. > >This is happening under SunOS 4.0.3, using Sun's sendmail 4.1 (that's the >version number that the $v macro gives, anyway). I've only seen it happen >on one system, but that doesn't mean it's not happening elsewhere. The home >directories on this system are remote-mounted by NFS. In order for sendmail to recognize a .forward file, the file has to be owned and readable by the recipient. My guess is that the remote mount mangles the file ownership, although I can't explain why that would happen intermittently (is someone messing with passwd files or are you using yp?). Also make sure that the user's home directory as listed in the /etc/passwd that the sendmail daemon is looking at is correct. ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmaus!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night
wls@uwm.edu (Bill Stapleton) (08/24/90)
In article <9023@ur-cc.UUCP>, msir@sulu.cc.rochester.edu (Mark Sirota) writes: > In article <9012@ur-cc.UUCP> I write: > > Sometimes, and I do mean sometimes, our sendmail seems to be ignoring > > .forward files, and delivering locally instead. > > I really appreciate all the mail I'm getting regarding this problem. It's > unfortunate that almost everyone is answering a question that I didn't ask. > Let me try to rephrase it. I'm no sendmail guru, but since nobody's hit it yet, here's a blast from our past that might apply: We had a problem with sendmail behaving differently depending on whether the mail was sent immediately or queued (at busy times) and sent later. In particular, it would pick up a program spec from a users' .forward (like "|vacation") and if it wasn't queuing, it would execute the program as the user who owned the .forward, ie the "to" user (right). But if the mail was queued for later, it ended up executing the program as the user sending the original message, ie the "from" user (wrong). This was fixed here, but I'm not sure if the problem/fix was reported elsewhere. There's also a related problem that we haven't fixed: If two users in a list have the exact same thing in their .forward file (say "|vacation"), one of them gets dropped as being a duplicate (wrong). We're still running 5.61 here; Has this problem been fixed in a later version? Anyways, I hope this is of some help to somebody... -- Bill Stapleton wls@csd4.csd.uwm.edu uwmcsd4!wls
gpz@ESD.3Com.COM (G. Paul Ziemba) (08/24/90)
In article <9023@ur-cc.UUCP>, msir@sulu.cc.rochester.edu (Mark Sirota) writes: > In article <9012@ur-cc.UUCP> I write: > > Sometimes, and I do mean sometimes, our sendmail seems to be ignoring > > .forward files, and delivering locally instead. > > I really appreciate all the mail I'm getting regarding this problem. It's > unfortunate that almost everyone is answering a question that I didn't ask. > Let me try to rephrase it. I haven't seen this suggestion so far, so here goes... (if it's been suggested before, well, I'm wearing my asbestos suit :-) Have you checked the /etc/fstab entry(ies) to make sure that the .forward files are mounted hard? If they are mounted soft, it is possible for nfs to time out under heavy network traffic conditions and give up, resulting in a temporarily inaccessible file. ~!paul -- Paul Ziemba api!gpz gpz@ESD.3com.com 408.970.2077 OS/2: just say no. "How much char could a char star star if char star could star char?" (quote stolen from mspercy@clemson.clemson.edu)
andy@jhunix.HCF.JHU.EDU (Andy S Poling) (08/24/90)
In article <1990Aug23.135914@uwm.edu> wls@uwm.edu (Bill Stapleton) writes: >In article <9023@ur-cc.UUCP>, msir@sulu.cc.rochester.edu (Mark Sirota) writes: >> In article <9012@ur-cc.UUCP> I write: >> > Sometimes, and I do mean sometimes, our sendmail seems to be ignoring >> > .forward files, and delivering locally instead. >> >> I really appreciate all the mail I'm getting regarding this problem. It's >> unfortunate that almost everyone is answering a question that I didn't ask. >> Let me try to rephrase it. > >I'm no sendmail guru, but since nobody's hit it yet, here's a blast from our >past that might apply: > >We had a problem with sendmail behaving differently depending on whether the >mail was sent immediately or queued (at busy times) and sent later. In >particular, it would pick up a program spec from a users' .forward (like >"|vacation") and if it wasn't queuing, it would execute the program as the >user who owned the .forward, ie the "to" user (right). But if the mail was >queued for later, it ended up executing the program as the user sending the >original message, ie the "from" user (wrong). This was fixed here, but I'm >not sure if the problem/fix was reported elsewhere. Ah, the old forwarding to a program with the wrong userid trick. The problem is even worse if the FROM address is not local - then sendmail seems to use the userid & groupid of the person to whom the *previous* message in the queue run was sent. Talk about an apparently random uid... Below is my simple patch for alias.c in 5.61 (I think this section of code is identical in 5.64). What the patch does is this: if this mail will be forwarded, don't read the .forward file yet - queue the mail instead. This way the original TO person's userid & groupid can be determined when forwarding the mail during a later queue run. This is pretty much a quick hack, and it will cause mail that will be forwarded to sit in the queue until your next queue run. We run the queue often enough that it's not a problem here. I consider it a reasonable trade-off. Someone should probably come up with a more sophisticated fix though... -Andy Andy Poling Internet: andy@gollum.hcf.jhu.edu Network Services Group Bitnet: ANDY@JHUNIX Homewood Academic Computing Voice: (301)338-8096 Johns Hopkins University UUCP: uunet!mimsy!aplcen!jhunix!andy *** alias.c~ Fri Aug 24 10:39:37 1990 --- alias.c Fri Aug 24 10:39:38 1990 *************** *** 578,590 if (user->q_home == NULL) syserr("forward: no home"); # endif /* DEBUG */ /* good address -- look for .forward file in home */ define('z', user->q_home, CurEnv); expand("\001z/.forward", buf, &buf[sizeof buf - 1], CurEnv); if (!safefile(buf, user->q_uid, S_IREAD)) return; /* we do have an address to forward to -- do it */ include(buf, "forwarding", user, sendq); } --- 578,608 ----- if (user->q_home == NULL) syserr("forward: no home"); # endif /* DEBUG */ /* good address -- look for .forward file in home */ define('z', user->q_home, CurEnv); expand("\001z/.forward", buf, &buf[sizeof buf - 1], CurEnv); if (!safefile(buf, user->q_uid, S_IREAD)) return; + #ifdef SAFE_FORWARD + /* + * if we will be forwarding, force queueing before we read the + * .forward file. This allows the original To address to live + * through queueing so that we can determine the recipient's uid + * when running the queue at later time. -- ASP + */ + if (!QueueRun) + if (bitset(QQUEUEUP, user->q_flags)) /* already set to queue it */ + return; + else + { + user->q_flags |= QQUEUEUP; /* queue it, don't send now */ + logdelivery("queued"); + return; + } + #endif /* SAFE_FORWARD */ + /* we do have an address to forward to -- do it */ include(buf, "forwarding", user, sendq); }
fll@dde.dk (Flemming Lau) (08/29/90)
wls@uwm.edu (Bill Stapleton) writes: >There's also a related problem that we haven't fixed: If two users in a list >have the exact same thing in their .forward file (say "|vacation"), one of them >gets dropped as being a duplicate (wrong). We're still running 5.61 here; Has >this problem been fixed in a later version? One might argue that the problem you mention is just a "bug" in the sendmail documentation. I also have had the problem but I found that changing the "|vacation" to |"vacation" solved the problem. (In parts of the parsing of the contents of the .forward file "|vacation" is interpreted as an address and therefore duplicates are suppressed. If you white |"vacation" the | is interpreted correctly all the way.) -- Obviously people living under such a system are not happy. They just think they are. ---------------------------------------------------------------------- Flemming Lau Tel: int +45 42 84 50 11 (UTC + 1)
wls@uwm.edu (Bill Stapleton) (08/30/90)
I write: >There's also a related problem that we haven't fixed: If two users in a list >have the exact same thing in their .forward file (say "|vacation"), one of them >gets dropped as being a duplicate (wrong). We're still running 5.61 here; Has >this problem been fixed in a later version? In article <1990Aug29.073958.200@dde.dk>, fll@dde.dk (Flemming Lau) writes: > One might argue that the problem you mention is just a "bug" in the > sendmail documentation. I also have had the problem but I found > that changing the "|vacation" to |"vacation" solved the problem. (In > parts of the parsing of the contents of the .forward file "|vacation" > is interpreted as an address and therefore duplicates are suppressed. > If you white |"vacation" the | is interpreted correctly all the way.) I set up a new test on one of our machines running 5.64, and it doesn't seem to matter which form you use - If there's two that are the same, one of them is suppressed. I tried: "|vacation" "| vacation" |"vacation" | "vacation" |vacation | vacation They all work, but they're all subject to duplicate supression. Any other suggestions? By the way, did the person who started this thread (with a different problem) find their glitch? -- Bill Stapleton wls@csd4.csd.uwm.edu uwmcsd4!wls
rickert@mp.cs.niu.edu (Neil Rickert) (08/30/90)
In article <1990Aug29.170409@uwm.edu> wls@uwm.edu (Bill Stapleton) writes: >I set up a new test on one of our machines running 5.64, and it doesn't >seem >to matter which form you use - If there's two that are the same, one of >them >is suppressed. I tried: > > "|vacation" "| vacation" > |"vacation" | "vacation" > |vacation | vacation > >They all work, but they're all subject to duplicate supression. Any >other >suggestions? If the command can take arguments, use: "|vacation user" where 'user' is you. If the command cannot take arguments, first make a symbolic link: ln -s /usr/ucb/vacation /home/user then in .forward, use |/home/user By the way, my 'man' pages say you should use an argment for vacation. It is an unwise practice to ever use "|vacation" in the .forward file. Always use full paths. Otherwise you are depending on the path that happened to be in effect with sendmail was started. When the daemon is started in /etc/rc sometimes only a very minimal path is in effect. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
allyn@sdd.hp.com (Allyn Fratkin) (08/30/90)
In article <1990Aug29.170409@uwm.edu>, wls@uwm.edu (Bill Stapleton) writes: > They all work, but they're all subject to duplicate supression. Any > other > suggestions? how about reading the manual? it specifically says that you need to place in your .forward file: \mylogin, "|vacation mylogin" i'm not sure if vacation actually uses the login name argument, but having it there keeps the recipients from being suppressed because everybody's login name is different. just a system administrator... -- From the virtual mind of Allyn Fratkin allyn@sdd.hp.com San Diego Division - or - Hewlett-Packard Company uunet!ucsd!hp-sdd!allyn
msir@sulu.cc.rochester.edu (Mark Sirota) (08/30/90)
In article <1990Aug29.170409@uwm.edu> wls@uwm.edu (Bill Stapleton) writes: > By the way, did the person who started this thread (with a different > problem) find their glitch? Thank you for asking... No, it hasn't been found, but it hasn't recurred since those first several times all during the same week. Since it seems to be fairly inexplicable, and ignoring it and hoping it would go away seemed to work, I'm going to continue to ignore it and hope it never returns. By the way, even more bizarre, another mailbox problem reported by a knowledgeable user that week was that a new letter found its way into the *middle* of his mailbox. I'm attributing that one to simple user confusion. -- Mark Sirota - University of Rochester Computing Center, Rochester NY Internet: msir@cc.rochester.edu Bitnet: msir@uordbv.bitnet UUCP: {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir