question about the new sendmail prescan bug

[Xiang Hong <xiangh () ict ac cn>]

hi all, i'm new here, so please forgive me if i don't follow any of the 
conventions of this list.

i've been looking at the new sendmail bug but can't find a way to 
exploit it.
from the patch released, i noticed that if a token is too long (256 
chars), prescan() will return with delimptr pointing to an address one 
beyond the end of addr buffer. then the next time parseaddr() gets 
called (from a loop in sendtolist()), it'll be processing something 
wild. chances are prescan call will return with a non-NULL pvp, and this 
will make invalidaddr() be called, and a '\0' will be written to the 
address pointed by delimptr. if this address is part of local variable 
bufp in sendtolist(), we have the exploit mentioned in Michal Zalewski's 
full-disclosure post.
looking at the sendtolist() code, bufp seems to reside in an address 
following buf, and the way described above seems to work. but when i 
gdb'ed sendmail compiled with the default -O2 switch, i found buf is at 
the bottom of the stack, writting somthing beyond its end won't change 
the value of bufp.

btw, i don't quite understand how local variables are organized on 
stack, eg. how paddings/alignments apply, when the -Ox switch is on.

thanks for any response and best regards.