Hello,
Since no one is responding to this call for help does anyone know
where or
who else might be able to help
First, I suspect that other people are getting the same corrupted messages
from you that I am. If no one is replying, it's not because they aren't
willing to help you, it's because some error is corrupting your messages
and preventing us from reading them.
The headers of your messages contain the lines:
Received: from doma(_at_)ptd(_dot_)net by smtpw.ha-net.ptd.net by uid 50002 with
qmail-scanner-1.15
(uvscan: v4.1.60/v4245. spamassassin: 2.43. Clear:.
Processed in 1.817724 secs); 17 Apr 2003 12:41:58 -0000
Received: from
Message-Id: <E1968sX-0000Wv-01(_at_)venus(_dot_)ccil(_dot_)org>
From: fetchmail-friends-bounces+xxx(_at_)lists(_dot_)ccil(_dot_)org
Bcc:
Date: Thu, 17 Apr 2003 08:52:37 -0400
inetcmtssthptdnet-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1.cmts.sth.pt
d.net
(HELO fw.domsnet.net) ([24.229.126.100])
(envelope-sender <doma(_at_)ptd(_dot_)net>)
by smtpw.ha-net.ptd.net (qmail-ldap-1.03) with SMTP
for <fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org>; 17 Apr 2003
12:41:56 -0000
[...]
Everything below the empty line becomes part of the body of the message -
stripping off many of the essential headers.
I believe that lines between the "Received: from" and "inet....-1-1-1-1-1"
are inserted by the ptd.net mail servers. It may be the uvscan that is
corrupting these messages. You really should talk to whoever is upstream of
you and doing these scans. It makes your messages very difficult to view
and reply to.
As to your original question, see if you can view the messages on the
remote server, or somehow retrieve them by some other pop3 client than
fetchmail. I suspect it is probably the same problem as shown by your
outgoing messages. You state they may be junk mail, but you probably can't
tell for sure until they are retrieved.
You also have multidrop on. In the messages I receive from you, the
original To lines are pushed from the headers to the body of the email.
Some intervening server is regenerating the From and To lines since the
originals are no longer visible to the MTA. This would cause multidrop to
fail.
Try setting up a separate fetchmail session that has multidrop off. Run
this manually (not as a daemon). This should be able to retrieve and flush
the messages - you can then reconstruct them by hand and deliver them
manually, or delete them as appropriate.
As a longer term fix, either fix the uvscan, have someone rename that
horrible server name, or find another smtp server to relay your mail. This
issue is probably the cause of your "incorrect header line" errors from
fetchmail, as well as corrupting any messages you send to others.
I'd be happy to help you fix this, just post to the list (not directly to
me) - ideally from another mail account behind a different mail server.
~Jonathan