Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Thu, 07 Aug 2014 05:42:13 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-appsawg-nullmx-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   Senders of abusive mail often use forged undeliverable return
   addresses.  Null MX allows DSNs and other attempted responses to such
   mail to be disposed of efficiently.

What's a DSN?   Please define in the terminology section, or add a
reference saying that the reader should read (X), or just expand on first
use: not all readers will have the SMTP RFCs memorized. :)

Also, it's not clear to me how this is a win unless the forged
undeliverable return address has a null MX.   Is that the envisioned
scenario?   If so, an additional sentence or two explaining why this is
likely would help to justify the existence of this paragraph; otherwise I
recommend just deleting it--it's not necessary, and on the face of it it
seems implausible, but I'm not a spam expert, so maybe there's a reason
of which I am not aware that the spammer would set this up, or use a fake
domain for which a null MX exists.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Aug 2014 08:58:44 -0400

You're right that a spammer using randomly generated fake domain names is
not likely to pick a real one with a null mx.  But a lot of spam is sent
using domain names harvested from the Internet, sometimes picking ones that
seem related to one or more of the recipients, in order to make the mail
seem legitimate.  It's those that are actually reasonably likely to pick
domain names that aren't used to send email.  It's those that the paragraph
in question is addressing.

Barry

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 09:04:09 -0400

On Aug 7, 2014, at 8:58 AM, Barry Leiba <[email-masked]> wrote:
> You're right that a spammer using randomly generated fake domain names is not likely to pick a real one with a null mx.  But a lot of spam is sent using domain names harvested from the Internet, sometimes picking ones that seem related to one or more of the recipients, in order to make the mail seem legitimate.  It's those that are actually reasonably likely to pick domain names that aren't used to send email.  It's those that the paragraph in question is addressing.

I suspected it was something like this.   I think it would be beneficial to add a sentence or two explaining this scenario for the reader, although obviously it's not strictly necessary.

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Aug 2014 16:57:13 -0400

I believe it will be generically applied to all anonymous 
transactions. IOW, it will be used as an across the board 5321.Mail 
 From check for any non-whitelisted return-address.

I can provide 11 years of CBV statistics to determine which percentage 
are real No MX versus NULLMX based.

We currently use a 550 when the return-address CBV fails, so that 
isn't going to change.  Code wise, one line can be added to implement 
this check to help preempt the actual CBV call:

   if mx.count == 1 and mx.exchange[0] == "."  then return FALSE
   return CBV(MX)

-- 
HLS

On 8/7/2014 8:58 AM, Barry Leiba wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>