Only use a web bug if you know that the receiving system won't treat it as spam and that the recieving mail client is configured to render HTML.
Doing a direct to MX session will let you see rejection messages, but your firewall may not allow that and even if it does you could get a subsequesen DSN. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Grant Taylor <[email protected]> Sent: Friday, August 28, 2020 12:06 PM To: [email protected] Subject: Re: Sending email from the Mainframe 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
