+ Norbert Bollow <[EMAIL PROTECTED]>:
| > and ezmlm setup
|
| What are the configuration files/options that you feel should be
| shared?
Don't know, since I don't do ezmlm. But it seems very unlikely to be
an ezmlm problem anyway.
Your setup (which I won't repeat here, for brevity's sake) seems
eminently reasonable, and I cannot find any evidence there that would
point a finger at qmail. So let us return to the headers you quoted:
| Received: (qmail 28924 invoked by uid 894); 11 Mar 2001 14:10:29 -0000
| Delivered-To: home0-0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED]
| Received: (qmail 28921 invoked from network); 11 Mar 2001 14:10:29 -0000
| Received: from smv665-mc.mail.com (165.251.4.203)
| by tasc.surrogacy.org with SMTP; 11 Mar 2001 14:10:29 -0000
| Received: from localhost (localhost)
| by smv665-mc.mail.com (8.9.3/8.9.1SMV070400) with internal id UDK05175;
| Sun, 11 Mar 2001 04:10:27 -0500 (EST)
| Date: Sun, 11 Mar 2001 04:10:27 -0500 (EST)
| From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
| Message-Id: <[EMAIL PROTECTED]>
| To: <pps-l-return-64-**CENSORED**[EMAIL PROTECTED]>
To me, that To: field whose address must surely have come from the
envelope sender, at least shows that the message arrived at iname.net
with the correct envelope sender. But I'm willing to bet a modest
amount that iname.net mangled the envelope recipient of the bounce
into <0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED]>
with the results you have seen. At least, that theory is consistent
with everything you have shown us.
There it is, then: Not a qmail problem at all, but some external host
perhaps having troubles coping with an unusal form of email address.
Perhaps a sendmail.cf entry thrown off by the equals sign in there?
If you still have your log files lying around, you might look for
further evidence there, but I really don't think you can blame this on
qmail or ezmlm at all.
Oh, and concerning others' reactions to your hiding the user's
identity: It's just a reflex action, flaming everybody to a crisp who
does header mangling before asking questions. In 99.9% of all cases
the flaming is fully justified, since the mangling really throws away
useful information. But I think it's quite clear that this was not
the case here.
- Harald
