You seem to be asking for an impossibility here because the email protocol as currently implemented doesn't support this. 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. 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.
Even successful receipt and successful storage of an email by the target domain doesn't mean that the intended recipient will ever login to the account, retrieve it and actually read it. In fact, the user's local email client may even have additional filters that trash some received email based on his own criteria. Acceptance by the domain's mail server doesn't mean the email will ever be "delivered" to the actual end user. 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. It would have to be a highly unusual situation before most informed users would ever allow a receipt to be returned. Being able to accurately verify successful delivery of email to an actual email account would be a tremendous boon to spammers and other undesirable users of emai, so I wouldn't expect to see this situation change until much better ways of dealing with that problem exist. 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. Joel C Ewing On 8/28/20 6:57 AM, Sasso, Len wrote: > Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe > and if it is unable to be delivered, for any reason, sends an email back to > the Sender with a corresponding message? > > > Thank You and Please Be Safe! > > Len Sasso > Systems Administrator Senior > CSRA, A General Dynamics Information Technology Company > 327 Columbia TPKE > Rensselaer, NY 12144 > > Office Hours: M-F 7 AM - 3:45 PM > Out-Of-Office: Friday, August 28, 2020 Noon - 3:45 PM > Phone: (518) 257-4209 > Cell: (518) 894-0879 > Fax: (518) 257-4300 > [email protected] > URL: www.gdit.com<http://www.gdit.com> > > > > ... -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
