> I would strongly protest adding any explicit support for a badly thought
> out and officially depreciated feature in exim - even sendmail doesn't
> support Return-Receipt-To: now.
I wouldn't call Return-Receipt-To: 'badly thought out'. Remember,
it's primary intent was to provide a mechanism for diagnosing delivery
problems. Over the last 15-20 years I've used it several times for
that purpose; and it has generally been quite helpful. (Back in the
days when the primary inter-host mail transport mechanism was uucp
over dial-up lines, Return-Receipt-To: was an extremely valuable aid
in determining where the major delays in delivery were occurring, and
when the connectivity tables hadn't been kept up to date to reflect
changes in connection frequency.)
However, I will concede that it is less useful today; and possibly
more prone to misuse. I haven't been following the recommendations
on receipts; but I would hope that a receipt-when-read-or-deleted
would contain the delivery timestamp as well as the read/delete time.
As the originator of a message, I control when it is sent, and can
have some reasonable expectation of when it will be delivered; but
I have no control over when, or if, it will be read. At times it is
nice to be able to assert, with some documentary backup, that my message
was delivered by a given time; and that if the recipient ignored it,
or is lying about having received it at all, it certainly isn't my fault.
(There have been times when I would have given quite a bit for separate
receipts indicating time of delivery, time of first appearance in the
user's MUA, and time read-or-deleted.)
On the other hand, a proliferation of receipts, no matter when issued,
could significantly increase mail bandwidth requirements. I know of
no proposals that satisfy both demands.
-Pat
--
*** Exim information can be found at
http://www.exim.org/ ***
