tperala@umn-d-ub.D.UMN.EDU (Tim Perala) (03/07/90)
We are running V2.1 of elm, and have seen a strange thing happening. Here is what we are seeing.... A user will compose and mail message1 to recipient1. The user immediately composes message2, and sends this off to recipient2. (recipient1 != recipient2). The recipient1 gets the message2, complete with a "To" field equal to recipient2. Recipient1 never recieves the intended message, neither does the recipient2. Now, it seems to be that this only happens when recipient1 is a long alias (to be expanded by sendmail) and/or when the system is very loaded. I have looked at how elm2.1 fires up sendmail... ( (/usr/lib/sendmail -oi -oem recipient1 ; /bin/rm -f /tmp/snd.6424) & ) < /tmp/snd.6424 This is quite quickly followed by... ( (/usr/lib/sendmail -oi -oem recipient2 ; /bin/rm -f /tmp/snd.6424) & ) < /tmp/snd.6424 My suspicion is that the "mail buffer" file (/tmp/snd.6424) is overwritten by the user before sendmail has had a chance to get to it. If recipient1 is a long alias, it will take sendmail quite a long time to parse the command line prior to reading its stdin. Does this sound plausible? If so, is it a known bug? Has it been fixed in 2.2 or will it be fixed in 2.3? Why not have elm fork, set up the "mail buffer" as stdin to the child, exec sendmail and immediately remove the "mail buffer" so subsequent access to that file name will be a new file? I don't read this newsgroup, so I apologize if this problem has been previously discussed. Thanks for your help. Tim Perala (tperala@ub.d.umn.edu) Systems Programmer Information Services University of Minnesota, Duluth (218) 726-6122
tperala@umn-d-ub.D.UMN.EDU (Tim Perala) (03/08/90)
In article <3252@umn-d-ub.D.UMN.EDU>, tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes: [description of wrong messages being delivered deleted] > I have looked at how elm2.1 fires up sendmail... > > ( (/usr/lib/sendmail -oi -oem recipient1 ; /bin/rm -f /tmp/snd.6424) & ) < > /tmp/snd.6424 > > This is quite quickly followed by... > > ( (/usr/lib/sendmail -oi -oem recipient2 ; /bin/rm -f /tmp/snd.6424) & ) < > /tmp/snd.6424 > > My suspicion is that the "mail buffer" file (/tmp/snd.6424) is overwritten > by the user before sendmail has had a chance to get to it. If recipient1 > is a long alias, it will take sendmail quite a long time to parse the > command line prior to reading its stdin. > [text deleted] Well, after finding the code for v2.2 and running in debug mode, I discovered that this bug has been fixed by prepending an alphabetic sequence number to the name of the mail buffer file. ( (/usr/lib/sendmail -oi -oem tperala ; /bin/rm -f /tmp/snd.AAA009052) & ) < /tmp/snd.AAA009052 Sorry to waste time and bandwidth. Flame me at (tperala@ub.d.umn.edu). ------------ Tim Perala Systems Programmer Information Services University of Minnesota, Duluth (218) 726-6122