Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00

[Hector Santos <[e-mail]>]

At the end of the day, this is a proposed optimization and enhancement 
to the MX record protocol handling logic.  On the publishing side, it 
can ultimately change/add new protocol rules and guidelines:

   - Mail Domains MUST have MX preference non-zero values (PREF != 0)
   - Non-Mail Domains SHOULD have MX preference zero values (PREF == 0)

For PREF!=0, the MUST is best to avoid NULL MX compliant systems 
skipping mail deliveries.  If we allow a SHOULD, then the domain is 
open to false positive mail non-deliveries.

For PREF==0, a SHOULD allows the outbound mail framework to decide how 
to best handle the mail delivery; a) by supporting this NULL MX 
proposal which will short circuit the delivery attempt and/or b) 
supporting the "Status Quo" of continuing to attempt to connect to 
what is probably a non-existing server.

A domain declaring a MX with PREF == 0 could be declaring to the mail 
client world to avoid connecting to this host, but this waste and 
redundancy overhead is absorb in modern systems and thus is a 
non-issue for the most part.   In our system, the domain will be 
permanently blocked after all attempts have been exhausted. It takes 
operator intervention to remove this auto-pilot block -- a rare 
procedure.  So while the idea sounds simple, it may not be a simple 
implementation nor simple deployment (turning it on for updates).

But it is an optimization to the MX logic and should be described as 
such avoiding the highly subjective reasonings dealing with mail 
filtering, anti-spam, reputation, etc.

-- 
HLS



On 2/21/2014 2:57 PM, Dave Crocker wrote:
> On 2/21/2014 10:43 AM, Murray S. Kucherawy wrote:
>> On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Except that 'authorized' is the essential point, to distinguish
>> between
>>     legitimate uses and spoofing, etc. uses.  The word 'legitimate'
>> doesn't
>>     work well here. So 'authorized' seems the next closes.
>>
>>     There are three essential problems with the original wording.
>> The first
>>     is that domains don't 'send' mail. Also the word 'send' is frankly
>>     ambiguous in its own right here. And lastly is that the
>> stricture needs
>>     to cover keep the domain name out of a number of different fields.
>>
>>
>> My problem is that "SHOULD NOT be authorized for use" is a concept that
>> exists entirely inside the ADMD creating the content; it points to
>> something that's not subject to interoperability.  "SHOULD NOT be
>> used",
>> by contrast, is something that a receiver can evaluate.
>
> We've all locked into some interesting linguistic challenges, though
> they seem to be getting cast in terms of a kind of email protocol
> challenge.
>
> To start:  I'm not trying to change any existing email standards and
> don't think the current topic will do that.,
>
> Rather, I'm trying to do two other things.  One is to distinguish
> between activities authorized by the domain owner, versus those
> outside of the owner's control.  And then to suggest proscription of
> what the domain owner authorizes for use.
>
> Simply put:  If one publishes a NULL MX for the name, one shouldn't
> use that domain for an email address anywhere.  (Tony's language was
> good for that I think.)  And I've no idea whether should or must
> should be used -- and don't much care.
>
> But the linguistic wrinkle is that those nasty spoofers are sitting
> out there, getting in the way of generic language like "should not be
> used".
>
> d/
>
>