For messages received from internal users on an authenticated connection, notification of delivery failure is always appropriate. This discussion is about messages arriving from the Internet over unauthenticated SMTP. I am suggesting that non-delivery notification should be conditional and rare.
Reject Notification Options
The specifications provide for two ways to notify a sender about delivery failure:
- An SMTP Response Code in the 5xx range, sent to end of the SMTP session, assuming that rejection is detected soon enough, or
- A non-delivery email message sent to the Return-Path address, if rejection is detected after the SMTP session is closed.
The objections to notification by Non-Delivery Reports
In the absence of tight restrictions on their use, Non-delivery reports (NDRs) are a problem because:
- They are expected to create a significant outbound message load because of volume.
- They may go to the wrong person, and this backscatter may cause disruption to the victim that rebounds to reputation problems for the notification sender.
The objections to notifying Unwanted Senders
When deciding whether to notify about message rejection, the defender must consider how the sender will respond to the notification. In the typical case where the blocked message comes from an unwanted sender, notification works against the interest of the notifier. The sender can be expected to use the rejection notification to adapt his penetration strategy to evade the cause of the rejection. If the rejection notice provides enough information, the unwanted sender may know whether he needs to change the message content, the recipient address, his sender identity, or his server identity. All of these responses work against the interest of the defender who wants no messages at all from this source.
The objections to notifying after Quarantine Disposition
A message may be rejected from quarantine because of administrator action or time expiration. The purpose of quarantine is to allow time for administrative review, so that acceptable messages from friendly senders will be allowed, by administrative action, before the timer expires. When a message is rejected from quarantine, the message has been judged unacceptable, either directly or indirectly, and all of the objections to notifying senders will apply. Those objections are amplified by the objections to using non-delivery reports, since notification by NDR is the only option at this point.
The objections to notifying Friendly Senders
For friendly senders, a problem occurs if the rejection is a false positive. For messages from individuals, the false positive is a minor problem, since it will probably cause additional communication that leads to resolution of the problem.
For subscribed message streams, a rejection notice is likely to cause the recipient to be unsubscribed. If the rejection is correct because the recipient account has been terminated, this will be a good thing. However, if the rejection is a false positive for any reason, the recipient may be unsubscribed from a message stream that he considers valuable.
The objections to Silent Discard
Silent Discard is the alternative to rejection notification. This disposition is problematic if the sender is friendly and the content should have been acceptable, because the sender will assume that the message was delivered and that the recipient is accountable for responding to its contents. Various complications may arise from this confusion.
Use Quarantine to minimize False Rejections
Rejection can occur for any of these reasons:
- Server reputation
- Sender Email address reputation (either the SMTP “Mail From” address or the message From address)
- Recipient permanent errors (never existed, terminated, or disabled)
- Recipient temporary errors (over-quota account)
- Authentication issues with either of the two sender email addresses
- Unacceptable content
Reputation problems can be considered certain, having minimal risk of a false positive. Recipient problems are also certain, as long as the system is not prone to false positives caused by bugs or query failure.
Authentication and Content problems are heuristic results, meaning that false positives should be expected. Rejection based on a false positives is expected to cause harm to both sender and recipient, by disrupting their communication. Consequently, my strategy is to send authentication errors and content problems to quarantine, rather than reject. When malicious content or malicious impersonation is confirmed, an unconditional block rule is created on the responsible identifiers. In the rare case that malicious content is received from a friendly sender, quarantine allows the problem to be exposed and escalated to the sender organization.
When a false positive is confirmed, the message is released and local policy is updated. Authentication problems are corrected by configuring an alternate authentication rule in local policy. Content problems are corrected by creating a whitelisting rule for the responsible identifier, conditional on it being authenticated. Any of these actions will ensure that the ambiguity is resolved for the next message from the same source.
Send notifications when all objections are resolved
Given all of the above, senders should be notified only when:
- the problem is a recipient errors,
- the recipient error is trusted to be free of operational mistakes, and
- the sender is known to be friendly.
Notification of content and authentication problems is assumed to be unnecessary because these problems will be sent to quarantine and resolved favorably during quarantine review.
Notification of reputation problems is assumed to be unnecessary because the classification of the sender as “friendly” implies that the sender has an acceptable reputation.
This approach assumes that a mechanism exists to classify senders as “friendly”. For senders that are not classified as either friendly or blocked, the administrator must decide whether to send recipient error notices. Given the high volume of recipient-guessing techniques that I observe in advertising messages, my recommendation is to handle recipient problems from unclassified senders with silent discard, and to consider the recipient error as an indication of a possibly unwanted sender.
Obstacles to Implementing this design
The objection to using non-delivery reports means that SmarterMail, in its present form, is a poor choice as an incoming gateway, because all of the most useful spam checks occur after the SMTP session is closed. PostFix onLinux, with Declude Reboot, would be an alternative.
My testing of SmarterMail suggests that if a communication problem occurs during recipient verification, the error is handled as a confirmed failure, causing the message to be rejected. It should treat a non-result as an unknown, and let the message proceed. If the recipient is invalid, the problem will be detected during delivery. More importantly to this design, a recipient verification failure in SmarterMail will always notify the sender of the problem. This behavior permits recipient guessing and directory harvesting by unwanted senders.
Custom software is needed to configure alternate authentication rules for sender authentication problems.
Custom software and administrative effort will be needed to build a list of “friendly” senders who are eligible for recipient failure notification. The entire message will need to be accepted before the message From address can be confirmed as a “friendly” sender, so notification will always be sent using a non-delivery report. This volume of these messages should be trivial, and the risk of incorrect notification should be eliminated by prior authentication of the sender as “friendly”.