Hubbry Logo
Return receiptReturn receiptMain
Open search
Return receipt
Community hub
Return receipt
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Return receipt
Return receipt
Return receipt
View on Wikipedia
from Wikipedia

In email, a return receipt is an acknowledgment by the recipient's email client to the sender of receipt of an email message. What acknowledgment, if any, is sent by the recipient to the sender is dependent on the email software of the recipient.

Two notification services are available for email: delivery status notifications (DSNs) and message disposition notifications (MDNs). Whether such an acknowledgment of receipt is sent depends on the configuration of the recipient's email software.

Delivery status notifications

[edit]
Main article: Bounce message

DSN is both a service that may optionally be provided by Message Transfer Agents (MTAs) using the Simple Mail Transfer Protocol (SMTP), or a message format used to return indications of message delivery to the sender of the message. Specifically, the DSN SMTP service is used to request indications of successful delivery or delivery failure (in the DSN format) be returned. Issuance of a DSN upon delivery failure is the default behavior, whereas issuance of a DSN upon successful delivery requires a specific request from the sender.

However, for various reasons, it is possible for a message to be delivered, and a DSN is returned to the sender indicating successful delivery, but the message subsequently fails to be seen by the recipient or even made available to them.

The DSN SMTP extension, message format, and associated delivery status codes are specified in RFCs 3461 through 3464 and 6522.

Message disposition notifications

[edit]

MDNs provide a notification of the "disposition" of a message - indicating, for example, whether it is read by a recipient, discarded before being read, etc. However, for privacy reasons, and also for backward compatibility, requests for MDNs are entirely advisory in nature - i.e. recipients are free to ignore such requests. The format and usage of MDNs are specified in RFC 3798.

A description of how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment is provided in RFC 3503.

A non-standard but widely used way to request return receipts is with the "Return-Receipt-To:" (RRT) field in the e-mail header, with the email return address specified. The first time a user opens an email message containing this field in the header, the client will typically prompt the user whether to send a return receipt.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Return receipt

View on Grokipedia
from Grokipedia
In email and digital messaging, a return receipt (also known as a read receipt or delivery receipt) is a feature that notifies the sender when a has been received or read by the recipient. It provides acknowledgment from the recipient's client or server, typically including details such as the date and time of receipt or viewing. Two primary mechanisms enable return receipts in email: Delivery Status Notifications (DSNs), which confirm that a message has been delivered to the recipient's mail server, and Message Disposition Notifications (MDNs), which indicate further actions such as the message being displayed or processed by the recipient's software. These are standardized in protocols to enhance reliability in communication, though their use depends on client support and user settings. Return receipts are commonly available in email clients like and , as well as in and collaboration tools, aiding in professional and legal correspondence by providing of message handling, albeit with limitations in and universal adoption.

Overview

Definition and Purpose

A return receipt in the context of electronic mail is a notification generated by the recipient's email system and returned to to confirm either the successful delivery of the message to the recipient's mailbox or its subsequent processing, such as opening or deletion by the user. These notifications can be automated at the server level for delivery confirmations or require user approval at the client level for disposition reports. The mechanism addresses the inherent asynchrony of email, where senders lack immediate feedback on message status. The core distinction lies between server-level delivery, which verifies that the message reached the recipient's mailbox without user intervention, and user-level , which reports actions taken after delivery, such as viewing or discarding the message. For instance, Delivery Status Notifications provide automated confirmation of delivery outcomes like success or failure at the transport level. This separation ensures that return receipts serve varied needs, from basic transport verification to detailed interaction tracking. The primary purpose of return receipts is to offer senders tangible proof of message receipt or engagement, mitigating risks of non-delivery or non-review in high-stakes scenarios such as legal correspondence, contractual agreements, or time-sensitive business notifications. By enabling such verifiability, they enhance trust and accountability in digital communications while respecting recipient privacy through optional user controls.

Historical Background

The concept of return receipts in electronic messaging originated in the 1980s with proprietary email systems, particularly the Message Handling System (MHS) developed by the (). In , which was standardized in recommendations such as F.400/ from 1988, users could request notifications of receipt or non-receipt of interpersonal messages (IPMs) through per-message parameters like IPM Receipt Notification Request and IPM Non-receipt Notification Request. These features allowed originators to receive automated or manual acknowledgments from recipients or their systems, addressing the need for verifiable delivery in early networked environments before widespread automation. As internet-based email grew in the , informal mechanisms emerged in (SMTP) implementations, including the non-standard "Return-Receipt-To" header, which specified an address for delivery confirmations and was documented in common header lists by 1997. This period saw key formalizations: RFC 1891 in 1996 introduced SMTP extensions for Delivery Status Notifications (DSNs), enabling machine-generated reports on message delivery success or failure, though it was later obsoleted by RFC 3461 in 2003. Complementing DSNs, RFC 2298 in 1998 defined Message Disposition Notifications (MDNs) for reporting actions like message opening, updated to RFC 3798 in 2004 and obsoleted by RFC 8098 in 2017; MDNs, a late development building on DSN foundations, provide finer-grained tracking. The evolution of return receipts was driven by the explosive growth of email volume during the , when usage surged from academic and military networks to commercial applications, necessitating reliable tracking to manage increasing message traffic and reduce uncertainties in delivery. X.400's structured approach influenced SMTP adaptations, as early email borrowed concepts like notification requests to bridge proprietary systems with the open , supporting the transition to global-scale communication. Prior to the 2000s, return receipt mechanisms suffered from limitations, primarily due to reliance on user-initiated prompts in email clients, which resulted in low compliance rates as recipients often ignored or declined requests to avoid intrusions or extra steps. This user-dependent model led to inconsistent tracking, prompting a shift toward more automated server-side responses following the publication of RFCs like and 2298, with the former standardizing machine-generated DSNs largely independent of recipient action and the latter introducing MDNs that often involve interaction at the recipient's MUA.

Core Mechanisms

Delivery Status Notifications

Delivery Status Notifications (DSNs) are a standardized extension to the Simple Mail Transfer Protocol (SMTP) that enable the reporting of email delivery outcomes, such as successful delivery to a recipient's mailbox, permanent failures, temporary delays, or issues during relay to another mail transfer agent (MTA). Defined in RFC 3461, DSNs provide per-message and per-recipient status information, allowing senders to track whether messages have reached their intended destination server without relying on non-standard bounce messages. This mechanism addresses the limitations of basic SMTP, which lacks built-in delivery confirmation, by specifying conditions under which reports are generated. The operational flow of DSNs begins when the sending MTA includes a DSN request in the MAIL FROM command during the SMTP transaction, using parameters to define the desired reporting conditions. If the receiving MTA supports DSNs—indicated via the EHLO response—it processes the request and generates a upon completion of delivery attempts. reports are generated automatically by default, while , delay, or reports require explicit requests to avoid overwhelming senders with notifications. The itself is formatted as a multipart/ message, containing a human-readable , machine-readable delivery-status fields, and optionally the original message content. Key details in the include the action taken (e.g., "delivered," "failed," "delayed," or "relayed"), enhanced status codes for precise diagnostics, and transport-specific error information. Central to DSN functionality are several parameters specified in SMTP commands: ENVID, which assigns a unique envelope identifier (up to 100 characters, encoded in xtext) for tracking the message across MTAs; NOTIFY, which controls the conditions for generating reports (options include for deliveries, for permanent s, DELAY for temporary issues, or NEVER to suppress all); and RET, which determines the amount of original message content included in failure reports (FULL for the entire body or HDRS for headers only). These parameters are added to the MAIL FROM (for ENVID and RET) and RCPT TO (for NOTIFY and ORCPT, the latter for original recipient address preservation) commands. Enhanced status codes, outlined in RFC 3463, provide granular classification, such as 2.x.x for , 4.x.x for transient failures, and 5.x.x for permanent ones, improving across diverse systems. Additionally, RFC 6522 extends DSN support for internationalized email by allowing non-ASCII text in report components and relaxing structure constraints for nested messages. For instance, in a successful delivery scenario, a DSN might an action of "delivered" with status code 2.1.5 (destination valid), confirming the message has been placed in the recipient's mailbox. Conversely, if the recipient's mailbox exceeds its quota, the could indicate a "failed" action with code 5.2.2 (mailbox full), including diagnostic details like an SMTP reply code to aid troubleshooting. These examples illustrate how DSNs facilitate reliable server-side delivery verification, distinct from complementary mechanisms like Message Disposition Notifications that handle post-delivery user actions.

Message Disposition Notifications

Message Disposition Notifications (MDNs) provide a standardized mechanism for a recipient's mail user agent (MUA) or mail gateway to report the disposition of an email message after it has been successfully delivered to the recipient's mailbox. Defined in RFC 8098 (obsoleting RFC 3798), MDNs offer advisory notifications about user actions such as displaying the message, deleting it without display, or dispatching it to another system or recipient. These notifications are inherently optional and user-configurable, allowing recipients to decline requests to preserve and prevent unwanted tracking. To request an MDN, the sender includes the Disposition-Notification-To header field in the outgoing message, specifying the address to which the notification should be sent. When the recipient's MUA detects a qualifying disposition event—such as the message being opened or deleted—the client generates an MDN report as a MIME multipart/report message. This report specifies the disposition type (for example, "displayed" for viewing or "deleted" for removal), the mode indicating whether the MDN was requested or automatically sent, and an optional human-readable explanation of the action. For integration with IMAP servers, RFC 3503 defines a profile using mailbox keywords like $MDNSent to track whether an MDN has been issued for a message, enabling coordinated handling across multiple MUAs accessing the same folder. Key components of an MDN include the Original-Recipient field, which identifies the recipient address from the original message ; the field, detailing the action type and any modifiers (such as "dispatched" with "forwarded"); and the Reported-Message-ID field, which references the of the original message for . Extensions in the standard support additional dispositions, such as reporting partial message retrieval in cases of large attachments or notifications for forwarding actions where the full message is resent. In practice, when a user opens an email with a read receipt request, compatible MUAs like those in or may automatically send an MDN confirming the "displayed" if the feature is enabled. Conversely, many clients default to ignoring such requests or prompting the user for approval, ensuring no MDN is generated if declined to uphold privacy preferences. MDNs thus assume prior successful delivery, complementing mechanisms like Delivery Status Notifications that handle transport-level confirmations.

Implementation Details

Protocol Standards

Return receipts in email protocols are primarily governed by standards developed by the Internet Engineering Task Force (IETF), which define mechanisms for Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN) to ensure reliable reporting of message handling across systems. The core standards for DSN, which focus on delivery status reporting in SMTP environments, are outlined in RFC 3461, the primary specification for SMTP Service Extensions for DSN, published in 2003. This RFC extends SMTP to allow senders to request detailed delivery reports, including success, failure, or delay notifications, by defining new SMTP commands and parameters. Supporting DSN specifications include RFC 3462, which details the format of DSN messages using MIME structures for structured reporting; RFC 3464, which specifies DSN fields such as Original-Recipient and Final-Recipient for precise tracking; and RFC 3463, which defines a set of enhanced status codes to standardize error and success reporting across mail transfer agents (MTAs). For MDN, which reports on message disposition such as reading or deletion, the key standard is RFC 8098 (obsoleting RFC 3798, published in 2004), published in 2017, that defines the Message Disposition Notification for providing standardized reporting of user actions on messages. This RFC supersedes the earlier RFC 2298 from 1998, addressing limitations in format and interoperability while maintaining compatibility with legacy systems through optional fields and backward-compatible headers. Additionally, RFC 3503 extends IMAP4rev1 to support MDN, enabling IMAP clients to request and process disposition notifications directly within the protocol. Related RFCs include RFC 6522 from 2012, which introduces internationalized DSN to support non-ASCII addresses and content, enhancing global compatibility; and the earlier RFC 1891 from 1995 (obsoleted by RFC 3461), which served as a precursor for simple DSN extensions in SMTP. Non-standard headers like Return-Receipt-To, while commonly used in some systems for requesting receipts, are informational and not mandated by any RFC, leading to inconsistent implementation across MTAs. These standards promote by requiring MTAs to recognize and process DSN requests across different implementations, such as through the Envelope-ID (ENVID) in RFC 3461, which allows unique tracking of messages without exposing sensitive content. For MDN, RFC 8098 mandates features, like the Disposition-Notification-To header, to prevent disruptions in environments with older clients that may ignore or mishandle new extensions. The evolution of these standards has incorporated updates for security and , such as guidelines in RFC 8098 to avoid reporting sensitive data in plaintext MDNs, reducing risks of information leakage, and the internationalization provisions in RFC 6522 to handle diverse character sets in global email ecosystems.

Client-Side Configurations

Client-side configurations for return receipts primarily involve settings within mail user agents (MUAs) and message transfer agents (MTAs) that enable users and administrators to control the requesting and processing of delivery status notifications (DSNs) and message disposition notifications (MDNs). Senders can request DSNs during message composition by specifying SMTP parameters such as the NOTIFY option in and RCPT commands to indicate conditions like success, failure, or delay, while MDN requests are made by including the Disposition-Notification-To header field containing the desired notification address. Recipients, on the other hand, configure their MUAs to handle incoming requests through options that allow automatic sending of MDNs, prompting for user approval, or outright denial, with a strong recommendation to default to denial to safeguard by preventing unintended disclosure of message handling details. Administrators configure MTAs to support DSN generation by enabling the SMTP service extension, which involves activating the DSN EHLO keyword and ensuring propagation of parameters like RET (for full or header content in reports) and ENVID (for tracking identifiers). For MDN support, MUAs integrated with IMAP or POP protocols are set up to trigger notifications upon synchronization or opening, often requiring configuration of disposition options to specify reported events such as "displayed" or "deleted." These settings ensure compliance with protocol standards while allowing fine-tuned control over notification flows. Common interfaces in standards-compliant clients include toggles for adding the Disposition-Notification-To header during composition and configuring the NOTIFY parameter for DSN requests, which can be set globally or per-account to automate requests without manual intervention each time. Handling of non-standard methods, such as the legacy Return-Receipt-To header, may involve client-specific parsing rules to interpret or ignore these for , though modern configurations prioritize RFC-defined mechanisms to avoid issues. Best practices emphasize balancing sender verification needs with recipient autonomy, recommending that organizations implement global policies in enterprise environments—such as through group settings—to default to prompting or denying MDNs unless explicit is obtained, thereby mitigating risks like unauthorized tracking of user behavior. Administrators should also configure MTAs to limit DSN reporting to essential details, avoiding inclusion of sensitive content, and regularly settings to ensure they align with organizational data protection requirements.

Modern Usage and Applications

In Email Clients and Webmail

In desktop email clients, provides comprehensive support for both Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN), leveraging integration with Microsoft Exchange servers to confirm message delivery to the recipient's mailbox and reading status, respectively. This functionality is available in paid versions such as and standalone editions like Outlook 2021, where users can enable requests via the Tracking options in the compose window. In contrast, offers configurable MDN support for read receipts through built-in options during composition, with users able to set preferences per account or globally under Tools > Account Settings > Return Receipts. DSN support in Thunderbird is partial, available since version 3 for requesting delivery confirmations from the recipient's server, though it often requires extensions like DSN Settings for advanced control. Webmail services exhibit varied implementation of return receipts. , part of (formerly G Suite), has supported read receipts since 2017 for enterprise and accounts, allowing senders to request notifications when messages are opened, though it relies on proprietary mechanisms rather than native DSN standards. These receipts require recipient approval and are not available in personal @gmail.com accounts. Yahoo Mail provides limited delivery confirmations, where the absence of a failure notice indicates successful server delivery, but lacks native read receipt or automatic MDN features, instead recommending manual follow-up replies from recipients. Mobile email applications show inconsistent return receipt handling due to operating system and client limitations. The native Mail app supports requesting receipts only if the underlying mail server (e.g., Exchange) enables it, but sending is unreliable as does not natively process MDN or DSN without server support, often resulting in no confirmations for IMAP or POP accounts. Similarly, Android's default app does not support requesting or returning read receipts in its mobile interface, even for Workspace users, due to non-real-time syncing constraints. Enterprise tools like 365's Outlook mobile apps, however, offer advanced tracking as of 2025, enabling both delivery and read receipt requests directly in drafts for and Android, with prompts for recipient responses and integration for broader engagement insights. As of 2025, recent developments in return receipt functionality emphasize enhanced AI integrations for automated status summaries alongside email management. Compliance with regulations like the GDPR has also advanced, mandating explicit opt-in consent for read receipts to avoid prohibited tracking without user approval, ensuring transparency in EU-based deployments.

In Instant Messaging and Collaboration Tools

In (IM) applications, return receipt concepts from email have been adapted into visual indicators for message delivery and reading, optimized for real-time, synchronous interactions rather than asynchronous notifications. These features draw inspiration from Delivery Status Notifications (DSN) for confirming receipt and Message Disposition Notifications (MDN) for read confirmations, but implement them via proprietary protocols without direct reliance on email RFC standards like RFC 3461 or RFC 8098. Instead, IM apps use lightweight, client-side signals such as check marks or status icons to provide immediate feedback, enhancing user awareness in fast-paced conversations while prioritizing low latency over formal acknowledgments. WhatsApp introduced read receipts in November 2014, using a single gray to indicate sending, double gray marks for delivery, and double blue marks when the message is read. Users can toggle off read receipts in , which prevents blue marks from appearing on sent messages and hides others' read status from them. Similarly, Signal added read receipts on October 3, 2017, displaying a filled circle for read status when both parties have the feature enabled, with a global toggle to disable sending or receiving them. Telegram employs double s for delivery and blue marks for reads in private chats, with optional confirmations configurable per contact by adjusting for that user to hide read status. In collaboration tools, these indicators support team workflows by signaling engagement without disrupting flow. Slack lacks native read receipts as of 2025 but offers delivery confirmation through message timestamps and user presence dots (green for active, gray for away), allowing indirect inference of visibility via profile icons appearing below messages. provides "Seen" read receipts in chats and channels since 2022, showing confirmation without timestamps, and integrates with Outlook to sync presence status across platforms for hybrid email-messaging scenarios. Zoom Team Chat includes basic delivery notifications via push alerts for sent messages and unread badges, though it focuses more on real-time typing indicators than explicit read confirmations. As of 2025, trends in these platforms emphasize AI-driven enhancements for more nuanced handling, such as contextual acknowledgments where bots auto-respond to confirm understanding based on message content.

Challenges and Limitations

Technical Reliability

Return s, encompassing both Delivery Status Notifications (DSNs) and Message Disposition Notifications (MDNs), exhibit varying degrees of technical reliability depending on system support and user behavior. DSNs, which report on message transfer to the recipient's mailbox, generally achieve high rates in compliant environments for delivery confirmations when mail transfer agents (MTAs) fully implement the protocol. However, reliability falters if the receiving MTA lacks DSN extension support, in which case the request parameters are stripped, leading to fallback on standard non-delivery reports (NDRs) or bounces rather than structured DSN feedback. MDNs, intended to confirm message processing or reading, are inherently less dependable due to their reliance on client-side user agents, where defaults often suppress automatic sending to avoid privacy risks, resulting in frequent non-responses. Common failure modes further undermine dependability. For DSNs, a notable issue arises from false positives, where successful delivery is reported even if the message lands in a spam folder, as the notification only verifies mailbox acceptance without inbox placement checks. MDNs face additional hurdles, such as being ignored by email clients with conservative default settings or blocked by network filters treating report messages as potential spam, leading to lost or undelivered notifications. Factors exacerbating these issues include server misconfigurations that fail to propagate DSN requests across relays, firewall policies blocking outbound report emails, and delays in international routing that timeout notification attempts. Compliance with MDNs remains particularly low in practice, as user consent is required and often withheld, contrasting with the more automated nature of DSNs. To mitigate these reliability gaps, implementers often employ redundant mechanisms, such as combining DSN requests with non-standard headers like Return-Receipt-To for broader compatibility, alongside tracking headers for supplementary logging. Server-side logging enables manual verification of delivery attempts when automated reports fail, providing an independent of recipient responses. Standards like RFC 3464 enhance diagnostics through standardized status codes (e.g., 5.x.x for permanent failures), allowing precise identification of errors such as quota exceeded (5.2.2) or unsupported destinations (5.1.1), thereby facilitating targeted and improving overall system resilience. These strategies, when applied in compliant setups, can elevate effective notification rates, though MDN variability persists due to end-user discretion.

Privacy and Security Concerns

Message Disposition Notifications (MDNs) pose significant privacy risks by potentially revealing users' reading times, devices, and software environments when automatically generated, enabling senders to track behavior without explicit . For instance, the Reporting-UA field in an MDN can disclose details about the recipient's mail user agent (MUA), such as the client software and operating system, which may facilitate user fingerprinting. Similarly, Delivery Status Notifications (DSNs) can expose server details through fields like Reporting-MTA and Remote-MTA, which include fully qualified domain names of mail transfer agents, as well as recipient addresses via Original-Recipient and Final-Recipient fields, potentially compromising in forwarded or scenarios. Security vulnerabilities in return receipts include the ease of forging MDNs through header manipulation, such as spoofing the Disposition-Notification-To field, which can trick recipients into sending notifications to attackers and enable phishing or denial-of-service attacks. Unencrypted transmission of these notifications risks exposing sensitive metadata, including timestamps and device information, during transit over insecure channels. DSNs similarly lack inherent protections against forgery, amplifying risks when combined with broader email spoofing techniques that bypass authentication protocols like SPF or DKIM. Regulatory frameworks address these concerns through requirements for user in . The General Data Protection Regulation (GDPR), effective since 2018, mandates explicit, for tracking via email mechanisms like MDNs, treating such notifications as processing activities that reveal behavioral insights. The (CCPA) similarly requires opt-in mechanisms for sharing personal information, including email addresses and derived metadata from read receipts, with consumers entitled to of data sales or disclosures that enable tracking. The proposed 2025 Digital Omnibus package aims to streamline mechanisms under the for electronic communications tracking, including email-based methods, to address consent fatigue, though this has sparked debates on the balance between simplification and privacy protections. Mitigations include the advisory nature of MDN requests as outlined in RFC 8098, which allows recipients to ignore them without obligation, thereby preserving privacy by default. Modern email clients implement , such as in protocols like or services adhering to PGP standards, to prevent metadata leaks in notifications during transit. User education campaigns promote disabling automatic read receipts in client settings, complemented by regulatory-driven defaults in major providers to deny requests unless consented.

References

  1. https://datatracker.ietf.org/doc/html/rfc3461
  2. https://datatracker.ietf.org/doc/html/rfc8098
  3. https://datatracker.ietf.org/doc/html/rfc3798
  4. https://support.microsoft.com/en-us/office/add-and-request-read-receipts-and-delivery-notifications-in-outlook-a34bf70a-4c2c-4461-b2a1-12e4a7a92141
  5. https://datatracker.ietf.org/doc/html/rfc3798#section-1
  6. https://datatracker.ietf.org/doc/html/rfc3461#section-1
  7. https://support.microsoft.com/en-us/office/add-delivery-receipt-to-track-an-e-mail-message-69cd1b39-2300-482d-96c6-22e2f4a96848
  8. https://datatracker.ietf.org/doc/html/rfc3798#section-10
  9. https://datatracker.ietf.org/doc/html/rfc2076
  10. https://www.rfc-editor.org/rfc/rfc1891
  11. https://mailchimp.com/resources/history-of-email/
  12. https://www.yesware.com/blog/outlook-read-receipt/
  13. https://www.askamanager.org/2013/08/do-i-have-to-send-read-receipts-when-emails-request-them.html
  14. https://datatracker.ietf.org/doc/html/rfc3464
  15. https://datatracker.ietf.org/doc/html/rfc3463
  16. https://datatracker.ietf.org/doc/html/rfc6522
  17. https://datatracker.ietf.org/doc/html/rfc3503
  18. https://kb.mozillazine.org/Figuring_out_whether_the_recipient_read_your_message
  19. https://support.google.com/mail/answer/9413651
  20. https://help.yahoo.com/kb/SLN3386.html
  21. https://discussions.apple.com/thread/255527906
  22. https://techcommunity.microsoft.com/t5/microsoft-365-blog/delivery-and-read-receipts-in-outlook-for-android-and-ios/ba-p/4386420
  23. https://www.gdpreu.org/gdpr-compliance/email-tracking/
  24. https://betanews.com/2014/11/06/whatsapp-adds-read-receipts-as-it-celebrates-fifth-birthday-infographic/
  25. https://faq.whatsapp.com/665923838265756
  26. https://signal.org/blog/read-receipts/
  27. https://support.signal.org/hc/en-us/articles/360007059812-Read-Receipts
  28. https://www.alphr.com/managing-telegram-read-receipts/
  29. https://www.suptask.com/blog/slack-read-receipts
  30. https://slack.com/help/articles/201864558-Set-your-Slack-status-and-availability
  31. https://support.microsoft.com/en-us/office/use-read-receipts-for-messages-in-microsoft-teams-533f2334-32ef-424b-8d56-ed30e019f856
  32. https://support.microsoft.com/en-us/office/teams-status-information-available-in-outlook-b1509222-2c5d-4cd4-bff7-508d2b6f410d
  33. https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0061605
  34. https://aws.amazon.com/blogs/messaging-and-targeting/enhance-event-experiences-with-a-generative-ai-powered-whatsapp-assistant-using-aws-end-user-messaging/
  35. https://www.litmus.com/blog/why-email-deliverability-matters
  36. https://learn.microsoft.com/en-us/exchange/mail-flow/non-delivery-reports-and-bounce-messages/non-delivery-reports-and-bounce-messages
  37. https://gdpr.eu/article-6-how-to-process-personal-data-legally/
  38. https://oag.ca.gov/privacy/ccpa
  39. https://www.twobirds.com/en/insights/2025/eu-digital-omnibus-resetting-europes-digital-rulebook
  40. https://www.theguardian.com/world/2025/nov/19/european-commission-accused-of-massive-rollback-of-digital-protections
  41. https://gdpr.eu/email-encryption/
Add your contribution
Related Hubs
User Avatar
No comments yet.