🚀 go-pugleaf

In article <1992Dec31.175537.22573@chance.gts.org> john@chance.gts.org (John R MacMillan) wrote:
>|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.

On what mathematical analysis or statistical evidence do you base that assertion?

>|	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.

Reliability to some destinations, and/or via some intermediate sites, is
quite poor.

>|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.

I've seen it happen, more than once (smail does this).

>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.

In the case of sendmail, which is where Return-Receipt-To originated,
the receipt is only sent if the mailer definition is flagged as a mailer
that performs final delivery.

>|	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.

RFC1123 section 5.2.8 clearly states (for Internet sites using SMTP) that
every SMTP receiver that handles the message MUST insert a Received
header. The same section of the same RFC also states that ALL Internet
mail programs MUST refrain from changing any pre-existing Received header.

In the case of mail transmitted via UUCP using rmail in compliance with
RFC976 the route information is encapsulated in the "From " line(s).

If some intermediate site runs broken (i.e. non-RFC-compliant) mail
software, I still have at least partial route information.

>|	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.

In the case of Internet mail, the delay may indicate nameserver or machine
load problems.  The delay for UUCP site is not entirely random.

>|	[additional information might be obtained from the return
[...]
>
>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.

I never claimed that that other information, mentioned in a sidebar, was
useful as an indication of receipt.  Why are you trying to put words into my
mouth?

>|	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, 

If it didn't leave my site, but I did get a return receipt, it means that
the message was delivered to mail-handling software locally, i.e. it went
somewhere.

> [...]
>g) how long that may have taken.

I *know* *exactly* how long it took, since i *know* *exactly* when the
original message was sent, and i *know* *exactly* when the return receipt
was received.

>|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.

``the return receipt was lost'' is a special case of ``something went awry''.
(indeed, ``the MTA was changed'' could be considered another special case :-)

>|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.

Sounds more like you were trying to twist the previous poster's wording
around to suit your own preconceived notions.

As long as you're going to be pedantic, ``failure to receive a bounce'' is no
indication (of successful delivery) at all.

>|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.

In the case of non-receipt of a bounce (over what time interval?--forever?[*]),
there are many possible reasons why one might not have received a bounce
message, some of which I have enumerated.

In the case of receipt of a return receipt, there must have been a working
path to an MTA which does acknowledge return-receipt-to, *and* there must
have been a working path back to the originator.

To put it somewhat more succintly:
Non-receipt of a bounce can result from a multitude of conditions, only one
of which is "successful delivery to the intended recipient", taken singly or
in combination.
Receipt of a return receipt results only from fulfillment of all of several
specific conditions; the failure of any one of those conditions to be
satisfied will result in the return receipt not being received.

It is true that neither non-receipt of a bounce nor receipt of a return
receipt provides a 100% guarantee that the message was received by the
recipient (such a guarantee may well be impossible to provide), but it is
certainly *not* true, as you have asserted, that non-receipt of a bounce
carries the same information regarding mail delivery as does positive
receipt of a return receipt.

[*] 	I just sent a message two seconds ago. Well I didn't receive a
bounce message yet, so according to MacMillan that means that the message
has probably already been successfully delivered to the correct recipient.

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce