🚀 go-pugleaf

In article <dhuber.715611908@autmgr> dhuber@autelca.ascom.ch (Daniel
Huber) writes:

:I just recommended a colleauge to enable the header Return-Receipt-To: for
:his outgoing international mail. However, we do not get all return receipts
:we would expect... 
:Is it possible to turn off Return-Receipt-To: replies? Or is the internet
:that unreliable?

Return-Receipt-To: is obeyed by sendmail and MTAs that want to act
like sendmail.  However, it's not part of any RFC that I'm aware of.

						...Mike
-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

According to dhuber@autelca.ascom.ch (Daniel Huber):
>I just recommended a colleauge to enable the header Return-Receipt-To: for
>his outgoing international mail. However, we do not get all return receipts
>we would expect... 
>Is it possible to turn off Return-Receipt-To: replies? Or is the internet
>that unreliable?

I hate to tell you this, but there is no such thing as a
return-receipt-to header.

Well, actually there is, but it was invented by the author of
sendmail, and only sendmail (and some versions of SCO MMDF)
support the the generation of return receipts.  So the only
time you will get a return receipt is when the recipient's
machine is running sendmail.

Of course, through judicious use of the .forward file and mail
filtering programs, the fact that you got a return receipt
doesn't mean anything any way, since the addressee may be
discarding mail from you unseen.

- David

In article <1992Sep05.124731.8552@golem.uucp>, davidf@golem.uucp (David J. Fiander) writes:
> According to dhuber@autelca.ascom.ch (Daniel Huber):
> >I just recommended a colleauge to enable the header Return-Receipt-To: for
> >his outgoing international mail. However, we do not get all return receipts
> >we would expect... 
> >Is it possible to turn off Return-Receipt-To: replies? Or is the internet
> >that unreliable?
> 
> I hate to tell you this, but there is no such thing as a
> return-receipt-to header.
> 
> Well, actually there is, but it was invented by the author of
> sendmail, and only sendmail (and some versions of SCO MMDF)
> support the the generation of return receipts.  So the only
> time you will get a return receipt is when the recipient's
> machine is running sendmail.
> 
> Of course, through judicious use of the .forward file and mail
> filtering programs, the fact that you got a return receipt
> doesn't mean anything any way, since the addressee may be
> discarding mail from you unseen.


A common use of Return-Receipt-To: is to debug mail transport
problems.  It is a little cleaner and easier than mailing to
"nosuchuser@remote.dom.ain" or "<@remote.dom.ain:myname@my.dom.ain>",
when it works.



Vernon Schryver,  vjs@sgi.com

According to vjs@rhyolite.wpd.sgi.com (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
>"nosuchuser@remote.dom.ain" or "<@remote.dom.ain:myname@my.dom.ain>",
>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
postmaster@remote.dom.ain asking her to return your headers to
you.

- David

In article <1992Sep07.153345.613@golem.uucp>, davidf@golem.uucp (David J. Fiander) writes:
> According to vjs@rhyolite.wpd.sgi.com (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
> >"nosuchuser@remote.dom.ain" or "<@remote.dom.ain:myname@my.dom.ain>",
> >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
> postmaster@remote.dom.ain 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
postmaster@decwrl.dec.com about a random machine in dec.com.  I know
that postmaster@sgi.com 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,  vjs@sgi.com

In article <1992Sep05.124731.8552@golem.uucp> davidf@golem.uucp (David
J. Fiander) writes:

:Well, actually there is, but it was invented by the author of
:sendmail, and only sendmail (and some versions of SCO MMDF)
:support the the generation of return receipts.  So the only

smail also supports Return-Receipt-To: headers.

						...Mike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

In article <Bu9B21.J2G@ef2007.efhd.ford.com> Mike O'Connor <mjo@fmsrl7.srl.ford.com> writes:
>In article <1992Sep05.124731.8552@golem.uucp> davidf@golem.uucp (David
>J. Fiander) writes:
>
>:Well, actually there is, but it was invented by the author of
>:sendmail, and only sendmail (and some versions of SCO MMDF)
>:support the the generation of return receipts.  So the only
>
>smail also supports Return-Receipt-To: headers.

Which smail?  Smail2.5 didn't, last I checked.  The official releases
of smail3.1 don't, although I believe that some unofficial patches are
filtering around that do this.
-- 
	tron |-<=>-|		ARPAnet:  veritas!tron@apple.com
      tron@veritas.com		UUCPnet:  {apple,pyramid}!veritas!tron