Re: [apps-discuss] Call for Adoption: draft-delany-nullmx

[Hector Santos <[e-mail]>]

I support the fast adoption of NULLMX as a BCP method. Not as a 
standard method.  As a PS, it may slow it down because *I don't see 
too many abandoning already long established, well embedded, finely 
tuned, well greased over many years of implicit MX code, queuing, 
scheduling outbound mail logic.*

Things to consider:

Can we be assured that any existing MX=0 records are not just 
mistakes, and they are indeed "no mail notifications"?

Sending mail is "cheap" these days, DNS lookups is "cheap."  Sure, its 
nice to optimized things, but it already is today. It isn't a problem 
today especially when there is decades of sending "queuing 
intelligence" already implemented. A failed receivers are generally 
filtered out pretty fast and it cost nothing. Its all automated.

This is about YADDI (yet another domain discovery issue) (again) and 
there might be better solutions available for sending mail or in 
principle, contacting a host.  In general, worthy changes need to be 
shown and justified to make it all worthy to consider. This is 
especially within the IETF that is increasing showing a direction to 
accepting PS ideas only latter to abandon them and do so less regard 
for the smaller end of the market place.  I would like any new 
"change" to have more of an cost benefit impact to justify 
exploration. Something more than just "we don't do mail, so stop" 
notification.

Anyway, I think its a good idea to explore as an BCP rather than a 
standard.  This is keep it really simple. It should also help get it 
established faster for more rapid consideration by adopters.  Labeling 
it as a proposed standard begins to force things and I don't see too 
many people dropping their long term engineered implicit MX logic.

For example, we long supported a outbound sending rule:

      SupportNoMXTryOnce

When the rule was enabled (ON), it basically set the sending queue 
maximum attempts to one when a MX lookup was empty.  The default as ON 
long ago, but the default is not OFF and has been for many years now. 
I believe this change was due to two factors:

   - Reports of significant retry success with No MX, A records,
   - lower cost of operations (its "cheap").

I can see how a new MX lookup factor of MX=0 can be used to enable the 
try once logic:

    if MX.COUNT = 0 THEN SupportNoMXTryOnce = TRUE

I can see this as a BCP suggestion, not as a standard suggestion.


-- 
HLS

On 1/30/2014 4:46 PM, Murray S. Kucherawy wrote:
> Colleagues,
>
> This is a formal call for adoption of draft-delany-nullmx into
> APPSAWG.� The call will close on February 14, 2014.� The chairs note
> that there has already been some expression of support for adoption in
> past threads; more feedback is requested.
>
> As you've heard us say in Vancouver and earlier, we are instituting a
> new experimental idea with respect to documents in APPSAWG, namely
> "mini-charters" in order to frame discussions, set goals, and secure a
> minimal set of reviewers and supporters.� The mini-charter for this
> draft appears at the end of this message.
>
> Please submit comments, concerns, support, etc. for this document's
> handling by APPSAWG in reply to this thread by February 14, 2014.�
> Note that this is not an indication of support for the document as-is,
> only for APPSAWG adopting it for further development.
>
> The mini-charter lists four people (in addition to the authors)
> willing to provide timely reviews and support for the document through
> publication.� I'd like to be able to list a couple more.� If you'd
> like to be added to that list, please say so in your reply.
>
> -MSK
>
> The mini-charter:
>
> SMTP mail has never provided a way for a domain to state that it does
> not receive mail. �If a domain publishes MX records, it definitely
> does receive mail. �If it publishes no MX, but does publish A or AAAA
> records there is no way to tell whether those records are indended to
> identify an "implicit MX". �If a sending host attempts to send to an A
> or AAAA, and is unable to connect, there is no way to tell whether the
> failure is temporary or permanent, short of repeated retries.
>
> As a result, if a user attempts to send mail to a mistyped domain, it
> can take up to a week (the recommended retry limit) to get back a
> failure report. �In principle, a domain could set up a stub mail
> server that accepted connections and immediately rejected delivery
> attempts, but that is more work than most domains want to do. �Hence
> our goal is to provide a cheap way to quickly tell senders not to
> bother. �(Note that an SPF record with "-all" says that a domain sends
> no mail, which is not necessarily the same as receiving no mail.)
>
> We propose that an MX record pointing to the root of the DNS, known as
> "MX ." means the domain accepts no mail. �This approach has been used
> informally for almost a decade, with few if any problems, but has
> never been described in an IETF document. �We propose only to assign
> the no-mail semantics to "MX ." and not make any other changes to
> SMTP.
>
> There is one draft to adopt: draft-delany-nullmx, to be submitted to
> the IESG by the end of May, 2014.
>
> The following have committed to work on the document through to
> publication:
>
> Murray Kucherawy <[e-mail] <mailto:[e-mail]>>
> Dave Crocker <[e-mail] <mailto:[e-mail]>>
> Terry Zink <[e-mail]
> <mailto:[e-mail]>>
> Arnt Gulbrandsend <[e-mail]
> <mailto:[e-mail]>>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>