A Beginner's Guide to the Internet/INTERNET.ISO/text/email/fixemail.txt

Text File | 1996-05-06 | 55.5 KB | 1,168 lines

MaasInfo.FailNet = "Fixing Addresses" = How to fix e-mail addresses
that didn't work, by Robert Elton Maas, [e-mail], 415-969-2958,
brand new file first created 1993.May.12, draft version of 1993.Dec.15.
This file is "trivial shareware", see MaasInfo.TopIndex for details.

                 Introduction

A question which appears frequently on the USENET is, "I tried to send
private e-mail to the poster of some Usenet article, but my e-mail
bounced. What I had to say is not of general enough interest to post to
the whole newsgroup, so I'd really like to find that person's correct
electronic mail address somewhere. How can I find it?"

There are many different techniques for doing this. Several of them are
discussed below, divided into categories according to the kind of error
message you got when you originally tried the e-mail, and illustrated
with actual examples of addresses for which the author has successfully
found corrections.

Note there is already a document called "Finding Addresses" which would
seem similar but approaches the problem from a different direction. In
that other document, the assumption is you know something personal
about somebody, such as their real name and where they work or go to
school etc., but are unsure whether they really do have network access,
or if they do have no idea what their e-mail address might be. But here
we know the person has network access because we already saw something
posted by them, but we know nothing else about them because we've never
met them except over the net. Of course if you have both kinds of
information, then the techniques in both documents may be useful. As
much as reasonable I'll try not to overlap the methods described in
"Finding Addresses", except where those methods are especially useful
for the situations described in this document. For anyone who doesn't
yet have a copy of "Finding Addresses" and also doesn't have
MaasInfo.DocIndex, here's a copy of the pointer from MaasInfo.DocIndex:

EMAIL_ADDRESSES.TXT (29k) -- finding-addresses -- "How to find people's
E-mail addresses" -- List of techniques for finding somebody's e-mail
address given the name, by Jonathan I. Kamens <[e-mail]>. Includes
instructions for using the new UseNet white-pages directory service.
Posted to newsgroups comp.mail.misc soc.net-people
news.newusers.questions news.answers comp.answers soc.answers. Warning,
this file contains tabs which don't have the intended effect on some
systems such as VM/CMS. &&LocalEdit (Are tabs gone now?)
ftp rtfm.mit.edu /pub/usenet/news.answers/finding-addresses (29k)
Warning: The following copy is very old and presumably out of date:
ftp hydra.uwo.ca (129.100.2.13) LIBSOFT/email_address.txt (14k, 1991.Nov)
625-IP-&E (Ask if he knows who maintains that version so we can ask them to
please update it?)

E-mail is short for electronic mail, i.e. messages that are composed on
one computer by one person then transmitted to another computer
(usually a different computer, but occasionally the very same computer)
and then read by another person. Generally e-mail is directed to the
recipient (reader) by an e-mail address, and replies are directed back
to the sender by another e-mail address. Each e-mail address generally
tells the name of the host (computer) where that e-mail is directed,
and the name of the user on that host who is to receive that e-mail. An
e-mail address can be bad, causing the e-mail not to be correctly
delivered, for several reasons: (1) The syntax of the address can be
completely meaningless (garbage). (2) The name of the host can be wrong
or obsolete. (3) The host can be down or have its mail service screwed
up. (4) The name of the user can be wrong or obsolete. Inspection of an
alleged e-mail address can usually detect a syntax error. If an address
looks perfectly fine, distinguishing among the other three cases is not
so easy, although the error message that accompanies a non-delivery
notification (a "bounce") can often give clues what may have been
wrong. These clues can then be used to track down the correct e-mail
address, either directly or by asking the Postmaster at some
appropriate host.

Internet DNS (Domain Name System/Service) addresses are of the form
user@host, where host is of the form a.b.c.d...x.y.z (any number of
words separated by periods, but always at least two words with one
period). 'z' is the toplevel domain, either a class of service (such
as: edu com mil net) or the code of a country (such as: us uk au). 'y'
is the next-to-top domain, 'x' is the third-from-top, etc. down to 'a'
which is the actual host name.

UUCP addresses are paths of the form a!b!c...x!y!z (any number of words
separated by exclamation points). 'a' is the first host along the route
(after the originating host), 'b' is the next, etc. and finally 'y' is
the actual host of the recipient and 'z' is the username of the
recipient.

Rooted UUCP addresses are just like UUCP addresses (paths) except they
include an Internet DNS hostname as the first host name. There are two
forms: b!c...x!y!z@a and a!b!c...x!y!z, where 'a' is a full Internet
DNS hostname, 'b' etc. thru 'x' are UUCP hostnames along a path to the
destination host 'y' with user 'z'.

Internet paths are of the form user%host@mainhost where 'user' is the
user name as before, 'host' is the actual host that user is on, either
in DNS format or in some local format known only to mainhost, and
mainhost is some well-connected host name in DNS format. E-mail is sent
to mainhost where it is forwarded to host and delivered to user.

Note that the user name can be rather complicated, such as first and
last name separated by underscore or period, or simple such as just a
last name or first name or moniker, or totally cryptic such as just a
number. In particular, most user names on Compuserve (as seen from
Internet) are just two numbers separated by a period.

One special case to note is the 'bitnet' pseudo-domain. An address such
as [e-mail] is not actually a valid DNS address, but will
work on some systems. It means the username is 34AEJ7D, the hostname is
CMUVM, on BitNet. Some systems will automatically send e-mail with such
addresses to the nearest InterNet/BitNet gateway, which will then
recognize it as a BitNet address, strip off the .BitNet suffix, and
deliver correctly to 34AEJ7D at CMUVM. Other hosts will just reject it
as not a valid DNS address. If you are on such a host that rejects it,
you'll have to rewrite such addresses as 34AEJ7D%CMUVM.bitnet@mainhost,
where 'mainhost' is some InterNet/BitNet gateway you know about,
preferably one near you.

Another special case to note is the 'uucp' pseudo-domain. An address
such as [e-mail] really means daat!asd. If your host doesn't make
that translation automatically, you'll have to do it manually. If the
address then bounces (Bad system name: daat), well at least you have
the syntax correct but your host doesn't know how to reach host daat,
and now you'll have to see below how to discover a UUCP path that
actually works from your particular host to the host of your desired
recipient.

Note that for most InterNet addresses, the host name is
case-insensitive (atreyu.engin.umich.edu is the same as
ATREYU.ENGIN.UMICH.EDU or Atreyu.Engin.UMich.Edu) whereas the username
may be case-sensitive on some systems (especially Unix).

Any alleged e-mail address not of any of the above forms is probably
invalid. For example, I tried to reply to Usenet articles with these
return addresses: 764.UTAH.EDU (either a DNS hostname with no user, or
user 764 on host UTAH.EDU but with the atsign trashed to a period, or
just total trash; haven't yet found the correct address),
[e-mail] (a very old and local address format,
invalid because the toplevel domain is neither a 2-letter country code
nor a special three-letter domain; the correct address turned out to be
[e-mail] at the time, but even
that format is obsolete now, the .arpa pseudo-domain is no longer
considered correct; someday I'll have to track down that person's
current e-mail address just for fun), cathl@odin (in DNS format except
only one component in hostname whereas two is the minimum allowed; the
correct address turned out to be infmx![e-mail]),
[e-mail] (another DNS format address with invalid toplevel
domain; I haven't been able to find this person's correct address yet),
[e-mail] (this actually is correct syntax, but
obviously trashed, the word "essential" duplicated due to bug in the
software or configuration there; correct address is
[e-mail]), edmark (this is NOT how I sent out my original
e-mail, but when it bounced it came back that way, as if I hadn't
specified a host at all; the correct address may be
[e-mail], not yet confirmed), ekabatch@us (trashed
during bounce process again; correct address turned out to be
[e-mail]).

Even if the syntax of the recipient's e-mail address is valid according
to one of the possibilities described above, one of the hosts your
message must traverse might not understand that particular syntax, so
you might have to switch to some equivalent but different syntax. Only
pure DNS addresses are required to work on Internet hosts, and only
pure UUCP paths are required to work on UUCP hosts (and the work ONLY
if your host knows how to reach the first host in the list and each
host knows how to reach the next). All the other formats (rooted UUCP
paths, Internet paths, etc.) are optional formats that only some (most)
hosts understand and NO hosts are actually required to understand. See
below for at least one example of switching to another "equivalent"
syntax.


%% General methods/tools

UseNet WhitePages: If the recipient has posted to any well-known UseNet
newsgroup since about 1991.August, that person's posting has probably
been registered in the database (e-mail address or path, parenthetical
remark, and date posted). Given some bad address that was used, you can
find out the parenthetical remark, usually the human name, then use
that name to find other addresses the same person posted from. If the
original address didn't work, chances are one of the others will work
fine, so try them all until you find one that works (and ask the person
if he's really the same person, since once in a while you'll find a
completely different person who happens to have exactly the same name).

Berkeley NetInfo UPATH and UHOST: If you're having trouble finding a
route to a UUCP host, UPATH will often tell you a rooted path, while
UHOST will tell you other information such as the system
administrator's e-mail address.

Berkeley NetInfo ANY: If you're having trouble figuring out something
about a DNS hostname or its parent domain, ANY will often tell you
information about MX forwarding connected with that host.

NIC WHOIS: If you're having trouble figuring out something about a DNS
hostname or its parent domain, WHOIS will often tell you the name and
e-mail address of the people responsible for maintaining that
particular domain (for United States military DDN hosts, nic.ddn.mil;
for all other hosts, InterNIC).

Access info for those general methods are described in MaasInfo.HowNet.
Similar information may be obtained from software that is available
only on particular hosts (such as Unix 'nslookup'), which may be more
efficient than connecting to Berkeley NetInfo or NIC. Check your local
documentation or customer support or sysadmin to learn if any such
software is available on your local host, or read the FAQ for the
interest group (mailing list or newsgroup) dealing with your particular
kind of operating system.

Other less proper tricks sometimes work also, such as:

Chopping off the low-order part of a DNS address, for example changing
[e-mail] to read just [e-mail]
(you'd be amazed how often that trick works when the low-order part is
the name of a workstation that is hardly ever online for accepting
e-mail).

Asking somebody else with the same RARE last name if they happen to be
related to the person you want to contact.

See the case histories below for more examples of tricks that sometimes
work.

Of course if you get through to the correct host just fine, but the
user name is invalid, you ask the Postmaster at that same host.


%% Excerpts from successful case histories:

The bulk of this document consists of actual examples of e-mail
addresses that didn't work for me, causing my e-mail to bounce, but for
which I was able to track down the correct address and finally deliver
my previously-bounced e-mail. I'll try to organize them in some logical
manner, but you may want to simply browse all the case histories to get
a full feel for what methods are available and sometimes work. In most
of these cases the host name was unusable, either no such host, or a
workstation that can't accept incoming e-mail, or a host badly
mis-configured, or incomplete/wrong UUCP path to that host, etc. The
easy case, where the host is perfectly ok but the username is wrong,
hardly needs lots of examples (query the UseNet WhitePages to find the
human name associated with the bad address that was posted, then ask
the Postmaster at that host for the correct e-mail address of that
person). But most of the time you don't know whether it's the host/path
or the username or BOTH that is/are wrong, so you have to do some
detective work before you even know which host's Postmaster can help
you.


% Trashed address upon bounce, just guess the correct address:

I got a bounce claiming I had used this address:
  74170.2364: MX@"[e-mail]".btr.com
and listing as the reason for failure:
  Invalid receiver address: MX@[e-mail]
I guessed the correct address might be:
  [e-mail]
so I tried it and indeed it worked and was the correct person.

I got a bounce claiming I had used this address:
  ghb@ecsvax%Forsythe.Stanford.Edu
which was obviously trashed, the atsign and percent interchanged, so I
switched them to:
  [e-mail]
which worked fine. The return address on his ack was:
  [e-mail]
which I'm checking now to see if it too works.

I got a bounce claiming I had used this address:
  sharonh@.informix.com
with the error message Host unknown. Obviously the low-order part of
the host name was missing, or else there was an extra period inserted
and "informix.com" was the full host name? Anyway I tried:
  [e-mail]
and that worked, so I guess I was lucky that time.


% Transforming to a more standard address format:

E-mail to:
  bcvms.bc.edu!BELSLEY
bounced (cannot resolve name), so I transformed it to:
  [e-mail]
which worked just fine. The clue was the particular error message which
sounded more like a syntax error than a regular kind of error (no such
user, or no such host).

E-mail to:
  netxcom.netx.com!bob
bounced (Undeliverable Mail), so I transformed it to:
  [e-mail]
which worked just fine. The clue wasn't quite as strong with this error
message, but my guess turned out to be correct anyway.


% Routing UUCP mail through uunet.uu.net:

E-mail to:
  procase!doc
bounced (bad system name), because our local host (BTR.Com) doesn't
have any UUCP maps, doesn't know how to re-direct UUCP mail to a host
that does have such maps, and isn't directly connected to procase. But
I simply re-directed it through UUNET like this:
  procase![e-mail]
and worked just fine. The funny thing our local host DOES know how to
transform the address [e-mail] into procase!doc, and routinely
does that, then bounces the e-mail. I guess that initial transformation
saves me a little bit of copy&paste work :-), since I can just append
the @uunet.uu.net part without having to rearrange the other parts and
insert the exclamation mark. Since a very large number of articles on
Usenet are posted with just [e-mail] as the return address, this
standard fixup is VERY common, and when I fail to notice it and fix it in
my initial reply I then automatically re-send the bounce when it arrives.

One note about efficiency and courtesy: We (BTR.Com) get our newsfeed
directly from UUNET (and I assume we pay money for it), so I don't feel
too bad redirecting all [e-mail] mail through it when it's in
reply to a Usenet article we got from them that had a bad address. But
if you have a large file you're sending somebody with such an address,
especially if you're not a direct customer of UUNET, you might consider
sending a test message via uunet first, and then re-sending the big
bounce only after the address has been confirmed, and sending to that
same address only if the recipient doesn't suggest a better address to
use. Or maybe don't use this method at all except as a last resort,
instead try using the Berkeley NetInfo UHOST command to find the
preferred rooted-UUCP path to the UUCP host you're trying to reach.


% Dropping the low-order part of a DNS hostname:

My e-mail to:
  [e-mail]
bounced (Host dvlseq.us.oracle.com is down), and I guessed that dvlseq
might be a workstation that is not always turned on, whereas the parent
domain might also be the name of a parent computer that is more often
online, so I tried:
  [e-mail]
and it worked just fine. Note this is NOT a sure thing. Sometimes this
trick works, and sometimes it doesn't.

The same trick worked for:
  [e-mail] (Address family not supported by protocol family)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Host atreyu.engin.umich.edu not found ...)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Host unknown)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Cannot send message for 5 days)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Cannot send message for 5 days)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (sendall: too many hops (30 max))
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Host ekhadafi.austin.ibm.com not found ...)
  [e-mail] (worked fine, but he suggested a better address:)
  [e-mail] (which also worked fine)
Likewise:
  [e-mail] (Host poco.cs.nmsu.edu not found ...)
  [e-mail] (Host cs.nmsu.edu not found ...)
  [e-mail] (worked fine)
Likewise:
  [e-mail] (Host unknown)
  [e-mail] (worked fine)
(I'm going alphabetically, so the reader can estimate how many other
such successful examples are in my database.)

I've cited so many examples above because the "experts" say NOT to use
this trick because it "hardly ever is correct", but in my experience it
VERY OFTEN works, and I want to prove my case here. Perhaps a
compromise is in order: Ask Berkeley NetInfo ANY or Unix 'nslookup'
etc. about the various truncated domain names to verify the "parent
host" really exists, before sending any test messages to the concocted
address.


% UseNet WhitePages to track down human name and alternate addresses:

My e-mail to:
  [e-mail]
bounced (Host prawn.ph.ic not found for mailer ddn), so I sent a query
to the UseNet WhitePages with the keyword "atae". I got back that same
e-mail address, but with the human name and date last posted from that
address:
  [e-mail] (Ata Etemadi) (Mar 1 93)
I also got back several other e-mail addresses that consisted of the
same username atae but different host name. Using the human-name that
accompanied them, I was able to guess that this one might be the same
person:
  [e-mail] (Ata Etemadi) (Apr 1 93)
and indeed that particular one worked fine (several other addresses I
found for that same person failed just like the original; I had to keep
trying until I found one that worked).

E-mail to:
  fernwood!mipos2!bverreau
bounced (uucp name < mipos2 > unknown at fernwood), so I checked the
UseNet WhitePages and found two entries with that same UUCP path, one:
  (something)!mipos2!bverreau (Bernie Verreau) (Aug 21 92)
and another:
  (something)!mipos2!bverreau (stargazer) (Aug 11 92)
That same WhitePages query also turned up this other entry:
  [e-mail] (stargazer) (Jul 12 92)
which was a slightly differently hostname but same username and same
nickname, so I figured it was the same person and indeed it was
(probably the same host also). Once we had established e-mail contact,
he told me a better address to use, which indeed worked too:
  [e-mail]

E-mail to:
  [e-mail]
bounced (unknown user), so I sent a query with the keyword "daj20"
and got back that same address but with human-name and address:
  [e-mail] (Daniel A Jatnieks) (Mar 1 93)
and also got back a different address with essentially the same name:
  [e-mail] (daniel a jatnieks) (Jul 21 92)
which worked just fine. Once communication was established, that person
sent me a preferred e-mail address which also worked:
  [e-mail]

I could go on and on with routine examples of this powerful tool but
I'll stop there. Let me just say I have found this to be my number one
most useful tool/method for tracking down alternate e-mail addresses
for the same person. Here's one somewhat strange example where this was
useful. A job ad had a totally bogus return address of just the
parenthetical remark:
  (Bill Noonan)
but using the UseNet WhitePages I tracked down this poster:
  [e-mail] (Bill Noonan) (Apr 1 92)
who explained that he deliberately trashed his return address to avoid
getting any e-mail replies to his job ad. (So now I guess he's mad at
me for exposing his trick, and he'll never hire me, but I don't think
I'd really enjoy working for somebody who hated e-mail that badly. :-)


% Using Berkeley NetInfo UPATH to find a path to a UUCP host:

Somehow the return address was:
  fernwood!btr!public!fernwood!halfdome!bob
which is obviously trashed (loop in the path is most obvious, where
fernwood appears twice), and I didn't notice the trash before replying,
so of course my reply bounced:
  This mail message is undeliverable.
I connected to Berkeley NetInfo and gave the command:
  UPATH halfdome
which told me the generic rooted-UUCP-path to users on that host, so
substuting 'bob' for the username gave me:
  noe!halfdome![e-mail]
which worked just fine.


% Using Berkeley NetInfo ANY (or Unix 'nslookup', etc.) to track down
some forwarding node, usually a MX node:

E-mail to:
  [e-mail]
bounced (Host unknown), so I connected to Berkeley NetInfo and asked:
  ANY golem.kharkov.ua
which gave me back this info:
  golem.kharkov.ua        IN      MX      100 relay.fuug.fi
  golem.kharkov.ua        IN      MX      200 mcsun.eu.net
so I concocted these indirect addresses (InterNet routes):
  [e-mail]
  [e-mail]
and both worked fine. I got lucky here. Eastern Europe has been VERY
difficult to contact recently (which is better than a couple years ago
when the soviet government was still in control and it was just about
IMPOSSIBLE to contact). Even in the Western world, the fact a host is
advertised as an MX forwarding host for another less-connected host is
no assurance at all that it will accept the % syntax for Internet
routes, and due to mis-configuration is not even a guarantee it really
does accept forwarding for that host at all. For example,
phlpa.pha.pa.us is listed as having three hosts (cs.widener.edu,
tattoo.cs.widener.edu, and ub-gate.ub.com) providing MX service for it,
and yet not one of those hosts is able to contact it (errors: "Host
phlpa.pha.pa.us not found for mailer ddn", "%MAIL-E-ERRACTRNS, error
activating transport SCOTT", and "Host phlpa.pha.pa.us not found for
mailer ddn", respectively).


% Recognizing a DNS name in the middle of a UUCP path, and rooting from
there instead (dropping all the preceding hostnames from the path):

E-mail to this address:
  ames!elroy.Jpl.Nasa.Gov!usc!wndrsvr.la.ca.us!andyb
bounced (bad system name), so I simply dropped everything before
wndrsvr.la.ca.us, and switched to regular InterNet syntax:
  [e-mail]
and it worked fine.

E-mail to this address:
  spool.mu.edu!olivea!gossip.pyramid.com!pyramid![e-mail]
bounced (spool . mu . edu ! olivea ! gossip . pyramid . com ! pyramid !
lstowell : unknown person or mailing list), so I dropped most of that
path and tried:
  gossip.pyramid.com!pyramid!lstowell
which worked fine. The recipient then suggested a better address:
  [e-mail]
which also worked.


% Recognizing a UUCP name for an InterNet host in the middle of a UUCP
path, and rooting from there instead (dropping all the preceding
hostnames from the path):

E-mail to this address:
  gatech.edu!decvax!decwrl!megatest!plethorax!alung
bounced with this reason:
  This mail message is undeliverable. (Probably to or from system 'decvax'))
but I recognized that decwrl is the UUCP name for decwrl.dec.com, so I
changed it to:
  decwrl.dec.com!megatest!plethorax!alung
and that worked just fine, although the recipient then told me an even
better address to use instead:
  [e-mail]
which also worked fine.


% Indirecting through a more local UUCP host:

Before BTR obtained direct Internet access, we had only UUCP access via
three neighboring nodes (fernwood, decwrl, and a third one I always
forget). Often a UUCP path as posted on the net started from some "well
known" UUCP host which didn't happen to be adjacent to BTR, so that
path didn't work. For example, e-mail to:
  ames!scubed!crash.cts.com!mcohan
bounced (bad system name), but simply including fernwood at the start:
  fernwood!ames!scubed!crash.cts.com!mcohan
fixed the problem; that path worked just fine from BTR. In other cases
I might have had to add both fernwood and uunet at the start of the
path, if fernwood doesn't know how to contact the next hop listed after
it, but uunet does. I'll see if an actual example of that turns up ...
Ok, I found one, e-mail to:
  fernwood!mertwig!xyzzy
bounced (uucp name < mertwig > unknown at fernwood), but inserting
'uunet' in the path worked fine:
  fernwood!uunet!mertwig!xyzzy


% Indirecting through a better connected Internet host:

If your own host isn't configured properly, especially in regard to MX
records supplied by the domain server it uses, e-mail might bounce even
though the e-mail address was correct. If you're pretty sure it is
correct (for example if you checked NetInfo at Berkeley and found the
host is valid), you might try indirecting a test message through some
well connected well configured host in your area. For example, e-mail
from here to:
  [e-mail]
bounced (This mail message is undeliverable), so I tried instead:
  [e-mail]
and that worked just fine.

This case is nearly identical: E-mail to:
  [e-mail]
bounced (This mail message is undeliverable), but e-mail to:
  [e-mail]
worked just fine.

Please use this method sparingly. The administration of some hosts get
rather angry if they catch you sending a lot of e-mail through their
host for no apparent reason, especially when their connection to the
net is already full and so your traffic displaces more legitimate
traffic. Sometimes the problem isn't in your host but in the
nameservers. They might have inconsistent information, one having
correct info and another having trashed info. If your host happens to
preferentially use the one with trashed info ... well I think you can
figure out what would happen.


% If the user seems to be definitely located at some major school that
provides good directory service, try NetFind (sort of a Gopher-style
WHOIS service, described in MaasInfo.HowNet):

E-mail to:
  [e-mail]
bounced (Connection refused by emily13.berkeley.edu). The UseNet
WhitePages confirmed this person posted from that address, supplied the
human name "Pinghua Young", and showed a whole slew of other similar
addresses of the form pinghua@emily*.Berkeley.EDU where * is just about
any integer from 1 through 13. I tried several but none of them worked.
No other e-mail address was listed in the UseNet WhitePages. Then I
tried NetFind or something like that, specifying the location as
U.C.Berkeley and specifying the human name, and it came up with:
  SYSTEM: gandalf.berkeley.edu
        Login name: pinghua                     In real life: Pinghua Young
        Office: 762 Evans, 642-5398             Home phone: [phone]
        Directory: /lion/d/stud/pinghua         Shell: /bin/tcsh
        Last login Thu Dec 17 22:44 (PST) on ttyp2 from emily10.Berkeley
        No unread mail
        Plan:
        [greatest descent every morning around 8-9]
        [quadratic hill climbing every afternoon 6-7]
        [bhhh all other times]
  SYSTEM: emily10.Berkeley.edu
        Login name: pinghua                     In real life: Pinghua Young
        Office: 616 Evans, 643-5398             Home phone: [phone]
        Directory: /econ/f/econgrad/pinghua     Shell: /bin/tcsh
        Last login Wed Mar 24 17:58 (PST) on ttyp1 from econnet.Berkeley
        New mail received Mon Mar 29 17:06:35 1993;
          unread since Thu Mar 25 11:51:12 1993
        Project: Working For Professor McFadden on Income Dynamics
Using that first entry, I tried e-mail to:
  [e-mail]
and indeed it worked, and I finally could re-send my bounce there.


% When you can't find any alternate addresses (or all alternates are
within a single domain), and that whole domain seems screwed up (you
can't seem to reach Postmaster at any of the hosts), use InterNIC WHOIS
(or NIC.DDN.MIL WHOIS if it's a DDN domain) to find out who the domain
contacts are (technical, administrative, etc.), and ask one of those
contacts for advice:

My e-mail to:
  [e-mail]
bounced (Host wrdis01.af.mil not found for mailer ddn). Via UseNet
WhitePages I found the human name was Steven G. Berman, but there were
no alternate e-mail addresses listed for that person. Even Berkeley
Netinfo ANY wrdis01.af.mil just hung and timed out instead of providing
information. So I connected to the NIC.DDN.MIL WHOIS service and asked:
  WHOIS wrdis01.af.mil
which told me this was the Air Force Logistics Command, and the
Coordinator was Skelton, Mark A. with this e-mail address:
  [e-mail]
so I asked him and he suggested:
  [e-mail]
which worked fine. (I suppose once I knew the e-mail address of the
domain contact, I might have just guessed that the original host name
was wrong and should have been the same as the domain coordinator, but
I didn't make that guess that time.)


% For Eastern-European domains, ask an expert on that region:

My e-mail to this address:
  [e-mail]
bounced (Host unknown), and my normal methods for tracking down the
correct address failed, so finally I asked an expert on that domain:
  [e-mail]
who told me the correct e-mail address was:
  [e-mail]

Another very difficult case was this address:
  [e-mail]
which bounced (Host gst.kiev.ua not found for mailer ddn), and I spent
a very long time trying different methods to track down the correct
person, until finally I found an expert (probably the same one as
above) who told me to try:
  [e-mail]
which indeed worked.

Yet another: E-mail to:
  [e-mail]
bounced (Host unknown), so I took a chance and asked [e-mail]
who claimed only to be an expert on the .ua domain, not they nearby .by
domain, but he was able to help me anyway by suggesting:
  [e-mail]
which worked just fine. I see a pattern with the first and third
examples here, and I would now almost suggest a standard fixup for
these two domains of converting @ to % and appending @ussr.eu.net (i.e.
making an Internet path through ussr.eu.net), and if that works we've
saved this very nice expert from having to handle one more case just
like the others and eventually getting tired.


% Sometimes the clue you need is in the bounce message (non-delivery
notification) itself:

E-mail to:
  [e-mail]
bounced (not a sufficiently clear match), but inside the text of the
non-delivery notification were a couple of partial-match addresses, one
of which was correct:
  [e-mail]
As it turned out upon communication with that person, he had an old address:
  [e-mail]
which apparently permitted the fuzzy match (ignore the trailing plus
sign, and equate lower case ell with digit one, but I'm not really
sure) even that address might no longer be valid, but his preferred
address is now:
  [e-mail]
which indeed also worked.

E-mail to:
  [e-mail]
bounced (421 springfield.SFSU.EDU does not accept mail--try
futon.SFSU.EDU instead), so I immediately tried:
  [e-mail]
and it worked fine, much to my surprise!


% If you actually succeed in reaching the desired host, but the user
can't be reached there, and you have no other good leads, ask the
Postmaster on that same host for help:

E-mail to:
  [e-mail]
bounced (550 User '[e-mail]' is not a registered gateway
user), so I asked the postmaster:
  [e-mail]
who was very nice, not only explained something was mis-configured
there, but offered to forward my e-mail for me until the
mis-configuration could be fixed. Later that postmaster thanked me,
because it turned out the same problem affected several other users and
I was the first to tell him about the problem so that he could fix it.
But beware, not all postmasters are as nice, and some don't answer
their e-mail at all if it's a query about how to reach some particular
user. (Disclaimer: I don't actually know the gender of that postmaster,
so "he" could refer to either gender here.)

E-mail to:
  [e-mail]
bounced (Microsoft Mail rejected recipient: BTAYLOR), so I asked:
  [e-mail]
who gave me the correct address:
  [e-mail]

Somebody at WesTech gave me his e-mail address, or so he said, so I tried:
  [e-mail]
but it bounced (User unknown), so I asked the Postmaster, who suggested:
  [e-mail]
which worked ok. Apparently the person I originally spoke to didn't
know the correct spelling of the person he was pretending to be. (I
think his spelling error blew his cover. :-)

Note that many postmasters won't (or can't) give you the correct e-mail
address until you supply the human-name, so for best results you should
first consult the UseNet WhitePages to find out the human-name that was
associated with that e-mail address when some UseNet article was
posted, then tell the Postmaster both the original e-mail address that
failed and that human-name associated with it.

My e-mail to:
  [e-mail]
bounced (User unknown), and after some attempts at contacting
postmasters I finally reached:
  [e-mail]
who told me there was no such person there, but later after I checked
the UseNet WhitePages and found the person's name was Dennis Tetreault,
and sent a second query including that name, the postmaster found this
address:
  [e-mail]
which worked ok.

Now here's a really weird example. E-mail to:
  [e-mail]
bounced (too many hops), so for no good reason I sent a query to:
  [e-mail]
which should have bounced too, but not only did it NOT bounce, and
actually get delivered to the postmaster on that host, but the
postmaster turned out to be the very same person I had originally tried
to contact! Sometimes when all reasonable methods fail, try some method
that seems unreasonable and you might get lucky!

Here's another very similar example: E-mail to:
  [e-mail]
bounced (sendall: too many hops (30 max)). Again for no good reason I
sent a query to:
  [e-mail]
and again to my amazement it didn't bounce. I got a reply from
[e-mail] (Mike Butry) who suggested:
  [e-mail]
and indeed that address worked fine.

Finally, sometimes you get authoritative bad news. The address:
   [e-mail]
for Don Knuth, the famous computer programming author, which used to
work before, stopped working, started bouncing (No such user), so I
sent a query to:
  [e-mail]
and got back the word that he no longer has a net mailbox because he
doesn't want to read email any more because it takes his time away from
writing books.


% Serendipity: discovering somebody related to person you want to
contact, or getting lucky in other ways:

E-mail to:
  [e-mail]
bounced (Host Unknown), and by using the UseNet WhitePages I discovered
his last name was "Kandappan", and there was somebody else with the
same last name:
  [e-mail]
who happened to be the original person's brother, who of course knew
the original person's e-mail address:
  [e-mail]
  [e-mail]
both of which worked fine.

E-mail to:
  AFriesen:CRF:[e-mail]
bounced (Failed to locate the following recipients: AFriesen:CRF:Bull).
I contacted a nearby postmaster:
  [e-mail] = [e-mail]
who suggested:
  [e-mail] (Friesen, Oris D.)
who turned out to be the brother of the person I wanted to contact, but
he then told me the correct e-mail address of the original person:
  [e-mail] (Correct person, "Aric", according to Oris)

E-mail to:
  [e-mail]
bounced (Host tsd.arlut.utexas.edu not found ...), and all my attempts
to find a more correct address also failed:
  [e-mail] (Host unknown)
  [e-mail] (Host arlut.utexas.edu not found ...)
  [e-mail] (Never got reply to my two test msgs)
  [e-mail] (Connection refused)
  [e-mail] (Never got reply to my two test msgs)
  [e-mail] (Never got reply to my query)
Meanwhile another apparently unrelated address:
  [e-mail]
also bounced, and when I asked [e-mail] for help I was
told to try:
  [e-mail]
and indeed it worked, so now I had a correction for this second
address, "unrelated" to the earlier group. In the course of tracking
down the addresses using the UseNet WhitePages, I found one of these
people was named Larry Maturo and the other was named Lawrence R.
Maturo, but I had over 600k bytes in my database (just a large and
growing text file, now divided into six actual files by alphabetical
order, with these two searches not in the same file) so I didn't happen
to see the two in close proximity. Still that name seemed SO very
familiar as I kept seeing it, and one day when I was scanning this
database trying to clean up some loose ends I happened to see the
records of the two searches just a few hours apart and they connected
in my mind. I searched all six files and found the two similar names in
different files, then asked [e-mail] if he was the same
person as [e-mail], and indeed he was, so finally the
original case was solved.


% Posting a query to the original newsgroup where the person originally
posted, or to soc.net-people, or to info.nets or bit.listserv.help-net
or news.newusers.questions etc.:

I tried to reply to an article on alt.hackers, to the address:
  otis![e-mail]
but that address bounced and all my normal attempts to track down the
correct address failed. As a last resort I posted a query to
alt.hackers and somebody sent me a correct address:
  [e-mail]
and somebody else sent me another correct address:
  [e-mail]

If you post to info.nets, be sure to include the complete text of the
original bounce you got (except for the body of the message you tried
to send; include header of bounce, explanatory text in bounce, and
header of your original message that was included), otherwise you'll
get complaints from somebody that you should have included it if you
expect anybody to help you.

Note that even if you have exhausted all other leads and have no other
way to discover the correct e-mail address, and included the necessary
information to let somebody help you, when you post your query to a
newsgroup you may get a few complaints (or even 'flames') about wasting
network bandwidth etc. So don't do this until you're really sure you
are at a loss for any other idea how to find out the correct e-mail
address, then tolerate the flames you will get. (I have a great idea:
Keep a list of all the people who flame you for using this absolute
last resort, then whenever you get stuck in the future send private
e-mail to just these flamers asking them to personally help you so you
won't have to post to the whole newsgroup! :-) Update 93.B.24: I tried
that after getting flames from three people: One of them helped me, one
of them refused to help me, and the third one (at IBM.Com) isn't
registered for e-mail from non-IBM sites so there's no way to contact
him except by posting a private message for him to the whole newsgroup
which would defeat the whole purpose of contacting him privately
instead of posting to the newsgroup!


% The original "bad" address starts working again:

I tried to send e-mail to:
  [e-mail]
but on two different occasions my e-mail bounced. I tried tracking down
other addresses, all of which also failed, except one address that
reached a different person by the same name (Jeff Linder). I tried
asking network experts, and some of them referred me back to the
original address which by now was working again. If I had just set up
an automated script to re-send a test message over and over, I might
have accumulated a large file of bounces, but I would have discovered
that address working again without bothering anyone. But in most cases
banging away at a non-working address is just an exercise in futility,
better to try to discover another address that works more reliably. But
in this case, there is no other valid address for this person, so
stupidly banging away at the non-working address WOULD have been the
best approach if only I were omniscient. This is the "exception that
proves the rule", as they say.


%% COMPLETE case histories showing how much work it took to finally
track down the correct address, and how many false leads were pursued
along the way:


The original address that bounced (unknown host) was:
  [e-mail]
I was able to confirm that address, and get the human name as "Gordon
Burditt", but no alternate addresses. I tried:
  [e-mail]
but that bounced (Host lonestar.org not found for mailer ddn). I also
tried that address indirectly:
  [e-mail]
but that bounced too (delivery attempts have failed for 5 days, Network
name lookup failed) Searching the UseNet WhitePages for "lonestar" to
find other users on the same host turned up:
  [e-mail] (E. Perkins) (Jul 1 92)
So I decided to see if I could find another address for that person,
then once I was in contact with that other user, ask the other user how
to get e-mail to the original person. I asked the UseNet WhitePages for
the keyword "Perkins" and got back:
  Gordon O. Perkins <[e-mail]> (Oct 21 92)
but that didn't help any. Then quite by accident I discovered on
alt.privacy an article with return path:
  btr!sgiblab!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!
      news.oc.com!utacfd.uta.edu!rwsys!sneaky!gordon
so if I truncate everything before the last DNS format name, and then
insert one of our UUCP neighbors at the start, I got:
  decwrl!utacfd.uta.edu!rwsys!sneaky!gordon
and indeed that address actually worked and I was able to finally
re-send what had bounced originally. But by that time (1992.Dec.20) BTR
was directly on InterNet, and shortly after I established communication
with that last address, the original address started working.


The address that originally bounced (Host Unknown) was:
  [e-mail]
Somehow I discovered this was also a UUCP host, and asked Berkeley
NetInfo for a UPATH, and got:
  romed!wierius!isus![e-mail]
but e-mail there bounced (unknown mailer error 1). I contacted the
[e-mail], and got a reply that romed hasn't been
calling in to get its mail, so I should find an alternate route. I did
further investigations via Berkeley NetInfo UPATH, and got a whole
bunch more incorrect information (paths that don't work because romed
doesn't call in nowadays):
  UPATH wierius -- romed!wierius![e-mail]
  UPATH romed -- romed![e-mail]
  UPATH espeng -- romed!wierius!espeng![e-mail]
  UPATH tempeaz -- romed!wierius!tempeaz![e-mail]
  UPATH migrant -- romed!wierius!migrant![e-mail]
I also checked UHOST of some of those hosts, and found that gedphx was
a neighbor to wierius, and that there was another path to gedphx not
involving romed or eddie.mit.edu:
  UPATH gedphx -- asuvax!gedphx![e-mail]
so then I concocted the following path:
  asuvax!gedphx!wierius!isus![e-mail]
and that path succeeded in reaching the intended recipient, so I was
able to re-send my bounces there 1992.Jun.22. Once we had established
communication, he said this address was his new correct address:
  [e-mail]
and indeed that worked too (verified 1993.Mar.17). Meanwhile, I
reported the faulty UPATH data to [e-mail] on
1992.Jun.22, and on 93.Feb.24 when I re-checked it all the bad data was
gone, some replaced by apparently-good data as below:
  UPATH isus -- crash!telesys!isus![e-mail]
  UPATH romed -- romed![e-mail]


The address that originally bounced (Host tsd.arlut.utexas.edu not
found for mailer ddn) was:
  [e-mail]
I tried this address:
  [e-mail]
but it bounced too (Host arlut.utexas.edu not found for mailer ddn). I
checked with Berkeley NetInfo ANY, and found neither
tsd.arlut.utexas.edu nor arlut.utexas.edu is a valid host name, but
utexas.edu is valid. Somewhere about this time,
[e-mail] (Brock L. Myers) suggested their host
may have crashed due to virus. Also, some query with the UseNet
WhitePages showed the person's name was "Larry Maturo". I asked the
[e-mail], but my queries of 1992.Dec.27 & 1993.Feb.11 were
not answered, finally my query of 1993.Mar.18 was answered by Jeff
Hayward <[e-mail]>, but he doesn't know. I queried the
UseNet WhitePages for "Maturo" but didn't get any new information. I
was at a dead end, so on May.02 I posted a query back to the newsgroup
where this originated, misc.jobs.misc. [e-mail] (Freddie
Akeroyd) and [e-mail] (Richard Furuta) suggested:
  [e-mail]
but my test messages May.11 and May.28 were never answered. La Monte H
Yarroll <[e-mail]> suggested:
  [e-mail]
but my test message May.17 bounced, Connection refused by
seagull.tsd.arlut.utexas.edu. La Monte also suggested:
  [e-mail]
but my test messages May.17 and May.28 were never answered. La Monte
also suggested asking:
  [e-mail]
but my query May.18 was never answered.

Meanwhile, e-mail to:
  [e-mail]
had bounced (worldlink.com says: unknown mailer error 7). Checking with
the UseNet WhitePages on 1993.Apr.24 showed that person's name was
"Lawrence R. Maturo", which sounded familiar but I didn't connect with
the other record, and even if I had it wouldn't have done any good
because both were bounces not yet fixed. Anyway, I asked
[e-mail] on 1993.Apr.24, got back this suggestion:
  [e-mail]
I sent a test message there 1993.Apr.30, which was ack'd, so I was able
to re-send that bounce 1993.May.12.

Finally one day that name "Maturo" got so familiar I did a search of
all six files (about 600k bytes total) to see where all that word
occurred, and I found the two separate entries above. "Larry" and
"Lawrence" are not exactly the same name, and the middle initial of one
tends to indicate it's another person with similar name trying
desperately to distinguish himself from the other to avoid people
getting the two of them mixed up on the net, but the last name is
rather uncommon, and I was pretty desperate by this point, so on May.28
I decided to go ahead and ask the one I had succeeded in contacting
whether he was the same person as the other, and it turned out he was
in fact the same person, and as I update this document 1993.Jun.01 I
have already re-sent the first of the [e-mail]
bounces to [e-mail] and will be re-sending the rest during
the next week or so if I don't get back an "OOPS" message (like if he
thought he was the same person but in fact was a different person).


The address that originally bounced (Host gst.kiev.ua not found for
mailer ddn) was:
  [e-mail]
I tried truncating the address:
  [e-mail]
but that bounced too (Host kiev.ua not found for mailer ddn). Then I
tried asking the UseNet WhitePages for the keyword "oleg" which I
thought was a very uncommon name. Well, that turned up:
  [e-mail] (Oleg N. Panchenko) (Dec 12 91)
(Test msg Jan.13 bounced, Host iitkh.kharkov.ua not found ...)
  [e-mail] ("Oleg B. Grinchuk") (Jun 11 92)
(Test msg Jan.13 bounced, Hops count exeeded 20) Next I tried asking:
  [e-mail]
and got back a reply from Igor Sviridov <[e-mail]>
<[e-mail]> <[e-mail]> <fido: 2:463/30>,
including offer to help with other .ua addresses that give trouble. One
of the suggestions from here or some other postmaster was:
  [e-mail] (For Oleg B. Grinchuk)
Although my test message there was ack'd, it didn't sound like correct
person, suggested it might be [e-mail] (Oleh Voloshchuk).
The same postmaster also suggested:
  [e-mail] (For Oleg B. Grinchuk)
but my test msg & query Feb.15, was never ack'd. The postmaster also
suggested:
  [e-mail]
but then the postmaster came back and said this host was disconnected
Feb.10, so use another address (below) instead. Being sufficiently
desperate I tried that address anyway, and indeed it bounced (Could not
find a route for a message to the following address:
[e-mail])
  [e-mail]
I sent a test msg here Feb.15, which was ack'd, but return adr
[e-mail]. I replied to find out if correct
person Feb.24, but never got an answer back. I also tried to auto-reply
to that return address:
  [e-mail]
but my reply bounced (554 batchmail died because of alarm clock
(14)--requeueing message). Another address suggested by one of these
people with similar name was:
  [e-mail]
I sent a test message there Mar.13, which was ack'd, but it's not the
same person I wanted to contact. On Apr.24 I asked the expert again,
who suggested:
  [e-mail]
My test msg Apr.30 was ack'd & confirmed, re-sent just one bounce
May.11, re-sent rest of bounces 93.5.13. In the ack, he said this was
his new address:
  [e-mail]
and indeed my test message of May.12 was ack'd.


%% Finally, here's a list of current stumpers, addresses that bounced,
for which I've already tried all reasonable methods of tracking down a
correction, yet still I haven't found a working address for these
people, where all the methods I've tried and all the help from the net
couldn't put Humpty Dumpty's e-mail address back together again, and my
bounced e-mail is still sitting in my FailNet-FixUps database not yet
re-sent, or I just gave up and flushed it. I give here just the
original address (or quick syntax fixup thereof) without the details.
If you happen to know a fixup for any of these, please let me know. If
you want to try your hand at investigating any of these yourself, send
me e-mail telling me which ones you'd like to try, and asking me the
current status of those particular ones, and I'll send you a copy of
the summary at the top of the corresponding record(s). Then if you want
you can also get the complete text of my original bounce (except the
message body) and of all later bounced test messages to alternate
addresses. The many bounces I'm currently actively investigating,
following leads, using the methods described above, where I haven't yet
reached a dead end, are NOT listed here, but will be appended here
after I reach a dead-end with them. Also some of the ones where I just
gave up and flushed the original bounce are not included here. In most
cases, only the dead-ends where I still have the original message and
still want to deliver it to the intended recipient, are listed here
(but some of those bounce messages may already have been flushed by the
time you see this, if I've changed my mind about keeping the message
forever trying to eventually deliver it):

[e-mail] (Anne Trimble Franusich) (May 11 92) (Anne
Franusich) (Mar 22 92) (Annie Franusich) (Apr 12 92)

[e-mail]

[e-mail]

glv!dave

[e-mail]

[e-mail]

filman@excelsior

[e-mail]

jmward@elbert (Joel M. Ward) (Apr 11 93)

[e-mail]

fernwood!bcars182!jwaustin (John Austin) (Nov 12 92)

[e-mail] (Karlo Yung)

uunet!sunspot!miki

[e-mail] (Randy King)

[e-mail] (Brett Rose)

[e-mail]

S_CHURCHHOY@UNHH (Referral from Cynthia Fish who unfortunately isn't in
Whitepages either)

[e-mail] (Tai-Sung Lee)

[e-mail]

ames!ncar!hsdndev!dartvax!northstar8![e-mail]

[e-mail]

Update 1993.Dec.15: Lately I've kept a list of FailNet experts. When
some bounce reaches the stumper point, I not only eventually copy the
address to the list above, but I start sending summaries of my attempts
for that particular stumper to a few random FailNet experts. Only after
several attempts to get help from these experts have all failed, do I
post to a newsgroup (the group where the original article appeared,
and/or a general network help group) asking the for anyone who can to
help. If you have been receiving these specific stumper requests for
help within the past couple weeks, you're already on the list. If not,
and you'd like to help me, let me know and I'll add you to the list.


%% Announcement (last updated 1993.Nov.05): I'm still unemployed, and
deep in debt, so if you can help me find employment please do so,
before my credit runs out and I can't pay the rent and we get evicted
and my little children (ages 3.6 and 1.8) have no home and have to live
in the streets with me. I help people on the net, answering questions
and writing these MaasInfo files, why can't somebody do a nice favor in
return and pay me money to work for them?? I get lots of "thank you"s,
but they don't pay the rent or get me out of debt.


%% End of MaasInfo.FailNet
.