Quote:
Originally Posted by jbolty
In todays world there is no reason on earth to have bills or bank statements delivered by mail.
|
Unless you want to be sure you receive the bill or statement.
https://support.zendesk.com/hc/en-us...deliverability
The way it's commonly used, email is a non-confirming message delivery protocol. This means that there is no guarantee that any given email sent from you will be delivered to its intended recipients. Delivery is based on assumption and acceptance by the relay server to complete the function. Additionally, once the relay server has accepted the email for delivery there are a number of things that may prevent the email from making its way to the recipient.
Occasionally, a server will provide what is known as a "bounce-back" email, letting the sending server know that the email can not be delivered and why. Many servers will not provide these as part of an effort to provide potential spammers with as little information as possible about their internal processes.
With a proliferation of spam emails, an increasing number of ISPs have been forced to implement more stringent restrictions on delivery, as well as focus more on filtering out spam traffic. This makes it increasingly difficult for them to effectively do their jobs without occasionally suspending a legitimate email along the way. Luckily, these systems can be self-correcting and there are steps that can be taken to assist them in the difficult job that they do. Both individual providers and the Federal Trade Commission have made efforts to reduce the overall effect of spam. However, the open nature of email as a communication protocol suggests that it will very likely always represent a problem.
https://superuser.com/questions/8971...-silently-fail
Can an email delivery silently fail ever, with the sender receiving no notification whatsoever about the failed delivery?
Doesn't the SMTP protocol guarantee email delivery, or at least a failed delivery notification to the sender?
No, SMTP has no delivery guarantees (you can check it yourself in RFC 5321):
There are mechanisms glued on to the SMTP protocol and associated programs for ensuring delivery (DSN, Return Receipts). Note that these themselves are best-effort / mutual cooperation extensions (Most mail clients let you elect not to send read receipts, and some clients can't issue a read receipt. Some MTAs can't/won't issue a delivery receipt.