>I have two private lists with members reporting that emails sent out to the list by certain people on the list are not get through to them. They know this because when someone else on the list replies to the original message (back to the list), they see the reply which then contains the original message. I am a list owner, not a list server admin so I am somewhat limited in diagnosing this from the server perspective (but our server admin would definitely help if I can tell him what to look for). Does anyone have any recommendations for where to start ? I am not seeing any list message delivery error reports for these members concerning these messages. I agree with what's been said so far: it looks like some kind of filtering at the receiving end. There is another possibility worth mentioning; some email domains use an oversimplified "loop detection" algorithm which simply blocks anything with too many "Received:" entries in the header. I have seen thresholds set as low as 10. (RFC 2821 says if this method is used, the threshold should be at least 100.)Since reaching our LISTSERV server and getting back out of its domain takes seven hops, that often causes particular domains to drop email from specific contributors, depending on how many hops the message accumulates before it leaves the sender's domain. This is a less-likely explanation, because loop-detect rejections do normally trigger error reports--at least, the ones I know about do! But it's possible, and can be diagnosed by checking the headers of the messages that don't get through: if the particular senders who get rejected happen to be the ones with long "Received:" trails in their headers, it might be the real cause. I have gotten a number of my subscribers to get the thresholds increased in their domains, and I have set the SHORTHDR option for a couple who either couldn't or wouldn't do that. Is the problem sporadic or consistent, by the way? A lot of filtering happens on a short-term basis (a few days), because some normally well-behaved domain got tagged in a database as wrongly configured or a source of spam. Again, though, most of my knowledge of these events is because of the ones that DO send error messages. The filtering setup that is most likely to produce no error reports is right at the end of the line: I have had subscribers whose lost mail turned out to be getting dumped in a folder they hadn't checked, because of an unexpected side effect of a filter. Hal Keen