Re: [apps-discuss] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Hector Santos <[e-mail]>]

On 8/2/2014 9:44 AM, Dave Crocker wrote:
> On 7/18/2014 9:03 AM, John Levine wrote:
>>>> I don't recall reading this in the document. It's a good point. IM personal
>>>> O it's more important than either 4.1, 4.2 and 4.3. Add it, please.
>>>
>>> I agree with Arnt here. Not having a code for this is an obvious omission,
>>> and this is chance to address it.
>>
>> Please send text, or at least a three part number.
>
>
> Shepherd hat:
>
>     I haven't seen any follow-up to John's request, although support for
> adding an extended code looks pretty solid.
>
>     It really would help for someone who is strongly in favor of adding
> the code to write up the necessary text, to be added to the draft.
>


Currently, SMTP (RFC5321) current recommends 550 or 553.  Reasons 
explained below, but 554 may be the better match based on documented 
specs.  First some background ........

There has always been a long time resistance (for good reason) towards 
SMTP-based CBV "Call Back Verifiers" methods where a small footprint 
SMTP client is used to verify the validity of the 5321.Mail From 
address a.k.a Return Path or reverse-path at the SMTP transaction level.

The NULL MX can be used as short circuiting method to minimize the CBV 
overhead where it is used. Currently, the CBV is one the highest 
payoff for fraud detection and can be found to be used abeit at the 
smaller scale despite the obvious IETF concerns about it.

Our CBV currently uses a straight forward 550 rejection when the 
return path can not be validated.   Based on 11 years of CBV usage, 
IMO, what would be more important to convey is *WHEN* the NULL MX can 
be performed; at the MAIL FROM state or the RCPT TO state.

Each receiver site has a different rate of 55x user rejections at the 
RCPT TO level.

For our site, since 2003, it can be a consistently high 50-60%.  This 
translates to the 50-60% reduction in DNS MX lookup overhead when any 
DNS-based check can be delayed from MAIL FROM to RCPT TO, and that 
includes the SPF check where this optimization need was first discovered.

However, this idea of delaying the return path check until the 
forwarding address is known was discussed in RFC5321 section 3.3:

    3.3.  Mail Transactions

                                                    Despite the apparent
    scope of this requirement, there are circumstances in which the
    acceptability of the reverse-path may not be determined until one or
    more forward-paths (in RCPT commands) can be examined.  In those
    cases, the server MAY reasonably accept the reverse-path (with a 250
    reply) and then report problems after the forward-paths are received
    and examined.  Normally, failures produce 550 or 553 replies.

In short, this is the closest thing we have to an IETF "sanctioned" 
logistic for checking reverse-path with a recommended response code.

However, according to SMTP, probably 554 is a closer match for a NULL 
MX reason:

SMTP (RFC5321) has the following example definitions for the three codes:

    550  Requested action not taken: mailbox unavailable (e.g., mailbox
         not found, no access, or command rejected for policy reasons)

    553  Requested action not taken: mailbox name not allowed (e.g.,
         mailbox syntax incorrect)

    554  Transaction failed (Or, in the case of a connection-opening
         response, "No SMTP service here")

So probably 554 would be the proper code for a a "No SMTP Service 
Here" NULL MX check operation.


-- 
HLS