When Thomas Gramstad wrote,
G> The subscriber's account at ISP 2 is closed, and address 2
G> produces error messages to the list manager. No clue to address 1
G> can be easily identified, but ISP 1 can be identified from the
G> headers or contents of the error message.
Nathan Mehl responded,
M> This has been a general problem for list managers (myself included)
M> since the first mailing list was created. Several mailing list
M> managers include features to help deal with it, and two MTAs (qmail
M> and postfix) implement Variable Envelope Response Paths to solve
M> the problem permanently.
VERPs are wonderful -- they take care of sites like Prodigy for example.
(I had a subscriber forwarding to a nonexistent address on Prodigy. Prodigy
returned only the information that there was no such mailbox on Prodigy as
that account number: Received: headers, no Subject:, and no text from the
original undelivered message. The concept that you don't recognize the
Prodigy account number because you wrote to someone who forwarded the message
to Prodigy escaped them and likely still does. If I'd had a VERP facility
available, that would have solved the problem. What I had to do instead,
sheesh.)
However, they don't help for subscriptions delivered to sites that don't
recognize envelope sender addresses and send NDNs to the From: or Reply-To:
or Sender: address. So VERPs go a long way but it's a great exaggeration to
claim that they "solve the problem permanently."
M> I have located the account causing you the problem and de-activated
M> it. You should see a more indicative bounce message shortly.
Good. Bigfoot manages to send a bounce that says which Bigfoot username
pointed to the undeliverable downstream address by including a "for" phrase
in the Received: headers even when the item was blind-carboned to more than
one Bigfoot address (at least in my tests). Surely iName can do something
similar.
