Subject: Re: [apps-discuss] SMTP+IPV6

From: Dan Wing <[email-masked]>
Date: Fri, 15 Nov 2013 11:56:56 -0800

Thanks for forwarding a pointer to your new I-D, http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6-00.  A few comments:

   The sender-SMTP server first tries all the IP addresses (IPv4 and
   IPv6) with higher preference (lower number) before the IP addresses
   with lower preference (higher number).  The sender-SMTP server tries
   all the addresses up to a limit before deciding if the message is
   deliverable or not.  The sender-SMTP server tries at least two
   addresses in each IP familly it is enabled (2 IPv4 addresses if IPv4
   capable and 2 IPv6 addresses if IPv6 capable).

Could that paragraph be edited for greater clarity?  I don't understand the interaction between the sender's limited number of addresses it tries and trying at least two addresses in each IP address family.  I believe the intent is that, prior to exhausting the limit of addresses it tries, it tries at least two addresses belonging to the 'other' address family.

   For the same MX RR preference, when there is more than one IP address
   (IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an internal
   sub preference list based on the rate of successful delivery of
   messages and based on the speed of such delivery.

I'm not too keen on measuring delivery speed.  How is delivery speed measured?  It can be throw off by a sender-SMTP sending a large message with a From address the receiver considers to have a poor reputation (which triggers more thorough spam checking on the receiver-SMTP and may well delay its response to the final dot), whereas that same sender-SMTP might send a short message with a From address the receiver considers to have a good reputation.  Is this delivery speed prioritization necessary for proper operation of IPv4/IPv6 selection?  I have not been deeply involved in SMTP in years, so perhaps this sort of delivery speed is used by high-end sender-SMTPs already and is state-of-the-art, but it seems an optimization that is unnecessary for v4/v6 selection.

   If such internal
   sub preference list is not established or cannot be established then
   the sender-SMTP tries randomly any address within the same
   preference.

This implies the sender-SMTP is prohibited (or discouraged?) from following the OS's configured IP preference table (RFC6724 / RFC3484).  I don't think that is desirable or the intent.

   In some ways, this strategy is similar to the Happy
   Eveballs [RFC6555] strategy where web browsers initiate parralel
   connections to web servers using IPv4 and IPv6 and select the
   connection with better response. 

The Happy Eyeballs RFC doesn't set up parallel connections.  You might be confusing Apple's implementation with the Happy Eyeballs RFC.  Apple's implementation does perform parallel connections when it has not yet established a history for its network (or if the history has decayed).  After Apple's implementation has established some information on v6 and v4 performance for that network, it reduces its aggressiveness and no longer does parallel connections.  It does periodically re-check its assumptions because IPv6 or IPv4 performance can improve or degrade over time, much like path MTU can improve or degrade over time.

-d

---

From: Franck Martin <[email-masked]>
Date: Fri, 15 Nov 2013 16:29:05 -0600 (CST)

----- Original Message -----
> From: "Dan Wing" <[email-masked]>
> To: [email-masked]
> Cc: "Franck Martin" <[email-masked]>
> Sent: Friday, November 15, 2013 11:56:56 AM
> Subject: Re: SMTP+IPV6
> 
> Thanks for forwarding a pointer to your new I-D,
> http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6-00.
> A few comments:
> 
> 
> Could that paragraph be edited for greater clarity?  I don't understand the
> interaction between the sender's limited number of addresses it tries and
> trying at least two addresses in each IP address family.  I believe the
> intent is that, prior to exhausting the limit of addresses it tries, it
> tries at least two addresses belonging to the 'other' address family.

yes, do you have text to propose?

> I'm not too keen on measuring delivery speed.  How is delivery speed
> measured?  It can be throw off by a sender-SMTP sending a large message with
> a From address the receiver considers to have a poor reputation (which
> triggers more thorough spam checking on the receiver-SMTP and may well delay
> its response to the final dot), whereas that same sender-SMTP might send a
> short message with a From address the receiver considers to have a good
> reputation.  Is this delivery speed prioritization necessary for proper
> operation of IPv4/IPv6 selection?  I have not been deeply involved in SMTP
> in years, so perhaps this sort of delivery speed is used by high-end
> sender-SMTPs already and is state-of-the-art, but it seems an optimization
> that is unnecessary for v4/v6 selection.
> 
> 
I don't want to suggest any method, just saying that building a sub preference list based on some criteria (such as) is useful. I'll make it clearer.

The MTA needs to remember which MX it tried for each message, some MX never works for some domains, so keeping this info cached, improve delivery. 

> This implies the sender-SMTP is prohibited (or discouraged?) from following
> the OS's configured IP preference table (RFC6724 / RFC3484).  I don't think
> that is desirable or the intent.
> 

Well this could be another criteria to build the sub preference list. It depends how much statefullness you want to code...

It seems to me we are moving from the OS IP preference to the application IP preference, as the application knows better what works for it than the OS.

> The Happy Eyeballs RFC doesn't set up parallel connections.  You might be
> confusing Apple's implementation with the Happy Eyeballs RFC.  Apple's
> implementation does perform parallel connections when it has not yet
> established a history for its network (or if the history has decayed).
> After Apple's implementation has established some information on v6 and v4
> performance for that network, it reduces its aggressiveness and no longer
> does parallel connections.  It does periodically re-check its assumptions
> because IPv6 or IPv4 performance can improve or degrade over time, much like
> path MTU can improve or degrade over time.
> 

Yes, mixed up a bit eyeballs with Safari strategy, but the idea remains the same for both, find which one works best and remember it.

---

From: Dan Wing <[email-masked]>
Date: Fri, 15 Nov 2013 15:47:37 -0800

> yes, do you have text to propose?

"The sender-SMTP obtains that list of MX records and sorts them in MX preference order (highest preference has lowest MX value), as described in Section 5.1 of [RFC5321].  After sorting, each of these hostnames is resolved for its IPv6 and IPv4 addresses, and the IPv6 or IPv4 addresses for that host are sorted following the application configuration, recognition of an easily reached address, or the operating system's address selection [RFC6724].  Most sender-SMTP limit the number of IP addresses that will be tried for each MX record.  For each MX record, the sender-SMTP SHOULD ensure that at least two IP addresses of the other address family are tried before that limit.

For example if a DNS zone might be configured as follows:

  IN      MX     10  mail1
  IN      MX     20  mail2
  mail1 IN      A     192.0.2.1
  mail1 IN      A     192.0.2.2
  mail1 IN      A     192.0.2.3
  mail1 IN      A     192.0.2.4
  mail1 IN      A     192.0.2.5
  mail1 IN      A     192.0.2.6
  mail1 IN      AAAA  2001:db8::1
  mail1 IN      AAAA  2001:db8::2
  mail1 IN      AAAA  2001:db8::3
  mail1 IN      AAAA  2001:db8::4
  mail1 IN      AAAA  2001:db8::5
  mail1 IN      AAAA  2001:db8::6
  mail2 IN      A     192.0.2.100
  mail2 IN      AAAA  2001:db8::100

the sender-SMTP would prefer mail1 (preference 10) and then mail2 (preference
20).  An SMTP-server implementation that does not implementation this specification
and has a 6 address limit per MX record and [RFC6724] default address preference, 
would attempt to connect to the 6 IPv6 addresses belonging to mail1.  If the IPv6 path
is broken, these connection attempts would all fail (after a timeout), as would the 
connection attempt to mail2's IPv6 address.  Finally, after those connection timeouts,
the IPv4 address for mail2 would succeed.

In contrast, an SMTP-server which is following the normative procedure above would
succeed in connecting to mail1 if the IPv4 path is working but the IPv6 path is broken.
This SMTP-server implementation would attempt to connect to the four IPv6 addresses 
belonging to mail1 and then to the IPv4 addresses belonging to mail2 -- resulting
in mail delivery to mail1 (which is preferable for the receiving
domain) and faster mail delivery.  Following the procedure above
with a 6 address limit per MX record and [RFC6724] default address
preference, the connections attempted would be:

  2001:db8::1   ; mail1, connection attempt 1
  2001:db8::2   ; mail1, connection attempt 2
  2001:db8::3   ; mail1, connection attempt 3
  2001:db8::4   ; mail1, connection attempt 4
  192.0.2.1     ; mail1, connection attempt 5 (IPv4)
  192.0.2.2     ; mail1, connection attempt 6 (IPv4)
  ; the other addresses for mail1 are not used by this particular
  ; sender-SMTP because of its 6 address limit per MX record.
  2001:db8::100 ; mail2, connection attempt 1 (IPv6)
  192.0.2.100   ; mail2, connection attempt 2 (IPv4)

The following paragraph from [RFC5321] remains important for implementations:
  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."

> I don't want to suggest any method, just saying that building a sub preference list based on some criteria (such as) is useful. I'll make it clearer.

Suggest:  "(e.g., by recognition of a well-performing address)"

> It seems to me we are moving from the OS IP preference to the application IP preference, as the application knows better what works for it than the OS.

Decay is important, though.  Without decay, an hour-long IPv6 hiccup on Tuesday will have effects for weeks afterwards.

Suggest:
  "Network paths and servers are constantly breaking and being repaired.  Thus, implementations MUST occasionally age out their IPv6 or IPv4 preferences.  It is RECOMMENDED that this information be aged out every 4 hours."

> Yes, mixed up a bit eyeballs with Safari strategy, but the idea remains the same for both, find which one works best and remember it.

Okay.

-d

---

From: Ned Freed <[email-masked]>
Date: Sat, 16 Nov 2013 19:09:55 -0800 (PST)

> http://tools.ietf.org/html/draft-martin-

> trying at least two addresses in each IP address family.  I believe the intent
> is that, prior to exhausting the limit of addresses it tries, it tries at least
> two addresses belonging to the 'other' address family.

It should also be stated explicitly that clever tricks like trying multiple
addresses at once may not be such a swell idea in the case of SMTP. This sort
of thing increases the liklihood of running afoul of server-side restrictions.

> measured?  It can be throw off by a sender-SMTP sending a large message with a
> From address the receiver considers to have a poor reputation (which triggers
> more thorough spam checking on the receiver-SMTP and may well delay its
> response to the final dot), whereas that same sender-SMTP might send a short
> message with a From address the receiver considers to have a good reputation. 
> Is this delivery speed prioritization necessary for proper operation of
> IPv4/IPv6 selection?  I have not been deeply involved in SMTP in years, so
> perhaps this sort of delivery speed is used by high-end sender-SMTPs already
> and is state-of-the-art, but it seems an optimization that is unnecessary for
> v4/v6 selection.

I most emphatically agree. This is basically asking people to implement things
in ways that sooner or later will have a bad interaction with something
out there, leading to problems that are very difficult to track down.

Keeping track of which addresses work and which don't is fine and should
be encouraged, tracking speed is not.

> that is desirable or the intent.

I don't think that was the intent, but then again, I'm a little unclear on
how RFC 6724 is supposed to interact with application selection of what
address to use.

				Ned