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

S Moonesamy <> Tue, 15 November 2011 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A29321F8F77 for <>; Tue, 15 Nov 2011 00:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.296
X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dZpXjqR8I2hZ for <>; Tue, 15 Nov 2011 00:39:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 766C121F8DE9 for <>; Tue, 15 Nov 2011 00:39:31 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id pAF8dLDl002905; Tue, 15 Nov 2011 00:39:25 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1321346366; bh=nNsCVuXMLEvPzRMkrJ/xS7K2QeI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tBgguyjQX15vsAOc+OYVHmcrurFtFIsynZ93q9mjIi551yneWBxOZUsCfY4ETTCnN nNGpHckmuOhNnwa+IupIawUGC0xYxFe2LR3BsNWaaZOOyShXGDK1pjL6ujpIpXhlgY ItbYuhcWOEpMZZQAjaCA9U35KNzyxi6j+30LPPjQ=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 15 Nov 2011 00:38:49 -0800
To: "Murray S. Kucherawy" <>
From: S Moonesamy <>
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2011 08:39:35 -0000

Hi Murray,
At 07:04 PM 11/14/2011, Murray S. Kucherawy wrote:
>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 

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

I'll leave this comment open.

>Also, I wonder if the v6ops "Happy Eyeballs" work might be an 
>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).


S. Moonesamy