Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!umn-d-ub!tperala
From: tperala@umn-d-ub.D.UMN.EDU (Tim Perala)
Newsgroups: comp.mail.elm
Subject: mail buffer overwriting (V2.1)
Keywords: buffer bug overwrite
Message-ID: <3252@umn-d-ub.D.UMN.EDU>
Date: 6 Mar 90 17:12:00 GMT
Organization: U of Minnesota-Duluth, Information Services
Lines: 50

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