Re: Review Requested: SMTP IPv6 operational experience document

[Dean Strik <dean@ipnet6.org>]

Pekka Savola wrote:
> Hello all,
> 
> (co-chair hat on)
> 
> The working group has been asked by our Area Director to review the 
> recently-revised SMTP operational experience document before it's 
> published as an individual submission:
> 
>    draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt
> 
> Please send comments, preferably in a week, by 26th January, either to
> the v6ops list (preferable), or directly to itojun (acting as the
> editor) and the chairs.

MAJOR

1) Section 2, second paragraph: "IP addresses for the destination host
are also looked up to make SMTP transport." This is incomplete. This
could refer to either of (a) or (b): (a) If no MX record is found, an A
lookup is done for the domain part of the mail address to find a mail
exchanger host; (b) IP(v*) lookups are then done, using A/AAAA, for each
mail exchanger found by MX lookups.
This needs clarification.

2) Section 3, paragraph "The algorithm for an SMTP server" (see also
under MINOR 7): "When there is no reachable desti[o]nation address
record found [..], the case should be treated just like MX records
without address records [..]".

This is simply wrong. There are two issues with this. First, "reachable"
isn't properly defined. For example, a network outage (and the implied
unreachability when contacting the host) is not a reason to pretend the
host did not have MX addresses specified. It must be made clear that
this special treatise (pretend there are no MX records) should only be
applied if the host address cannot be reached due to network layer
incompatibility.

Second, is that this text says that, if no addresses are reachable (with
the constraint above), it should be treated as if no MX records were
specified. This leaves the possibility for mail to be delivered
incorrectly. While this is the current situation, I would like to
propose a different approach, more in the spirit of the IPv4->IPv6
transition. Namely, I suggest that IPv6-only senders will bail out if
the destination is unreachable, instead of pretending there were no
MX RRs. I think it is acceptable to ask IPv6-enabled ("modern") servers
to avoid misdelivery (in SMTP, erroring is generally better than
providing an uncertain path), while only legacy IPv4-only servers can
treat IPv6-only hosts as MX-less.

I see the ugly lack of symmetry here. Yet I don't think we should impose
the chance of possible misdelivery (through the wrong host) on modern
systems. We can do this on legacy systems since it's effectively what
happens now, without this spec.

This conforms more with the following from RFC 2821, Section 5:
    "If MX records are present, but none of them are usable, this
    situation MUST be reported as an error."

This may be a little bit vague. If unclear, please let me know.

3) The example DNS configuration just below, has a "HINFO" record. This
should be a TXT record. If any. It's redundant, and the document
provides no explanation for the purpose of this RR.

4) Step (1) of the dual-stack SMTP sending algorithm doesn't specify the
actions to take when a SERVFAIL is encountered.

5) In step (2) of the SMTP sender algorithm (section 3), I suggest we
say "Compare each host name in MX records with the names of the sending
host. If there is any match, [..]". (A host can have multiple names, at
least in this mail delivery context.)

6) Step (2) lacks a comparison (and a few words). It should say, "drop
all MX records which have equal to or larger than preference value
[than the preference value of] *the lowest-preference matching MX*".
(Alternatively, perform a sorting on preference before trying to match,
and then iterate the list in order of ascending MX preference values).

7) Step (5), the "NOTE" paragraph is slightly arbitrary in its use of
guideline words ("optional", "may", "should"). I suggest changing the
text

    "If one or more address records are found, some MTA implementations
    may sort addresses based on based on the implementation's preference
    to A or AAAA records."
to
    "An implementation MAY sort addresses based on the implementation's
    preference to A or AAAA records."
and to drop the trailing line
    "But this type of sorting is optional."

I also would like to see a clarification that this sorting may only
reorder addresses from MX records of the same preference! Address family
preference can't be more important than MX preference value.

8) The conclusion in the example in the last paragraph of section 4,
(from "It is also possible[..]") "In such cases, [a] dual-stack MX host
may not be listed in the MX list". This is incorrect, it doesn't follow
from the example. I'm not sure what to replace it with. Perhaps removal
is better.

9) In the first paragraph of section 5, the text says there were
SERVFAIL errors "when attempting to obtain a canonical hostname [..] on
AAAA record lookups".
This is unclear to me. Doing a T_AAAA lookup is outside the scope of
this document. Doing any lookup resulting in a canonical hostname should
be independent of IPv6 or IPv4/v6 interop.
Unfortunately, the referenced draft is gone.

10) In section 6, "Open issues", first item (scoped addresses in email
addresses). The suggestion (which is of no consequence other than the
notion, btw) speaks of "source routes" only. Do you mean "address
literals as destination domains"? If so, please correct. If not, I would
suggest to drop the source routes from this.

MINOR

0) Throughout the document, usage of 'may', 'should', etc. are used.
Perhaps these should be capitalized and strengthened as per RFC 2119?

1) In the Abstract, there is the sentence

    As IPv6-capable SMTP servers are deployed, it has become apparent
    that certain configurations are necessary for IPv6-capable MX
    records for stable dual-stack (IPv4 and IPv6) SMTP operation.

Since there's no such thing as 'IPv6-capable MX records', I suggest
changing this to something like this:

    As IPv6-capable SMTP servers are deployed, it has become apparent
    that certain configurations of MX records are necessary for stable
    dual-stack (IPv4 and IPv6) SMTP operation.

2) I suggest removing the second paragraph from section one, or merging
this with the last section, as they cover the same subject (the draft
not being about single-stack systems).

3) Section 2, first paragraph: Add a reference to the DNS RFC?

4) Section 2, first paragraph: "domain name system" -> "the Domain Name
System (DNS) [Reference]". "MX RRs are looked up to know destination
hosts" -> "MX RRs are looked up in DNS to retrieve the names of hosts
running MTAs associated with the domain part of the mail address".

5) Section 2, second paragraph: "In IPv4 environment, IPv4 IP addresses
are defined with A RRs". Please remove this line. It's not relevant, the
first part is extremely gratuitous, and the statement is incorrect as
well.

6) Section 2, paragraph "But, every host may not support dual stack
operation, some host entries may have only IPv4 or IPv6 RRs:", replace by "But,
not every MX target may support dual-stack operation. Some MX targets
may have only A RRs or AAAA RRs:".

7) Section 3, paragraph "The algorithm for an SMTP sender is basically
the same as for an IPv4-only sender". Change "SMTP sender" to
"dual-stack SMTP sender".

8) Section 3, algorithm, step (3) and (4): lookup A/AAAA *recordS*
(plural).

9) Step (5); "No A or AAAA" is somewhat ambiguous. Instead, use
"no A and no AAAA".

10) In section 4.1 we find the first use of a capitalized "SHOULD". This
is not encountered anywhere else.

11) I'm not too happy about the wording of section 7 (Security
considerations), esp. the rather imperfect sentence "MTA's would need to
reject email with improper route-addr email address formats." The terms
"route-addr", "improper" and "email address format" are not well-defined
here.

12) In the References, the Morishita/Jinmei draft "Common misbehavior
against DNS Queries for IPv6 Addresses" is no longer available, so
should not be referenced (certainly not by filename).

SPELLING & GRAMMAR, MINOR MINOR

0) The document sometimes spells "IPv4/v6" and sometimes "IPv4/IPv6". A
consistent notation is better. (I use "IPv4/v6", which is used more
often in this document, in the rest of my comments").

1) The title in the document misspells 'environments' (environements)

2) Section 1, first paragraph: "submiter" -> "submitter"; "to configure
all the system" -> "to configure all systems".

3) Section 1, first paragraph: "since mail message delivery system is
rather complex on DNS setting than other Internet services". I suggest
something like, "since the DNS configuration used by mail message
delivery systems is more complex than other Internet services".

4) Section 1, first paragraph: "For the transition sate from IPv4 to
IPv6, both IPv4 and IPv6 interoperability should be kept more
carefully." Suggestion: something like "During the transition period from
IPv4 to IPv6, more care should be applied to IPv4/v6 interoperability."

5) The first sentence of the third paragraph of section 1 ("IPv6-only
MTA [..]") could be slightly reworded (grammar).

6) In section 2, paragraph "In transition period from IPv4 [..]",
replace "many IPv4 sites" by "many IPv4-only sites" (only these have
no interoperability of course).

7) Section 2, last paragraph: replace paragraph by grammatrically better
"The following sections discuss how the sender side should operate with
IPv4/v6 combined RRs (section 3) and how the receiver should define RRs
to maintain interoperability between IPv4 and IPv6 networks (section
4)."

8) Section 3, paragraph "For a single MX record, there are mnay possible
final states". There are 3, not many :) I also recommend changing "final
states" into something else.

9) Paragraph "The algorithm for an SMTP sender":
   "destionation" -> "destination".

Cheers,
Dean

-- 
Dean C. Strik             Eindhoven University of Technology
dean@stack.nl  |  dean@ipnet6.org  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli