Subject: Review Requested: SMTP IPv6 operational experience document

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Jan 2004 22:30:03 +0200 (EET)

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.

Thanks,
 Pekka & Jonne
  v6ops co-chairs

---

From: Dean Strik <[email-masked]>
Date: Fri, 23 Jan 2004 22:26:18 +0100

> the v6ops list (preferable), or directly to itojun (acting as the

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
[email-masked]  |  [email-masked]  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jan 2004 15:02:35 +0200 (EET)

Nice to see that Dean made an indepth review of the draft.

Here's my review as an individual WG member.

> the v6ops list (preferable), or directly to itojun (acting as the

First, I have to say that the beginning of the document (up to section
3 or so), is in an AWFUL English shape.  Please review those in
detail, even though I mention many of the editorial problems.  

I assume that this draft is going for Informational (and not e.g.  
BCP).

bigger issues
-------------

IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] , however, there are no special SMTP
considerations for translators needed; If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.  Protocols like IDENT
[St.Johns, 1993] as well as SMTP HELO/EHLO may require special
consideration when translators are used.

==> the latter, esp. SMTP EHLO/HELO is pretty important part of the
scope of this document (aren't we interested of SMTP?), so it should
probably elaborated a bit more.

...

There are several technologies defined for the transition from IPv4 to
IPv6.  This document concentrates on SMTP issues in a dual-stack
environment, e.g. delivery of emails from IPv6-only MTA to IPv4-only MTA
is outside of the scope of the document.

IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] , however, there are no special SMTP
considerations for translators needed; If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.  Protocols like IDENT
[St.Johns, 1993] as well as SMTP HELO/EHLO may require special
consideration when translators are used.

The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist in a dual-stack environment.

This document does not discuss the problems encountered when the sending
MTA and the receiving MTA have no common protocol (e.g. the sending MTA
is IPv4-only while the receiving MTA is IPv6-only).  Such a situation
should be resolved by making either side dual-stack or by making either
side use a protocol translator.

==> 1, 2 and 4th paragraph seem to be slightly at odds with each another, 
and the third seems out of place.  One should unify the text a bit, e.g.,
officially include discussion of the translators (etc.) or put them in an 
Appendix and refer to that in the introduction.

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2

==> the IPv6 examples should use something more closely resemling a 
"documentation prefix", at this time, the closest would probably be
2001:db8::/32.

4.  MX configuration in the recipient domain

4.1.  Ensuring reachability for both protocol versions

If a site has dual-stack reachability, the site SHOULD configure both A
and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the
site).  This will help both IPv4 and IPv6 senders to reach the site
efficiently.

==> you use uppercase keyword, but don't define them.  However, for an
operational document (and not a protocol specification, with
interoperability requirements) like this, it would be better to not
use them at all, i.e., s/SHOULD/should/ or the like.

7.  Security considerations

It could be problematic if the route-addr email address format is used
across multiple scope zones.  MTA's would need to reject email with
improper route-addr email address formats.

==> this is the first time you mention "route-addr".  You should provide a 
bit more background to this issue.

References

==> these have to be split to informative and normative.  Also note that an RFC 
obsoleting RFC1886 has been published.

==> this draft should also include the IPR and the copyrights sections at the end.

editorial issues
----------------

==> it would be nice if the text in the sections was indented a couple 
of spaces, for readibility, but this is OK as is too.

      SMTP operational experience in mixed IPv4/IPv6 environements

==> uppercase, s/ements/ments/

This document talks about SMTP operational experiences in IPv4/v6 dual

==> might be worth spelling out SMTP, even though everybody probably knows it..

Deliveries of mail messages to the final mail drop is not always done by

==> s/Deliveries/Delivery/ ?

direct IP communication with submiter and final receiver, and there may

==> s/submiter/submitter/, add "the" times ?

It is not so easy to configure all
the system with consistency since mail message delivery system is rather

==> s/system/systems/, maybe s/with consistency/consistently/ ?

complex on DNS setting than other Internet services.  For the transition

==> s/setting/settings/

For the transition
state from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be
kept more carefully.

==> the latter part of the sentence "kept more carefully" is barely 
english, please reword? :-)

Mail messages on the Internet are delivered based on domain name system
generally. 

==> s/delivered ... generally/typically delivered .../ ?

with domain part of a mail addresse.

==> s/addresse/address/

Similar to the way RFC's for IPv6
DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX
records will be used for both IPv4 and IPv6 on mail message routing,
hosts which have IPv6 transport and want to be delivered with the IPv6
transport must define IPv6 IP addresses for the host name as well as
IPv4 IP addresses.

==> want *what* to be _delivered with_?  Bad english, please reword, e.g.:

DNS lookup [Thomson, 1995] uses IN class for both IPv4 and IPv6 and 
similarly IN MX records will be used for mail routing for both IPv4 
and IPv6.  Hosts which have IPv6 connectivity and want to have the
mails delivered also using IPv6 must define IPv6 addresses for 
the host name as well as IPv4 addresses.

A MX RR have two data, a preference value and the name of destination
host.

==> s/have two data/has two arguments/ ?

IP addresses for the destination host are also looked up to make
SMTP transport [Partridge, 1986] .

==> s/ ././, s/make SMTP transport/initiate SMTP connection/ ?

In the following sections, how sender side operates with IPv4/IPv6
combined RR definitions (section 3), and how receiver side should define
RRs to keep interoperability with both IPv4 and IPv6 Internet (section
4) are considerd.

==> Start like "In the following section we consider how ..." 

     NOTE: IPv6 addresses for hosts defined by MX records may be
     informed in additional information section of DNS querie's result

==> s/querie's/query's/ or s/querie's/queries'/

    reachable and if a list of MX records is being traversed, try the
     next MX record (go to step (3)).  If there is no list of MX

==> s/))/)/

       condision reported, try the next MX record (go to step (3)).  If an

==> s/condision/condition/

6.  Open issues

o The document should really be integrated into RFC2821 [Klensin, 2001]
  (i.e. RFC2821 should talk about IPv6 cases).

==> I'd reword this a bit, like:

o A future specification of SMTP should be updated to include the 
  information in this memo.

Change history

==> Here you could add something like:

  [[ RFC-Editor: please remove before publication ]]

Author's address

==> replace with Authors' Addresses

2.  Basic DNS resource record definitions for mail routing
3.  SMTP sender algorithm in a dual-stack environment
4.  MX configuration in the recipient domain
4.1.  Ensuring reachability for both protocol versions
4.2.  Reachability between the primary and secondary MX
5.  Operational experience
6.  Open issues

==> The section titles and the document title should be 
"first-character uppercased", like:

2.  Basic DNS Resource Record Definitions for Mail Routing
3.  SMTP Sender Algorithm in a Dual-stack Environment
4.  MX Configuration in the Recipient Domain
4.1.  Ensuring Reachability for Both Protocol Versions
4.2.  Reachability Between the Primary and Secondary MX
5.  Operational Experience
6.  Open Issues

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 26 Jan 2004 22:13:29 +0900 (JST)

> ==> this draft should also include the IPR and the copyrights sections at the end.

	in my understanding (and from past experience) copyright section is
	added by RFC editor, am I right?  and is IPR section mandatory?
	(from my past experience it was not)

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jan 2004 15:17:47 +0200 (EET)

> 	(from my past experience it was not)

Both will be added by RFC editor, if they are missing, but it might be
good practice to include them anyway (in case someone who doens't know
the Internet-Draft copyright status reads them before the
publication).  The IPR section is not so important in the
Informational operational documents for which it's pretty rare anybody
claims IPR for, though (which is why the IPR issue is not usually
considered a "hard rule" for Info documents)..

Hopefully this clarified at least my understanding of the document
"form" procedures.

---

From: Dean Strik <[email-masked]>
Date: Thu, 29 Jan 2004 19:13:04 +0100

> >    draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt

There's one more small thing, which I didn't discuss in my earlier
comments. I quote from the draft, section 3, the dual-stack algorithm:
there's a note between steps (5) and (6), reading:

     NOTE: If one or more address records are found, some MTA
     implementation may sort addresses based on the implementation's
     preference of A or AAAA records.  To encourage the transition from
     IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence.  But
     this type of sorting is optional.

I already said:

> reorder addresses from MX records of the same preference! Address
> family preference can't be more important than MX preference value.

According to RFC 2821, section 5, paragraph 4:

   Multiple MX records contain a preference indication that MUST be used
   in sorting (see below).  Lower numbers are more preferred than higher
   ones.  If there are multiple destinations with the same preference
   and there is no clear reason to favor one (e.g., by recognition of an
   easily-reached address), then the sender-SMTP MUST randomize them to
   spread the load across multiple mail exchangers for a specific
   organization.

Now, a dual-stack client has two sorting parameters. Maybe it would be
nice to specify in this note that this IPv6 preference may take
precedence over the randomization specified above (so first all IPv6
addresses are tried, then IPv4).

Currently, my own implementation lets IPv6 take precedence. I'll make
this configurable soon (mostly because people may want to have it
otherwise).

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 30 Jan 2004 09:47:26 +0900 (JST)

> > >    draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt

	thank you for numerous comments.  i will try to integrate those
	into the document and submit another i-d (under individual name
	instead of "ngtrans", as suggested by ADs).

> this configurable soon (mostly because people may want to have it

	from IPv6 transition POV IPv6 should take precedence.
	having knob would be good for early transition period, mainly due to
	the problems documented in
	draft-morishita-dnsop-misbehavior-against-aaaa-00.txt,
	but please make IPv6 to take precedence by default.

itojun

---

From: Dean Strik <[email-masked]>
Date: Fri, 30 Jan 2004 08:31:59 +0100

> 	but please make IPv6 to take precedence by default.

Yes, I had no intention to change the default.