Re: Please, don't reply to spam -- much less on list [was: ግěcůžላኣዝዩ]

[Jeffrey Walton <noloader@gmail.com>]

On Fri, Jun 27, 2025 at 10:47 AM Greg <curtyshoo@gmail.com> wrote:
>
> On 2025-06-27, Greg Wooledge <greg@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