NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/mail/misc/2939

Internet Message Format | 1992-09-08 | 3.4 KB

Xref: sparky comp.mail.misc:2939 comp.mail.headers:299
Newsgroups: comp.mail.misc,comp.mail.headers
Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!sgi!rhyolite!vjs
From: [e-mail] (Vernon Schryver)
Subject: Re: Return-Receipt-To: header reliable?
Message-ID: <[e-mail]>
Organization: Silicon Graphics, Inc.  Mountain View, CA
References: <dhuber.715611908@autmgr> <[e-mail]> <[e-mail]>
Date: Mon, 7 Sep 1992 17:43:19 GMT
Lines: 65

In article <[e-mail]>, [e-mail] (David J. Fiander) writes:
> According to [e-mail] (Vernon Schryver):
> >
> >A common use of Return-Receipt-To: is to debug mail transport
> >problems.  It is a little cleaner and easier than mailing to
> >"[e-mail]" or "<@remote.dom.ain:[e-mail]>",
> >when it works.
>
> Once again, you are assuming that a) the receiving site honours
> return-receipt-to, and b) that the information returned will be
> usefull for debugging purposes.  SCO MMDF return-receipts say
> something like:
>
>     Your message (message-id) was received by the following
>     users or their agents:
>
>         recipient
>         recipient
>
> The only way to reliably debug mail problems is to send mail to
> [e-mail] asking her to return your headers to
> you.


No, I'm not assuming "the receiving site honours return-receipt-to".
That's why I wrote "when it works."

The headers from the MMDF response can be useful.  You will at least
get a trace of the route from the remote machine back to yourself.
With that route, you can construct a full RFC-822 source route or UUCP
!-path to send yourself mail via the remote site or to force a bounce.
There can be problems with these techniques if your site has stupid
AT&T /bin/mail which rabidly reroutes locally originated mail, or if
there rabid rerouters or sites which to not add headers in the path.
However, those are often clues to the problem.

You can use these techniques to probe the relays to the target and to
try to ensure the problem is not yours, before making yourself a pain
in the neck and/or a public fool by complaining to humans.

Bothering postmasters of busy sites is not a bright idea, until you
have at least tried to investigate things yourself.  Even a medium
sized site such as sgi.com receives dozens of messages/day for
postmaster.  People who obviously have not done any thinking or
investigating for themselves and so appear unlikely to be of help in
resolving their complaint can get ignored, particularly if it seems
likely the problem is elsewhere or if things are busy.  It's not as if
mail transport problems are interesting after the first few thousand,
as if there will not always be more to investigate, or as if many are
not caused at the complaining site.

Mailing to postmaster at a gateway for a large network complaining
about an individual machine within that network is a good way to be
ignored.  I bet you won't get much satisfaction complaining to
[e-mail] about a random machine in dec.com.  I know
that [e-mail] doesn't pay more than minimal attention to
problems with the thousands of machines deep within the sgi.com
domains.

In other words, sending mail to postmasters is perhaps more reliable
than return-receipt-to, but it is less reliable than either generating
a bounce or sending a circular message.


Vernon Schryver,  [e-mail]