On 7/25/2014 6:41 PM, Mark Andrews wrote:
In message <53d2dbec.6060...@isdg.net>, Hector Santos writes:
We will need to tweak the code or the retry frequency table for this
particular socket error, in this case 10061. To optimize, we will
need to specifically look for three conditions:
MX.Count == 1 and
MX[0].Preference == 0 and
MX[0].Exchange == "."
to trump, preempt any call attempt.
Nuke the preference check. Count and exchange is enough.
Hi Mark,
Sure, but its not the true "spec" condition. As stated in section 3,
anything else but the three conditions could be programmatically
extracted to be an "error" some where; an exception, indeterminate
condition, possible corruption, "not the spec condition," a "how can
this happen" situation. What does an diligent, high QA conscious coder do?
"Being Specific Is Terrific!"
If the preference can technically be any non-zero value for a No Mail
Service MX record, then the spec should probably make note of that in
section 3, otherwise a coder may wonder and add an exception.
3. MX Resource Records Specifying Null MX
To indicate that a domain does not accept email, it advertises a
single MX RR (see [RFC1035], section 3.3.9) with an RDATA section
consisting of a zero length label, written in master files as ".",
as the exchange domain, to denote that there exists no mail
exchanger for a domain. The Preference SHOULD be set to zero, but
implementators SHOULD NOT depend on it being zero for the NULL MX
to be defined.
Additional comments/nits about the draft:
o Preference vs Priority
An implementation note could be added:
Implementation note: Some DNS record UI managers use the term
"Priority" instead of "Preference." MX expansion requires a
sorted mail host order by increasing preference. The mail
host with lower preferences are tried first. A Higher priority
value in these UIs does not mean they are tried first.
The DNS management tools I just recently used (Microsoft DNS v5
Windows GUI manager and Godaddy's web-based DNS manager) to quickly
explore this used, the term "Priority" instead of the IETF spec
defined "Preference" term for this MX field name. The draft has no
reference to the term "priority" and/or the possible market,
administration and technical terminology discrepancies.
o No Permanent Blocks Semantics
I think the draft should make a note that permanent blocks should not
be extracted from an NULL MX records or the final resolution of
attempts. The NULL MX condition can quickly change at any time. It
is merely (to me, as I can see) an optimizer to short circuit an
outbound attempt and also test an incoming message return path domain
readiness for bounces/DSN which is a SMTP required mode of operation.
o Security overstatement
I think the security section does not need to be talking about SMTP
being 'inherently insecure." Whether a site does dynamic checking or
not of the SMTP session return path is the main thing here. This
draft isn't removing any insecurity other than suggesting it is one
way to detect the "mail hosting service availability" of an email
domain without the need to actually try/test it. An optimizer.
In fact, I think its possible that the attempt to define a NULL MX can
actually "nullify" and learned behaver for a Implicit MX logic where
there is no record at all. NULL MX is a real record and that can
trigger different logic than an real NO MX record condition. For
example, some MTA may have an option:
[X] NO MX, Try A record ONCE TIME
That was the case for our older version of MTA. The rule was relaxed
(default OFF) due to the false positives. So for the modern versions,
it doesn't matter anymore -- retries are based on the last SOCKET or
SMTP error condition.
--
HLS
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
