>  I'm sorry, there is no discrepancy between  1.5i and 1.5j.
 
Maybe. At least I was not able to reconstruct the problem under
1.5j-1.5j peering (but I only tried it with two lists at the same
machine). Nevertheless I was able to reproduce the problem with
peered test lists (with a 1.5i host) - at least partially (only
the "Processing your mail ..." mail, but not the statistics mail).
I was astonished because usually this kind of bugs vanishes as soon
as you have a safe test environment, but reappears in real life
immediately :-)
 
> Both of them have the same statement:
>                If domain ^= '' Then Return 0
> .......
>The point is that routine SENDLIST does:
>  Parse var fromid '@' '.'domain
>and then  you have the IF  I quoted above. If  it doesn't work, there  are two
>explanations:
>1) DOMAIN  gets disrupted  somewhere. It's  used before  (in the  mail parsing
>   routine) and after, but only in PROCEDUREs.
 
domain isn't disrupted because:
 
>2) FROMID is incorrect. I'd say the problem is here, but can't see why...
 
Exactly. fromid is set to the address of the peer list that was
forwarding the letter. Apparently this does occur only under certain
circumstances (some assorted magic + ACK in the LSV... header).
 
Eric, have fun with the trace output of LSVXMAIL that I have sent
to you. I assume that the complexity of LSVXMAIL and the visibility
rules of Rexx together with the attempt to write efficient Rexx
code have caused this glitch. I really don't believe that Rexx is
well suited for large programs (at least not for the production version).
And considering all this I'm impressed by the quality of the Listserv
code. But I'm wondering what you could do if you were using a real
programming language :-)
 
  Thomas