On 8/28/20 7:39 AM, Joel C. Ewing wrote:
You seem to be asking for an impossibility here because the email protocol as currently implemented doesn't support this.
There is a way to have a relatively good indication if a message was displayed or not. It relies on HTML and unique per message URLs. But even that is not guaranteed. It's just considerably more likely to succeed than other methods.
There is no way for a sender of email to distinguish between email that is accepted by its target domain but classed (correctly or incorrectly) as spam and thrown into the bit bucket to protect end users and make spammers waste their transmission resources, and email that is accepted and actually stored for retrieval by the recipient.
Agreed. It's very difficult, neigh impossible, to accurately detect good email addresses.
Some servers won't even tell a sender if the target email account doesn't exist, because that info is also useful to spammers. So, "successful" transmission to the target domain can occur even when there will be no actual delivery to any end user, and email rejection by the receiving domain is only a subset of the potential failures.
However you can flip the logic on it's head. You can detect known bad email addresses and "fail fast".
If your JCL / job is doing it's own SMTP (and not relying on something else to do it on it's behalf) it can deduce the SMTP rejections and have a high degree of certainty that the email address has a problem. This also means that your JCL / job is not dependent on the DSN because it has visibility to the SMTP status codes directly.
Remember, the DSN is a way for a sending SMTP server to notify a sender which is outside of the SMTP exchange that there was a problem during / inside of the SMTP exchange.
The email protocol does still allow for requesting a return email receipt when the email is actually opened, but that was one of the first features grossly abused by spammers wanting to locate actively-used email accounts; so all reasonable email clients default to suppression of automatic "receipt" responses.
This is actually not part of the SMTP protocol. Message Disposition Notifications are a feature implemented by email clients and the senders desire to receive one is conveyed by a header in the message. The SMTP server is oblivious to this.
SMTP is Delivery Status Notification eMail client is Message Disposition Notification
It would have to be a highly unusual situation before most informed users would ever allow a receipt to be returned.
I have on occasion responded to / allowed an MDN request. But as a general rule I have my email client prompt me and I almost always deny the request. About the only time I'll allow it is if it's from someone I know on a topic that I am willing to voluntarily share that information.
The only way at present to know for certain that email was actually sent, delivered, and read requires co-operation by the recipient to send a return email reply that has content that clearly demonstrates it is not just an automated response to the received email. Other than that, there is always room for some uncertainty that a failure could have occurred that prevented receipt.
There's a reason that Message Disposition Notifications use the term "disposition". Meaning that the message was displayed or printed. There is no way that a computer can guarantee that the message was actually read. At least not currently.
-- Grant. . . . unix || die ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
