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

[Hector Santos <[e-mail]>]

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