In message <9212151613.AA24245@z.nsf.gov> you write:
>
>> For things like "user unknown"
>> or "host unknown" (actually, after a few "host unknown" messages) I pass the
>> offending address to a little script I have called "bouncer". This takes
>> the address and sends a little "what's happened to this person"-type of mess
>age
>> to the postmaster at the offending site (so it takes joe@bozo.com and sends
>> to postmaster@bozo.com). This way I can find out for sure if the user has
>> left the site or if something is wrong with their system. I try to be sure
>> before shutting someone off.
>
>You are the nicest list manager in the world! How many total
>subscribers do you have on all your lists? How many bounces do you
>handle this way each week?
I couldn't imagine sending that many queries. A FAQ on how to handle
different kinds of bounce messages would be great. Great for list
managers and "normal people" too.
Here is my procedure for handling mailing-list bounce messages:
(1) Each time I get a bounce message, I record the offending address.
Sometimes the address doesn't match anything in my list. In that
case, I just record what I can. Sometimes the only thing that makes
sense is the address of the daemon that sent the message. That is
a lot better than nothing: it is usually sufficient to match
against subsequent bounce messages to see if I am getting repeated
instances.
(2) I see how many bounce messages I have gotten from the address,
i.e., how long the address seems to have been bouncing. If it is
'unknown user', I remove the address after the 2nd bounce message.
Otherwise, I remove the address after a month.
(3) Exception number 1: If it is 'unknown host', I see if the host is
in an old hosttable and I can get the IP number. If so, I look up
the new host name and modify the address. If there are only a few
major hosts in the domain, I might fish for the name using finger
too.
(4) Exception number 2: It may be that I cannot find the corresponding
address in my mailing list. If so, I look for likely
redistribution lists, and send a message to the redistribution
list's owner (if I have a record of him/her) or to the host's
postmaster.
(5) Exception number 3: If there is no corresponding mailing list, I
may have to do some real guessing. If I think I have identified
the node, then once again, I send a message to the node's postmaster.
Anyone who has dealt with large lists know that it is possible to go
through this entire procedure and still not eliminate a bounce
message. Not likely, but certainly possible. So far I have been
lucky. One further measure would be to write a procedure that mails a
unique message to each and every different address in the mailing list,
e.g., a message which contains the destination address in the body.
Then if you are lucky, the bounce message will tell the story. You
also might be able to try such things one at a time if you have some
candidate addresses.
Part of the reason the above procedure works for me is that my list is
digested and the digests are mailed like clockwork, twice a week. Thus
if I get two bounce messages in a row for unknown user, I know that the
condition has persisted for days. Likewise, it is easy to see from
records of bounced addresses if a message has bounced every time over
the last month. A 'normal' mailing list that isn't digested can't be
handed so easily.
One thing which I would love to see would be an archive of host
name-changes. I imagine ftping a file of recent hostname changes once
a week, and when I get an "unknown host" bounce message, I look up the
old hostname in the file and get the new hostname. What a wonderful
service that would be if some philanthropic site saw fit to offer it.
Postmasters would have a way of heading off a lot of e-mail problems.
One could imagine the concept extended to handle full e-mail addresses
too, e.g.
jjdoe@bullwinkle.edu --> johnd@rocky.com
*@bugs.navy.mil --> *@porky.navy.mil
Naturally, such an archive could be rolled over after some reasonable
amount of time. And after just a short time, people would be inventing
little client-server tools to get the data in slick ways, or when
bounce messages are standardized, making such updates happen
automatically.
John Wobus
Syracuse University
Not volunteering, alas...
References:
|
|
