From: ibuprofin@painkiller.example.tld.invalid   
      
   On Sun, 07 Apr 2013, in the Usenet newsgroup comp.protocols.tcp-ip, in article   
   , Barry Margolin   
   wrote:   
      
   >Martijn Lievaart  wrote:   
      
   >>  Jorgen Grahn wrote:   
      
   >>> But you make it sound as if disabling all bounces is necessary on   
   >>> the internet today.  I suspect a minority of servers do this.   
   >>> Maybe a tiny minority?  I tested one server (which worked) but   
   >>> surely someone has collected statistics somewhere ...   
      
   >> Disabling bounces, or at least severely limit them, is sound   
   >> practice. It is better to reject then to bounce.   
      
   >Same difference. If a message is rejected, the sending server would   
   >traditionally bounce it.   
      
   I interpret the discussion as relating to a very different part of the   
   mail transaction.   The "news.admin.net-abuse.blocklisting" Usenet   
   newsgroup was removed in (perhaps) late 2009, but one thing that got   
   many people posting (whining) to that newsgroup was their being put on   
   various blocklists for BELATEDLY sending a bounce.  Over and over   
   again, the regulars in that group stressed that if you're not going to   
   accept mail (non-existent user, full mail-box, WHAT-EVER) you must do   
   that during the initial mail transfer stage.  Returning a "55x" result   
   code then ends that mail transfer right there.  No later discovery that   
   the mail is actually spam or the user doesn't exist, or anything else.   
   No bounce.   No landing on the blocklists.   Yes, RFC821, 2821 and 5321   
   require undeliverable messages if you accepted mail for delivery, and   
   if someone sends them they must expect that there "could" (or maybe   
   "will") be consequences.   Not accepting undeliverable/unwanted mail   
   is a much better solution.   
      
   >Unless you're talking about the special case where the client is   
   >sending a message to their own domain.  Then the submission server   
   >may be able to reject the message immediately, and many do   
      
   That's the Horse of a Different Color.  There, it's all internal to a   
   domain, and as many are requiring some form of authentication to   
   submit mail, "this" domain should fix "their" problems.  The "bounce"   
   issue normally refers to the case of a mis-configured RECEIVING mail   
   server trying to "Return to Sender" garbage that has a forged "envelope   
   sender", and the worst abusers would not only bounce, but include the   
   entire (usually spam) content. That was well and truly deserving to be   
   placed on all blocklists.   
      
           Old guy   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)