The problem of backscatter, part 3 - Legitimate bounces

re: The problem of backscatter, part 3 - Legitimate bounces

Lee Maguire — Tue, 01 Jul 2008 13:40:13 GMT

It should be pointed out that there is has been a draft standard for bounce message formats for a few years now - a multipart/report message (<a href="http://tools.ietf.org/html/rfc3462">RFC 3462</a>)

containing a delivery-status (

<a href="http://tools.ietf.org/html/rfc3464">RFC 3464</a>) message.

However many of the codebases for mail exchangers predate this, so it's clearly not a universally adopted standard at this time.

Your given example, however, was probably delivered in this standard.

re: The problem of backscatter, part 3 - Legitimate bounces

Frank — Tue, 01 Jul 2008 19:40:49 GMT

In one of the next parts I hope you come back to the point about client A sending mails to server B. If B rejects one or more of these mails immediately it is actually A that has to create a non-delivery report for the (alleged) sender, e.g., put it into the mailbox of user@A. Only if B was forced to accept a mail "on probation", later finding out that it can't deliver it, it is B that has to send an NDR.

Accepting mail "on probation" is a major part of the backscatter problem (but no issue after an SPF PASS, obviously). The not yet published successor of RFC 2821 uses a clearer terminology wrt "bounce" (= send NDR), never confusing it with "reject" (= SMTP error).

551 "use address X for user Y" is one of many other SMTP reject reasons, 550 for say SPF FAIL is also known.

The problem of backscatter, part 4 - What the RFC says

Terry Zink's Anti-spam Blog — Mon, 07 Jul 2008 07:45:17 GMT

As one of the commenters in my previous post mentioned, RFC 3464 specifies the content-type for Delivery

Backscatter spam.. ugh!

THE OFFICIAL BLOG OF THE SBS "DIVA" — Mon, 07 Jul 2008 08:57:00 GMT

http://blogs.msdn.com/tzink/archive/2008/06/25/the-problem-of-backscatter-part-1.aspx">http://blogs.msdn.com/tzink/archive/2008/06/25/the-problem-of-backscatter-part-1.aspx http://blogs.msdn

re: The problem of backscatter, part 3 - Legitimate bounces

Lee Maguire — Mon, 07 Jul 2008 17:38:12 GMT

"To make matters worse, others use null senders for non-NDR messages."

Traditionally this has been done to avoid receiving "out of office" automated replies. If you receive mail other than DSN/bounce messages using a null-sender I encourage you to contact them and suggest that they instead try using the "Auto-Submitted:" header field as described in RFC 3834 section 5.

http://tools.ietf.org/html/rfc3834

re: The problem of backscatter, part 3 - Legitimate bounces

Charles — Sun, 20 Jul 2008 00:18:25 GMT

Actually, your initial paragraph describing this issue is all wrong.

You should NEVER, EVER bounce a message AFTER you have already accepted it for final delivery.

The correct behavior is to do an SMTP REJECT - meaning, your server NEVER ACCEPTS it for final delivery - and let the SENDERS server generate the NDR to the original sender.