Shortly, DC using email protocols and there no standard mechanism that can utilize this feature.
If sender wants to get status you talking, then receiver device (receiving DC, - to be more precise) must send to sender info that device picked email from receiver’s IMAP folder.
TL;DR
When sender delivering message to sender’s MTA, this MTA either confirms that message accepted for delivery (stage where timer clock turns to single checkmark) or it can send non-delivery notification (It isn’t a fact that sender’s MTA would be able to deliver message to receiver’s MTA. In cases for example when recipient’s email address is malformed or filter on sender’s MTA reject to send to some destination or MTA can’t find receiver’s MX server from DNS and bunch of other cases when delivery on this stage may fail ).
Now let see what is going on receiver’s MTA. Receiver’s MTA is most weak part where a bunch of filters working to prevent spam, forging, abuse and etc. Receiver’s MTA may easily, silently reject reception or politely send back reason for rejection (4xx, 5xx errors).
Let see what’s going next, - if receivers’ MTA accepted email, it isn’t means that it passed to recipient’s INBOX 100% percents. Receiver’s MTA may mark accepted email as a SPAM/FORGED/INFECTED for example when it passing internally message to IMAP server and sieve(RFC5228) may reroute message to a different folder instead of INBOX. IMAP’s sieve may also apply additional filters that can reroute/discard accepted message and it won’t notify sender because IMAP don’t sending messages back to senders.
Ok, let say, we succeed and our message delivered to recipient’s INBOX. If there is connected devices to recipient’s IMAP server, then email client will pick received message (downloads to final recipient’s device) and on the server side message will be moved from “new” to “cur” folder.
That’s it. At this stage delivering email protocols have been done its job. Sender can’t know if receipient’s device downloaded or not yet a message you sent. To get a signal back that this stage was passed on recipient’s side, email client on recipient device should send CUSTOM email back, confirming what you want because there no such feature in email protocols by default. The only standardized related message - is MDN (message delivery notification) that generated by recipient’s email client and also known as delivery confirmation or “message read receipt” or in our case - message seen.
So, what I wanted to say previously, - I don’t want to overload developers to implementing custom signal you want. When you sent email message and you see single checkmark, you can turn off your device at this stage, all steps to delivery your message to final recipient - it is job of receiver’s MTA and their IMAP servers as well recipient’s willing to turn on their devices to grab messages from their IMAP server. IMAP’s can’t send PUSH notification to a client if device isn’t connected, so there also no 100% guarantee that IMAP will tell clients to grab new messages.
IMHO it is more than enough to get standard MDN message (“seen”) to be sure that content of sender’s message was really exposed to recipient. I can’t see any profit form getting status you described - “message is delivered to receivers device but not readed”. May be it helpful for debugging, but have no points in real communication I think. Also, I saw a thread that people who using weak/expensive communication channels
don’t want to overload such channels and notification you want obviously would be extra bytes for them.
Unfortunately, can’t switch off my devices even on holidays, must be available 24/7 
Happy Christmas and coming New Year holidays !
