Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic

Hector Santos <hsantos@isdg.net> Thu, 21 June 2018 01:54 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A04130FE1 for <ietf@ietfa.amsl.com>; Wed, 20 Jun 2018 18:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=U0CYImbX; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=PvF57v25
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdHxCnuD1mpH for <ietf@ietfa.amsl.com>; Wed, 20 Jun 2018 18:53:58 -0700 (PDT)
Received: from catinthebox.net (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 986D7130FB1 for <ietf@ietf.org>; Wed, 20 Jun 2018 18:53:58 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2451; t=1529546030; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=1inEgoFQnFogMeshWyVJILVLE/Q=; b=U0CYImbXfAX5IbkK81PhlrULyb8WHv6jrA4mJ+YdJo3oWRWrGWBy3ji6xF7mPZ K08tovYCrekwRqD9pYB/lLT1MvuNoOw9bv/eq71ZiElmbnwFfw9Z0/h9TYE5evMJ ArvCKxKqNIw/Tn5vIYRdKV1OnAA8thXNnAu+0NJ/7RVK4=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf@ietf.org; Wed, 20 Jun 2018 21:53:50 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2234684596.1.8316; Wed, 20 Jun 2018 21:53:48 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2451; t=1529545476; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gwEFnac rbhXBdHvJtQrek7fQbv34CIo99wSpQegZ6+0=; b=PvF57v25MQj4RXBGBVccqL9 29P7vM/VSxOZsIFGmRriUVSkhThs8b4ezx6/Sosy7Qin0RCa8nLW4gIXihhUD7AX ORj1AsHDd8tYA6vbpfNFeK4euafbEjv3OfC+6S6jwkGdh6UeeZ7jFScAdt1i6EWL K05yHcSL1p07NVo8oQZE=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf@ietf.org; Wed, 20 Jun 2018 21:44:36 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2234446801.9.201456; Wed, 20 Jun 2018 21:44:34 -0400
Message-ID: <5B2B052A.4030403@isdg.net>
Date: Wed, 20 Jun 2018 21:53:46 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>, John C Klensin <john-ietf@jck.com>, iesg@ietf.org, ietf@ietf.org
CC: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic
References: <152588285893.3989.7909763661642193132.idtracker@ietfa.amsl.com> <6.2.5.6.2.20180619151759.0bf2c2b0@elandnews.com> <3679f35a-f6a8-47e9-9c0a-84b99a388855@isode.com> <6.2.5.6.2.20180620062609.08678c98@elandnews.com> <404d054e-d963-dd70-c9ae-f6ae4666797b@isode.com> <98F610E618E18B07B96C3BE8@PSB> <6.2.5.6.2.20180620141044.0be0c4c8@elandnews.com>
In-Reply-To: <6.2.5.6.2.20180620141044.0be0c4c8@elandnews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vAqWvzMca4-2_rsWsX_FRs4o9xI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2018 01:54:02 -0000

On 6/20/2018 5:32 PM, S Moonesamy wrote:
> Hi John,
> At 09:08 AM 20-06-2018, John C Klensin wrote:
>> While I agree that adding a note is reasonable and that
>> providing a reference to current status (as viewed from the
>> IETF's perspective) is probably more so, I think "defeats the
>> purpose" is wild hyperbole or worse.  There are actually two
>> goals of this registry.  One is simply to avoid inadvertent name
>> collisions and that certainly is not facilitated by hiding or
>> dropping names unless we somehow want to encourage their reuse.
>
> I did not suggest removing the entry as it might make it difficult for
> people to look up information about SMTP extensions.

My take, as probably one of the few server-side implementators of the 
SUBMITTER protocol.

SUBMITTER was an SenderID optimization protocol. Similar to SPF, 
SenderID was competing with SPF as a payload-based (RFC5322) SPF-like 
Protocol using the 5322.From for the IP::DOMAIN association DNS 
lookup, just like SPF.   The old MARID WG project initiated the 
experimental competition of the SPF, SENDERID/PRA/SUBMITTER proposed 
protocols.

SUBMITTER provided a way to pass the PRA (Purported Responsible 
Address) which was generally, the 5322.From field, at the SMTP MAIL 
FROM state, before the DATA payload was transferred.

Eventually, when SPF was updated, it won over SenderID, but if you 
implemented and enabled the SUBMITTER SMTP service extension, you will 
definitely see "many" SMTP clients issue the PRA at the MAIL FROM:

    MAIL FROM: <return-path> [SUBMITTER=pra]

With over 15+ years of having it (and other LMAP protocols) enabled, 
my statistics have shown it widely used by SMTP clients. It was not a 
NULL or NIL amount of usage, and we are a small company, imagine a 
bigger implementator?

The way it was implemented in my package was to use it at SMTP as a 
substituted SPF lookup if the SPF record did not exist.

Rather than get rid of SUBMITTER, I would like to see if SUBMITTER can 
be leveraged as a DMARC optimization.  It is providing the 5322.FROM 
address at the SMTP level (before DATA). This is can utilized in some 
fashion as a DKIM Policy lookup.

I don't want to just turn it off, the code is already written.  It is 
a solid concept, the passage of the 5322.From address to the SMTP MAIL 
FROM state.   SMTP clients are using it and if you enabled in your 
package, you will this fact as well.


-- 
HLS