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

From: S Moonesamy <[email-masked]>
Date: Tue, 19 Jun 2018 15:23:20 -0700

Dear Internet Engineering Steering Group,

There is an item on the agenda above moving RFC 4405, RFC 4406 and 
RFC 4407 to Historic.  RFC 4405 defines the SUBMITTER Service 
Extension.  Is there any standards action needed for the SMTP Service 
Extensions registry?

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Jun 2018 11:44:52 +0100

Hi SM,

On 19/06/2018 23:23, S Moonesamy wrote:
> There is an item on the agenda above moving RFC 4405, RFC 4406 and RFC 
> 4407 to Historic.  RFC 4405 defines the SUBMITTER Service Extension.  
> Is there any standards action needed for the SMTP Service Extensions 
> registry?
I can't think of any actions needed for the SMTP Service Extensions 
registry. SUBMITTER is not going to be removed from it. Did you think of 
something else?

Best Regards,
Alexey

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 20 Jun 2018 10:57:06 +0000

On June 20, 2018 10:44:52 AM UTC, Alexey Melnikov <[email-masked]> wrote:
>RFC 

I would have expected a note to be added indicating the status change..

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jun 2018 06:40:08 -0700

Hi Alexey,
At 03:44 AM 20-06-2018, Alexey Melnikov wrote:
>registry. SUBMITTER is not going to be removed from it. Did you 
>think of something else?

Not taking any action to update the registry defeats the purpose of 
having the registry.  I suggest considering Section 2.2 of RFC 5321.

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Jun 2018 14:59:47 +0100

Hi SM,

On 20/06/2018 14:40, S Moonesamy wrote:
>> registry. SUBMITTER is not going to be removed from it. Did you think 
>> of something else?
>
> having the registry.
Adding a note about the extension being moved to Historic is reasonable. 
Removing the entry is not.

>   I suggest considering Section 2.2 of RFC 5321.

I am happy to be proven wrong, but I don't think it covers the case of 
an SMTP extension being made historic.

Best Regards,
Alexey

---

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jun 2018 07:17:02 -0700

Hi Alexey,
At 06:59 AM 20-06-2018, Alexey Melnikov wrote:
>Adding a note about the extension being moved to Historic is 
>reasonable. Removing the entry is not.

Adding a note sounds fine.  I'll leave the process details to you.

>I am happy to be proven wrong, but I don't think it covers the case 
>of an SMTP extension being made historic.

My guess is that the editor might read the ietf@ mailing list. :-)

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jun 2018 12:08:12 -0400

--On Wednesday, June 20, 2018 14:59 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Hi SM,
>...
>> Not taking any action to update the registry defeats the
>> purpose of  having the registry.

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.

The other is to allow the client maintainers who see a service
extension announcement (or server maintainers who, in violation
of 5321, see a service extension request) to easily look that
purported extension up and see what it is about.   Unless the
IESG has a magic wand that will cause any and all uses of
Sender-ID to disappear the instant that this action is taken, it
is _very_ important that the registry entry remain and that it
point to useful information, both about what Sender-ID is/was
and why the IETF now claims it is Historic and, presumably, is
making a "NOT RECOMMENDED" (see 2026) statement about it.

At the risk of kicking a dead horse, the above is precisely why
I prefer to see RFCs published to cover cases like this (as
Applicability Statements for present or former standards track
documents) rather than simple tracker notes.   I don't actually
care about Sender-ID or friends.  The original documents were
Experimental, an explanation has been published about why the
experiment was concluded and these approaches were not viable,
and, if the tracker note is sufficiently clear about why the
action is being taken _and_ registries updated with appropriate
"HISTORIC" and "don't use this" notations and references, I
think this approach is probably ok (although not my first
preference).   However, I recommend we use this discussion as
motivation to discourage tracker-style reclassifications to
Historic for standards-track documents when the intent is to
convey a "don't start using this is you are not and, if you are,
please start phasing it out" sort of recommendation.

> I am happy to be proven wrong, but I don't think it covers the
> case of an SMTP extension being made historic.

I think that section is irrelevant to this discussion except to
the degree that it explains the reasons for having registry
entries (and keeping them there and keeping them up to date).
If someone thinks that is not explained adequately, please file
an erratum -- I still assume that the time will come in which a
replacement to 5321 will be appropriate and, while I'm keeping
notes and a working version of a revision, relying entirely on
that is probably not wise.

best,
   john

---

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jun 2018 14:32:41 -0700

Hi John,
>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.

>purported extension up and see what it is about.   Unless the

Yes.

>making a "NOT RECOMMENDED" (see 2026) statement about it.

Yes.

>please start phasing it out" sort of recommendation.

Several years ago, there was a discussion about this experiment.  It 
was not viable to do the reclassification at that time.  I don't 
think that tracker-style reclassification is a good idea.  Anyway, 
you explained it better than I could.

>that is probably not wise.

I am not inclined to file an erratum on this as it would be 
ill-thought-out. :-)

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Jun 2018 21:53:46 -0400

On 6/20/2018 5:32 PM, S Moonesamy wrote:
> 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