Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!mintaka!mit-eddie!rutgers!umn-d-ub!tperala
From: tperala@umn-d-ub.D.UMN.EDU (Tim Perala)
Newsgroups: comp.mail.elm
Subject: Re: mail buffer overwriting (V2.1)
Summary: Mail buffer bug fixed in v2.2
Keywords: buffer bug overwrite
Message-ID: <3254@umn-d-ub.D.UMN.EDU>
Date: 7 Mar 90 16:39:06 GMT
References: <3252@umn-d-ub.D.UMN.EDU>
Organization: U of Minnesota-Duluth, Information Services
Lines: 34

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