I'm not sure that the MLA returns a receipt on behalf of the ML members.
I looked through ESS again and I couldn't find anything that said if a
message enters an MLA with a signed receipt request that it shouldn't or
should return a receipt. Typically (I think), originators want to
know that the final recipient got the message not whether the MLA got it.
Then again maybe I didn't understand your scenario.
Graeme Lunt wrote:
We have recently encountered an issue when trying to correlate signed
receipts when using mail lists.
When a MLA supports multiple lists using a single public/private key
pair, it appears that there is insufficient information within a signed
receipt generated by the MLA to determine to which recipient the signed
Take the case where a message is sent to two recipients, R1 and R2, and
the user makes an "all" signed receipt request.
R1 is actually a Mail List supported by an MLA using a single
public/private key pair, MLA1.
MLA1 receives the message for R1, expands the list, and sends a signed
receipt "on behalf of" R1 back to the originator.
The originator can identify the message to which the signed receipt
relates (from the signedContentIdentifier) but not the recipient as the
signature on the receipt is from MLA1. There is no way to relate this
receipt to either R1 or R2.
One way to resolve this problem would be to add an extension to the
Receipt syntax to include
receiptFrom GeneralNames OPTIONAL
This field would allow the indication of whom the signed receipt was
sent from and consequently correlation with the original recipient list.
This also allows other scenarios where a third party may acknowledge
receipt for a given recipient for example an assistant reading a
This functionality is comparable to that of the "IPM Intended Recipient"
field of an X.400 IPN.
Also, if considering changing the Receipt structure it may be worthwhile
adding an extension bucket at the same time (or even to support
Am I missing something?