> Anyway, I finally got around to pruning the list of supposedly
> "invalid" e-mail addresses (it's a chore to even FIND the right
> address in a bounce message -- but that's another story) and
> guess what? About 50% of the "pruned addresses" resulted in
> a subscriber e-mailing back "hey, why was I unsubscribed?"
>
> In other words, I am getting bounce messages for mail that was
> *also* delivered, and of course the recipient doesn't have
> a clue unless I complain. Is this the same experience the rest
> of you have? How do you sort true invalid addresses from
> semi-true addresses which also deliver? Or should we even
> care?
One of the lists I run has about 5000 subscribers but mails
out only one large message per week. One week, I took every
"permanent" bounce message from that list and saved it in
a special folder for later analysis. ("delay" bounce messages
of the form "we've so far failed to delivery your message, but
will keep trying" were not saved or analyzed.) The sample was
taken after I spent several weeks deleting subscriptions for
those whose mail bounced, so in general, these errors were "new"
for the week.
Out of 5067 recipients for that digest, 59 errors were reported.
34 of those appeared to be legitimate errors, meaning that the
message delivery failed because the subscriber address was no
longer valid or the host was not reachable. 22 of the errors
appeared to be due to configuration failures (either of DNS,
routing, or mail forwarding), or inability to gracefully handle
exceptional conditions ("can't write file"). 3 of the error
messages did not contain sufficient information to allow the
problem to be analyzed.
So 22 out of 59 "permanent" error messages were reporting
transient conditions or conditions that could be fixed
by proper configuration.
The breakdown in error messages was as follows:
total legit
user unknown (note 1) 16 16
host unknown:
DNS configuration error 2 (note 2)
BITNET address had gone away 7 (note 3)
other 1
TOTAL 10 8
host down/connection timed out 7 7
local configuration error (improper MX handling) 6 0
can't create output / can't write file / i/o error 5 0
too many hops / looping detected 4 0
bad forwarding address 3 0
program not found 2 0
user's mail reception disabled 1 1
message exceeded size limit 1 1
redirect to new domain name 1 1
TOTAL 56 34
errors for which no reason was reported 3 ?
1. all of the "user unknown" errors were considered "legitimate"
because I had no reliable way to determine otherwise. However,
I regularly get complaints from people whose subscriptions were
deleted because of "user unknown" bounces. When I have been able
to obtain additional information from postmaters at such sites,
the explanation is usually something of the form "the machine
was down". In some cases it appears that NIS server failures
(i.e. the lack of adequate slave servers) were the culprit.
2. DNS configuration errors were identified by looking at each of
the DNS servers for the recipient's domain and comparing the
results returned from a query of type ANY for that domain.
If the results were inconsistent in a way that would cause
mail to be misrouted, or if the results were inconsistent in any
way but the serial numbers on the SOA records matched, this was
considered a configuration error.
3. The list contains several user@node.BITNET addresses. BITNET
hosts are dropping like flies and with no advance notice.
|
|
