Subject: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Nov 2011 14:35:02 -0800

Hello,

I would appreciate some feedback on 
draft-moonesamy-smtp-ipv6-00.  The I-D discusses about SMTP in an 
IPv4/IPv6 dual stack environment.  It documents the algorithm 
initially specified in RFC 3974 which is used in several SMTP implementations.

The change from RFC 3974 is:

  - Removal of the Basic DNS Resource Record Definitions for Mail 
Routing section

  - Removal of the SMTP Sender Algorithm in a Dual-Stack Environment section

  - Removal of the Operational Experience and open issues sections.

  - RFC 5321 remains authoritative for SMTP

Please note that the algorithm has already been used in several 
existing implementations.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 15 Nov 2011 02:57:46 -0000

Looks mostly reasonable.

In step (9), you say "If a transient failure condition is reported,
try the next MX RR" which looks wrong to me.  If you get a 4xx, you
requeue the message and try it again later.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2011 19:04:37 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Monday, November 14, 2011 2:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
> 

Why were these removed?  They seemed useful for illustration in RFC3974.

>   - Removal of the Operational Experience and open issues sections.

Replacing this with more current operational experience might be better than removing it outright.

Also, I wonder if the v6ops "Happy Eyeballs" work might be an interesting reference here.

> existing implementations.

Excellent.

RFC5321 talked about aspects of RFC3974 that were in conflict with what RFC5321 says.  Have those been resolved in your draft?  (Alas, I can't tell after a cursory read what those might've been.  Maybe it's simply the thing John Levine just pointed out in another message.)

It's worth pointing out the document state change as well (which I support).

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 14 Nov 2011 20:46:25 -0800

Hi John,
>Looks mostly reasonable.

Thanks for the feedback.

>requeue the message and try it again later.

I agree that it looks wrong.  I was going to suggest "going to Step 
7" instead of Step 3.  The problem though is that you cannot retry 
against the same IP address in all cases as you have to take into 
account the DNS TTL.  The workaround I see is:

(9)  Attempt to deliver the email over the connection established, as
      specified in RFC 5321.  If a transient failure condition is
      reported, try again as defined in RFC 5321 Section 4.5.4.1.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Nov 2011 00:38:49 -0800

Hi Murray,
>Why were these removed?  They seemed useful for illustration in RFC3974.

RFC 3974 has an IESG Note about a specific interpretation of the 
applicability of the MX processing algorithm in RFC 2821.  You may 
have noticed that MX processing and sending strategy are kept 
separate in RFC 5321.  The illustration is based on a specific 
reading/interpretation of the SMTP specification and that can open 
the way for ancillary problems, e.g. less leeway for operational 
considerations.

>better than removing it outright.

I'll leave this comment open.

>interesting reference here.

SMTP is not affected by the happy eyeball problem.  Getting this 
message to you 50 ms earlier would not make that much of a difference.

>RFC5321 talked about aspects of RFC3974 that were in conflict with 
>what RFC5321 says.  Have those been resolved in your draft?  (Alas, 
>I can't tell after a cursory read what those might've been.  Maybe 
>it's simply the thing John Levine just pointed out in another message.)

John Levine pointed out one of the issues.  A clear resolution of all 
the aspects would require removal of the algorithm.  The path I 
picked is to try to align the algorithm with RFC 5321.

>It's worth pointing out the document state change as well (which I support).

Ok.

Regards,
S. Moonesamy

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Nov 2011 10:59:11 +0000

> requeue the message and try it again later.

This is a point of repeated disagreement and there is no accepted
consensus. When they get a 4yz, some SMTP implementations will immediately
re-try delivery on the other hosts, and only queue the message for later
delivery if none of the hosts will take the message.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Southeasterly 5 to 7, veering southwesterly 4 or 5 in west. Moderate
or rough. Rain or showers. Moderate or poor, occasionally good later.

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Nov 2011 11:12:11 +0000

John R. Levine <[email-masked]> wrote:
>
> Ah, right.  Can you suggest language that means "if you get a 4yz do whatever
> you do now."

It's already specified in RFC 5321:

   Although the capability to try multiple alternative addresses is
   required, specific installations may want to limit or disable the use
   of alternative addresses.  The question of whether a sender should
   attempt retries using the different addresses of a multihomed host
   has been controversial.  The main argument for using the multiple
   addresses is that it maximizes the probability of timely delivery,
   and indeed sometimes the probability of any delivery; the counter-
   argument is that it may result in unnecessary resource use.  Note
   that resource use is also strongly determined by the sending strategy
   discussed in Section 4.5.4.1.

I'm not sure what SM's draft is for, since RFC 3974 is obsoleted by RFC 5321
(even though the RFC index fails to say so).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Westerly or northwesterly 4 or 5, occasionally 6 in north at first,
becoming variable 3 later. Rough, occasionally moderate later. Thundery
showers. Moderate or good, occasionally poor.

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Nov 2011 09:40:25 -0800 (PST)

> delivery if none of the hosts will take the message.

The point in the dialogue at which the 4yz is returned can also be a factor.
It's one thing to retry on a different A after getting a 4yz host temporarily
unavailable response to EHLO; it's rather different to retry a different A
after getting a 4yz user is over quota response to the final dot.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 20:19:50 +0100

On 15 November 2011 12:12, Tony Finch wrote:

> RFC 3974 is obsoleted by RFC 5321 (even though the RFC index fails
> to say so).

The first page of RFC 5321 doesn't confirm that theory, there is no
"obsoletes 3974".  Maybe 5321bis could state this explicitly.

It would be nice to have both, an official STD 10 fresher than 821,
and an informational companion obsoleting 3974 with the dual stack
example.

-Frank

"In any case, the SMTP adds its own identifier to the reverse-path"

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Nov 2011 19:25:32 +0000

> and an informational companion obsoleting 3974 with the dual stack

WRT sual stack, what is missing from section 5 of RFC 5321?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty: Southerly or
southeasterly 4 or 5, occasionally 6 in Cromarty. Slight or moderate.
Occasional drizzle. Moderate or good.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 20:39:45 +0100

> WRT sual stack, what is missing from section 5 of RFC 5321?

The simple step-by-step "how to" is missing, or rather, because 5321
is already long enough I don't miss it _in_ RFC 5321.  But I'd like
an external text with "ESMTP IPv6 considerations" not limited to the
3974 business.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2011 13:28:20 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ned Freed
> Sent: Tuesday, November 15, 2011 9:40 AM
> To: Tony Finch
> Cc: [email-masked]; [email-masked]
> Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
> 
> It's one thing to retry on a different A after getting a 4yz host
> temporarily unavailable response to EHLO; it's rather different to
> retry a different A after getting a 4yz user is over quota response to
> the final dot.

I thought the theory was that you only try different As or lower-precedence MXs if you fail completely to make an SMTP connection.  That is, if you get any 4yz reply at all, you stop there and requeue; if you get any 2yz or 5yz reply at all, you're done.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 16 Nov 2011 05:51:05 +0800

Folks,

> (even though the RFC index fails to say so).

I would like to see some very explicit discussion and reasonably clear consensus 
that answers this question.

By explicit, I mean specification of what details need to be covered that are 
not covered by 5321 (and to help get the consensus, what details in the new 
draft are redundant with which details in 5321.)

It seems to me something close to a absolute rule that the document MUST NOT 
replicate specification already in a standards track document, but rather must 
simply cite it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John R. Levine" <[email-masked]>
Date: 15 Nov 2011 17:44:01 +0800

>     reported, try again as defined in RFC 5321 Section 4.5.4.1.

That seems reasonably aligned with reality.  Different MTAs have rather 
different retry strategies, both different timeouts, and different rules 
for how they retry, e.g., retry the same target host, retry starting at 
the same MX distance, retry from scratch.  Whether some or all of the 
hosts are on IPv6 doesn't change any of that.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "John R. Levine" <[email-masked]>
Date: 15 Nov 2011 19:04:28 +0800

> delivery if none of the hosts will take the message.

Ah, right.  Can you suggest language that means "if you get a 4yz do 
whatever you do now."

Regards,

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Nov 2011 15:20:18 -0800 (PST)

> I thought the theory was that you only try different As or lower-precedence
> MXs if you fail completely to make an SMTP connection.

That's *a* theory. It is not *the* theory. Plenty of MTAs - in fact it seems to
be a significant percentage of them - don't work this way. Some will move on to
other MXes even if the failure occurs during inside the actual transaction. (I
happen to think this last extreme is wrong, but that's *my* theory for how this
should be done; it's not prohibited by any standard I'm aware of.)

> That is, if you get any 4yz reply at all, you stop there and requeue; if you
> get any 2yz or 5yz reply at all, you're done.

I think a pretty good case can be made for trying secondary MXes when the
banner response is a 4yz.

				Ned