graphMessage.IsReadReceiptRequested (bool) is not following the official RFC 3798 standards | Disposition-Notification-To Header

[sora-1337]

Describe the bug
When creating a graphMessage (Message),
the isReadReceiptRequested Property is insufficient per the RFC 3798 standard.
I would expect a List or any other Datatype for holding a DisplayName:EmailAddress combination.

Contrary to the expected RFC standard, it simply sets a boolean to true and internally parses the Sender (From) into the Disposition-Notification-To. This is insufficient and unpredicted behaviour.

In the case that you need to set a different Recipient (List) than the Sender, you are completely unable to.

For example: You use a service mail slave to send all of your companies mails, but your marketing team needs to be notified if their part of the mails are opened by customers. Setting the Recipient to the Sender here, is pointless, because your mail slaves' Inbox will surely not be able to be accessed by anybody except Sys Admins and Developers.

To Reproduce
Steps to reproduce the behavior:

var graphMessage = new Message {
IsReadReceiptRequested = true
};

Expected behavior
The graphMessage needs to offer an additional parameter for an alternative List for the actual people that are interested in Read Receipts. like:

var graphMessage = new Message {
IsReadReceiptRequested = false, // do not send the Sender a ReadReceipt (to minimize Service Inbox traffic)
ReadConfirmationTargets = new List<Recipient> { .... } // additional / alternative ReadReceipt Recipients
};

The way my custom Email Client Library handles this case is like this, feel free to copy paste from this:

// Disposition Header Assembly
List<Recipient> dispositionList = new List<Recipient>();

if (requestReadConfirmation == true)
{
    // Add Sender(s) to Read Confirmation
    dispositionList.AddRange(FromRecipient);
}

if (ReadConfirmationTargets?.Any() == true)
{
    // Add Additional Read Confirmation Targets
    foreach (Recipient recipient in ReadConfirmationTargets)
    {
        if (!dispositionList.Contains(recipient))
        {
            if(recipient.Address.Trim() == "")
            {
                throw new InvalidRecipientException("Invalid ReadConfirmationTargets: One or more of your email addresses in the ReadConfirmationTargets is empty.");
            }
            dispositionList.Add(recipient);
        }
    }
}

Screenshots

Desktop (please complete the following information):

• OS: any that support dotnet SDK
• Browser: any
• Version: all dotnet Graph Libraries up to 9.8.2023

Smartphone (please complete the following information):

• Device: /
• OS: /
• Browser: /
• Version: /

Additional context
RFC Reference: https://datatracker.ietf.org/doc/html/rfc3798#section-2.1

[andrueastman]

Thanks for raising this @beggarboy

As this really is API side functionality, and this repository is mainly intended for SDK related issues. Any chance you can post the issue at the link below so that the API owners may follow this up with regards to adding support for an additional parameter for an alternative List for the actual people that are interested in Read Receipts? It would be great if you could post back the link to the same here so that anyone who comes across this may find it as well.

https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/idb-p/Microsoft365DeveloperPlatform

[sora-1337]

Thank you very much for handing me to the right people @andrueastman,
cross posted here: https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/graphmessage-isreadreceiptrequested-bool-is-not-following-the/idi-p/3904169#M1926