4.4) When All Else Fails - Bounced Email
Description
This article is from the AmigaUUCP
FAQ, by Marc SCHAEFER,
4.4) When All Else Fails - Bounced Email
email will bounce for a variety of reasons. The fact that the global email system is made up of so many different types of mail systems causes lots of havoc... in many cases a system will munge the path you attempt to send email through by misinterpreting it or by attempting to 'optimize' it.
When all else fails, and your attempt to reply to a piece of email bounces, you may have to construct the return address by hand. Several possibilities come to mind. You want to use the 'h' command from dmail to look at the actual mail headers (use dmail's help command to get full info on the header command).
You want to look at both the original message that was sent to you, and the headers of your BOUNCED reply.
-------- SAMPLE OF ORIGINAL MESSAGE -------
From uunet!SASK.USask.CA!telepro!oliphant Fri, 28 Dec 90 13:04:57 PST
Received: by overload.Berkeley.CA.US (V1.07/Amiga)
id AA00000; Fri, 28 Dec 90 13:04:57 PST
Received: from sask.usask.ca by uunet.UU.NET (5.61/1.14) with SMTP
id AA22874; Fri, 28 Dec 90 01:30:48 -0500
Received: from herald.USask.Ca by SASK.USask.CA with PMDF#10255; Fri, 28 Dec
1990 00:30 CST
Received: by herald.USask.Ca (5.57/GLH-1.0); Fri, 28 Dec 90 00:30:06 -0600 id
AA01058 for amiga-uucp-patches-request@overload.berkeley.ca.us
Received: by telepro.UUCP (1.05D/Amiga) id AA04612; Thu, 27 Dec 90 21:25:00 CST
Date: Thu, 27 Dec 90 21:25:00 CST
Message-Id: <9012280325.AA04612@telepro.UUCP>
X-Envelope-To: amiga-uucp-patches-request@overload.berkeley.ca.us
From: uunet!SASK.USask.CA!telepro!oliphant (Mike Oliphant)
To: amyuucp@sask.usask.ca
Subject: Mailing list
Please add me to amiga-uucp-patches.
Thanks.
--
Mike Oliphant UUCP: alberta!herald!telepro!oliphant
Internet: oliphant@telepro.uucp
-------- ADDRESS I SENT MY RESPONSE TO ------
uunet!SASK.USask.CA!telepro!oliphant
-------- SAMPLE OF BOUNCE THAT CAME BACK TO ME -------
From uunet!sask.usask.ca!postmaster Mon, 31 Dec 90 01:02:30 PST
Received: by overload.Berkeley.CA.US (V1.07/Amiga)
id AA00000; Mon, 31 Dec 90 01:02:30 PST
Received: from sask.usask.ca by uunet.UU.NET (5.61/1.14) with SMTP
id AA13985; Sat, 29 Dec 90 17:18:48 -0500
Date: Sat, 29 Dec 1990 16:18 CST
Message-Id: <B13C1C282040350C@SASK.USask.CA>
X-Envelope-To: overload!dillon@uunet.UU.NET
From: PMDF Mail Server <uunet!sask.usask.ca!Postmaster>
To: overload!dillon
Subject: Undeliverable mail: local delivery failure
The message could not be delivered to:
Addressee: telepro!oliphant
Reason:
%MAIL-E-LOGLINK, error creating network link to node TELEPRO
-SYSTEM-F-NOSUCHNODE, remote node is unknown
-------- END OF SAMPLE HEADERS --------------------
So, why did my response fail? First, I have to tell you something about mail headers: Except for Received: headers, intervening systems can and will turn the standard headers into mush. That is, the 'From ' encapsulation, the From: header, the To: header, even the Reply-To: header might be modified by an intervening system.
There are only two things that are not mushed. They are the Received: headers and the mail message itself - which might contain the sender's signature at the end. This is a good reason to always put your email address in your signature, and always base it at a known internet node so anybody can figure out how to get back to you.
A Received: header is PREPENDED by *EVERY* site a piece of email goes through, and is NEVER modified by any other site. These headers tell you *exactly* how the mail was routed.
If you look at the original message, you will note that one of the machines, probably SASK.USask.CA, modified the From: line in an attempt to optimize it:
From: uunet!SASK.USask.CA!telepro!oliphant (Mike Oliphant)
Note that, by the From: line, SASK.USask.CA talks directly to telepro. The 'From ' encapsulation was also modified, and there is no Reply-To: header.
When I sent my reply to SASK using From:, the mail bounced because SASK was unable to find telepro ... if you look at the Received: lines you can see why ... because telepro talked to Herald before getting to Sask. It is amusing because SASK is probably the node that ripped out Herald's name in the From: and 'From ' lines in the first place.
Also, take a look at Mike's signature line:
Mike Oliphant UUCP: alberta!herald!telepro!oliphant Internet: oliphant@telepro.uucp
Interesting, eh? The Internet: address is actually wrong (sorry Mike!) using .UUCP is not legal because it is not a proper domain. However, if you forward through an internet host that also uses the UUCP MAPS, and assuming mike is in the maps, the address *will* work.
It's the first address that confirms our fears... mike shows telepro talking to herald. This combined with the knowledge we gained from the Received: lines tells us that the path:
SASK.USask.CA!herald!telepro!oliphant
Will work as a return address. When in doubt, trace the Received: headers to determine the return path.
Sometimes a UUCP MAP entry will be incorrect, in which case using the Received: headers will be the ONLY way to reply to a message.
There are some situations which are impossible to reply to ... if a message goes through a broken node that allows it to be propogated one way but not the other, even using the headers will not work.
Also, some sites will attempt to optimize the path you specified. If SASK.USask.CA were to optimize the path:
SASK.USask.CA!herald!telepro!oliphant
To
SASK.USask.CA!telepro!oliphant
Before processing, the mail could fail due to SASK.USask.CA breaking itself. There are many nodes, especially gateways between networks, that are broken in this manner and there will be times when you will not be able to reply at all.
Continue to:
My Books
