Bounce message

[1] Although the SMTP is a mature technology, counting more than thirty years, its architecture is increasingly strained by both normal and unsolicited load.

Hard bounces are permanent and they score higher in terms of sender's IP damage.

Hard bounces occur when the sender's mail server determines that there is a high likelihood that the recipient is unavailable and is likely to remain so.

This can happen in particular in the context of email spam or email viruses, where a spammer (sender) may forge a message to another user (intended recipient of spam), and forges the message to appear from yet another user (a third party).

The MDA simply copies the reverse path in the SMTP MAIL FROM command into the Return-Path.

Today these paths are normally reduced to ordinary email addresses, as the old SMTP 'source routing' was deprecated in 1989; for some historical background info see Sender Rewriting Scheme.

RFC 3834 offers some heuristics to identify incorrect bounces based on the local part (left hand side before the "@") of the address in a non-empty Return-Path, and it even defines a mail header field, Auto-Submitted, to identify auto replies.

The remaining bounces with an empty Return-Path are non-delivery reports (NDRs) or delivery status notifications (DSNs).

This next MTA is free to reject the mail with an SMTP error message like "user unknown", "over quota", etc.

"This rule is essential for SMTP: as the name says, it's a 'simple' protocol, it cannot reliably work if mail silently vanishes in black holes, so bounces are required to spot and fix problems.

It is then often impossible for the MTA to inform the originator, and sending a bounce to the forged Return-Path would hit an innocent third party.

However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned.

If silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems.

"Not validating the sender is an inherent flaw in today's SMTP, which is without the deprecated source routes mentioned earlier.

Other reasons include resource exhaustion — such as a full disk — or the rejection of the message due to spam filters.

Common codes are 5.1.1 (Unknown user), 5.2.2 (Mailbox full) and 5.7.1 (Rejected by security policy/mail filter).

MTAs involved in a reject are named according to the point of view of the Reporting MTA . MTA names are often of type dns .