One (and apparently only one) of my subscribers is getting some messages that show up in Eudora with "From ???@??? Wed Aug 05 19:49:33 1998", where the date and time is the time of the download. When she opens the messages all the appropriate information is present, but filters don't work, and she cannot see who the message is from or the subject until she opens the message. Her ISP insists the problem is with LISTSERV. Since all the other ISPs that get mail from the list are apparently able to handle the messages without the "From ???@???" lines I think the ISP is not following the mail RFCs. But I need specifics to present to the ISP, or a workaround if the ISP is unwilling to fix the problem. The problem did not occur until I started moderating the list, and it only occurs when I use the "resend" feature. It's reproducible. My list is moderated and I handle approval in two different ways. If the message is acceptable as is, I use the resend feature of my mail reader (Yarn) which inserts "Resent-from: [log in to unmask]" and "Resent-to: [log in to unmask]" lines in the header and mails the post back to LISTSERV. LISTSERV strips out the standard paragraph explaining the resend feature, and sends the post to the list. The post appears to come from the original sender, not the moderator. I use the second method of approval when the post needs to be edited (excess quoting, formatted as one long line, et cetera). I forward the message to the list, edit it, and add a flag to the header that tells a post-processor program I wrote to snarf the original sender's name from the information below the "------- Forwarded Message ------", change the "From: [log in to unmask]" to "From: [log in to unmask]", add the appropriate "Resent" lines, and then strip all signs of the forward. The post-processor is necessary because Yarn is paternalistic and will not allow me to change the "From" line to the original sender. This sounds complicated, but it's automated and is quite fast. The post appears to come from the original sender, just as in the first method. The problem arises with the first method. The "resend" preserves a lot of header lines that are stripped when a message is forwarded. Perhaps these header lines are confusing the software at the ISP of the affected subscriber. At any rate, _something_ is different about the resent messages and that something is confusing the ISPs mail software. Any pointers to a solution (yes, another ISP comes to mind) would be much appreciated. I suppose I could change my post-processor to strip all the extra header lines preserved by resend, but I'm fairly sure they are there because the RFCs call for them to be there. The author of Yarn seems to have done an excellent job of complying with the RFCs in other areas (how many mail readers implement true resend?) and I doubt he dropped the ball here. TIA, -rex