> 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