🚀 go-pugleaf

|Lack of a bounce message tells me nothing useful:
|	the message might have been delivered successfully to the
|		intended destination

By far the most likely of the possibilities.

|	In summary, I have no positive indication that the message
|	was delivered anywhere, and I have no indication that it
|	wasn't delivered.

Correct.  But since email today has pretty high reliability, your
message _probably_ got there okay.

|Receiving a bounce message tells me:
|	some site somewhere might have failed to pass on the message
|		(in fact, it may have forwarded the message)

It's highly unlikely that a bounce would be generated when indeed the
mail had been passed on.

But since you felt all the possibilities should be included, including
those that are very unlikely:

|A return receipt tells me:
|	the message was delivered to a specific system (the one that
|		sent the receipt), which attempted to perform final
|		delivery

Well, a system _claiming_ to be the one sent the receipt, but may or
may not have attempted to perform final delivery.

|	(obviously) the system that sent the return receipt does
|		acknowledge return-receipt-to

No, something generated the return receipt that time, but may not do
so in future or for other recipients at that site.

|	the route taken by the original message and by the return
|		receipt (via the Received headers)

By those MTAs that bothered to fill them in, and didn't munge existing
ones.

|	the amount of time elapsed between each hop of the original
|		message and the return receipt (again via Received
|		headers)

Which for internet sites is usually the difference between their
clocks, and for UUCP sites is, for a single sample, random.

|	[additional information might be obtained from the return
|		receipt's Received headers, including: the MTA
|		identity at each hop, the means of transfer between
|		MTAs, changes to the envelope address]

None of which relates to return receipts.  It may be useful for
debugging mail problems, but it's useless for telling if the recipient
got your mail.

|	In summary, I know a) that the message went somewhere, b) where
|	the message went, c) the route the message took, d) how long
|	the message took to reach the place to which it went, e) that
|	the MTA that sent a return receipt does in fact acknowledge
|	return-receipt-to, f) the route taken by the return receipt,
|	and g) how long the return receipt took to reach me.

a) you know it went somewhere if it left your site, b) you know where
it may have gotten to (but not stopped), c) and maybe partly how it
got there, d) some possible indication of the time, e) that something
generated a receipt this time, f) how the receipt may have come back,
g) how long that may have taken.

None of these tell you your mail got there.  Only b) tells you that
_maybe_ what you want happened.  So in summary, regarding the ultimate
disposition of your mail, it tells you that your mail _probably_ went
where it was intended.

|If I have previously established that the MTA for a recipient acknowledges
|return-receipt-to, and I do not receive a return receipt within a reasonable
|time period, I know that something went awry or the MTA was changed.

Or the return receipt was lost.  In other words, you don't know
anything definite about whether your mail got there.

|Isn't ``some degree of proof'' (the original wording, as you can see) the
|same as ``an indication''?

No.  ``Some degree of proof'' uses misleading wording (with a strong
word like ``proof'') to try and strengthen its own statement.  ``Some
degree of proof'' is not proof at all.  The original wording simply
underscores the problem with user expectation, and I was trying to
water it down.

|In any event, failure to receive a bounce and
|positive receipt of a return receipt clearly mean quite different things;
|see above.

They are certainly different, I have no argument with that, but in
terms of whether or not your mail was delivered as intended, they both
tell you that _probably_ your mail was delivered, but there is no
certainty.