On Fri, Jun 27, 2025 at 10:47 AM Greg <curtys...@gmail.com> wrote: > > On 2025-06-27, Greg Wooledge <g...@wooledge.org> wrote: > >> > >> Bounce can and does mean a rejection of the email by the *server*, so > >> your proposal seems nonsensical or confusing, as the email has > >> already been delivered to its recipients. > > > > I am not proposing anything. I am *explaining*. > > > > This is the terminology that mutt uses. > > It is not the accepted meaning of the term. > > https://github.com/mjg59/jargon/blob/master/bounce > > :bounce: v. 1. [common; perhaps by analogy to a bouncing check] An > electronic mail message that is undeliverable and returns an error > notification to the sender is said to bounce. see also {bounce message}.
RFC 5321, Section 6.2, might also help (<https://datatracker.ietf.org/doc/html/rfc5321#section-6.2>): 6.2. Unwanted, Unsolicited, and "Attack" Messages Utility and predictability of the Internet mail system requires that messages that can be delivered should be delivered, regardless of any syntax or other faults associated with those messages and regardless of their content. If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above. In today's world, in which many SMTP server operators have discovered that the quantity of undesirable bulk email vastly exceeds the quantity of desired mail and in which accepting a message may trigger additional undesirable traffic by providing verification of the address, those principles may not be practical. As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. 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. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate. To stretch the principle of delivery if possible even further, it may be a rational policy to not deliver mail that has an invalid return address, although the history of the network is that users are typically better served by delivering any message that can be delivered. Reliably determining that a return address is invalid can be a difficult and time-consuming process, especially if the putative sending system is not directly accessible or does not fully and accurately support VRFY and, even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses are, in fact, invalid. Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content. Jeff
