From: barmar@alum.mit.edu   
      
   In article ,   
    Moe Trin  wrote:   
      
   > 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.   
      
   In most cases these should be equivalent, except for the From address in   
   the bounce message -- if they reject it the bounce comes from   
   Mailer-Daemon@senderdomain, if they accept and then bounce it comes from   
   Mailer-Daemon@receiverdomain.   
      
   But in the case of spammers sending directly to the destination site, I   
   can see their point -- it creates additional blowback.  Spamming   
   software doesn't send bounces, so the only bounces that would occur in   
   this mode are when the receiving server accepts the mail and then   
   returns it to the (forged) sender.   
      
   --   
   Barry Margolin   
   Arlington, MA   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)