After further experiments, I don't think the Return-Path: header line is my
problem. Here's why:

From: "Ben Parker" <[log in to unmask]>
Sent: Wednesday, November 16, 2005 6:29 PM

> If you still don't see a Return-Path: header line (usually but not always
> first) then something else before your mail client is removing that header
> which is a very bad thing, and in itself a violation of RFC821.

I've been able to establish that AT&T has been removing the Return-Path:
header entries and substituting an X-Originating-IP: header line. Because
I've been slow to clean up old email from my mother, I can see they've been
doing this for about two years, and I have sent their support people an
inquiry about delivering incomplete headers.

However, if I send email from outside their network to a defunct AT&T
account, the returned delivery-failure report does show the Return-Path:
line from the original message.

Also, errors are detected when LISTSERV sends a renewal notice to a defunct
AT&T address, but not when it sends an active probe. Does a renewal notice
use a different tracking method? I can't see any difference in the headers.

Granted, I cannot compare the Return-Path: entries, which AT&T stripped
before they reached me. But they do show up in email bounced by AT&T, so
LISTSERV ought to have seen them in both my test cases.

> I said it is known that some mail systems do not like the '*' chars in the
> 'Probe-Style' Return-Path.

Would that be an issue on every hop, or just in the list server? or
the LISTSERV machine's domain? And is that fixed by the "sendmail hack" to
which you referred previously? We're definitely using a UNIX system (SunOS
5.9, according to the "release" command response).

Hal Keen