🚀 go-pugleaf

Warner Losh writes:
> The biggest question about Return-Receipt-To: is what to do when a
> nieve user sends mail to a mailing list with this header in it.
This opens another can of worms.
There is a lot of automated software that can be broken by mailing lists.
What would be nice is an RFC for mailing lists.
Something that could describe the behavior of the list management
software (such as how it deals with "Return-Receipt-To:"), header
definitions (such as "Listname:" to identify the list(s) ), and some
facilities to ease the integration of mailing lists into news systems.

> It would be critical that mailing lists and such filter out 
> Return-Receipt-To:.  
The list management software should acknowledge the receipt of the message
by sending an appropriate notice, and then remove the
"Return-Receipt-To:" header before forwarding the message.

> Return-Receipt-To is a dangerous header as it stands now.  If its use
> is to be standardized, its meaning much change :-)
The temptation is there to try and use what already exists to some extent,
but there appears to be a lot of interest in something with more
functionality.

Perhaps the existing functionality of sendmail's "Return-Receipt-To:"
should be captured in an RFC, but then the idea should be extended to also
include a "Read-Receipt-To:" header (or equivalent) for the MUA. This new
header could then include added features (such as dealing with multiple
recipients).

As to the issue of whether "Return-Receipt-To:" has any value: yes, it
will be less meaningful until it is standardized and becomes ubiquitous.
But isn't that always the case with protocols?

What should happen when crossing a gateway, and there is no equivalent to
a "Return-Receipt-To:" or "Read-Receipt-To:" on the other side? Should the
gateway send an appropriate message?

 -Tom

tmetro@lynx.dac.northeastern.edu