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