> A little while ago we had a discussion about this subject here and the
> advisability and feasibility of implementing such a feature in Exim.
>
> It turns out that Exim supports it already! It apparently isn't up to
> the server to support mail receipt confirmation, but up to the MUA. And
> the new Netscape Messenger _does_ support it by simply sending a
> standard receipt message back to the original sender. Exim doesn't have
> to do anything but deliver the confirmation. So that one's finally out
> of the world.
That depends upon exactly which type of 'receipt confirmation' you
are talking about. The classic form, implemented by some versions
of Sendmail using the non-standard 'Return-Receipt-To:' header,
sends a receipt message when the original message is placed into
the user's mailbox. This MUST be done by the Mail Delivery Agent
or by the final Mail Transfer Agent when initiating final delivery.
The second kind sends a receipt when the mail is -read-, and must
be done by the Mail User Agent. (I'm not sure what it should do
if the message is deleted unread. A case could certainly be made
for sending a receipt message with modified text to indicate the
deletion.)
The third kind is a compromise between the two; where the MUA sends
the receipt when it first finds the message in the mailbox and displays
it in the list of new/unread messages.
Exim supports the later two, because they don't require any explicit
action from the MTA. Supporting Return-Receipt-To: is something of
a religious issue. If support is added to Exim; it should be configurable,
and OFF by default. Actually, I'd want three possible settings: OFF,
ON, and 'only when the envelope expands to a single recipient.'. And
even then, I'd still keep the headers_remove that prunes it out before
it can reach a majordomo list.
-Pat
--
*** Exim information can be found at
http://www.exim.org/ ***
