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
