On Fri, 9 Mar 2001, Phil Pennock wrote:
> Is this an "implementing it because of lost data, since that's been
> discarded by now" or "deciding what applies"? Going on the basis of
> what you said in:
> <http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-19981116/010062.html>
> the only issue not covered in 6.2.7 of RFC 1891 is privacy of forwarded
> addresses, which could be a user-controlled toggle.
It's not only the privacy issue. It's the "what constitutes a delivery"
issue.
I have no problem with implementing (optionally, of course, because only
some people want it) a different format for bounce messages, other than
the problem of finding time and prioritizing.
> Whilst I don't know for _sure_, <http://www.postfix.org/bounce.8.html>
> claims to conform to RFC 1894, so I don't think that is true.
I think it's 1891 that contains the stuff that people object to.
Unfortunately, the word "DSN" is used cover both this stuff (requesting
notification for successful delivery etc) as well as the format of
bounce messages.
> I certainly don't wish to see SUCCESS or RELAYED implemented, or if they
> are I'd pay money to have them configurable to be disabled. :^)
Good. This means there is no real serious disagreement in this thread,
as far as I can tell.
On Fri, 9 Mar 2001, Jeffrey Goldberg wrote:
> But it is the general use for checking that a message has been delivered
> that I find objectionable.
And I find it hard to define "delivered". The problem is, the lawyers
want this, so it will keep cropping up. They are mad, of course. How can
you define "delivered" with the same degree of consistency as a human
law enforcer putting a legal document into the hands of the recipient?
> (1) First, it will never be reliable, due to difficulty in defining
> "delivery", and for non-uniform implementation. There will be
> far too many false positives and false negatives.
>
> (2) If it is not highly relieble (see (1)) it is quiet probably worse
> than useless.
>
> (3) It can nearly double the number of messages transmitted, while
> being useless in terms of informativeness.
Absolutely.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
