On 03/03/2016 01:04, Brandon Long wrote:
On Mon, Feb 29, 2016 at 4:57 PM, Michael Peddemors
<michael(_at_)linuxmagic(_dot_)com
<mailto:michael(_at_)linuxmagic(_dot_)com>> wrote:
Weighing in here.. (See Embedded Comments)
On 16-02-29 04:19 PM, Brandon Long wrote:
So, we went down a similar path, and had implemented what we called
"PLAIN-CLIENTTOKEN" as a SASL mechanism.
It's basically the same as a regular SASL PLAIN, but it includes an
extra term for the client token.
This ensures that we have the client token at login time, so
that we can
perform the login permission check. It was also useful since we
were
implementing it across multiple protocols.
Ultimately, we instead decided that OAUTHBEARER would be our
preferred
mechanism for handling that.
With your spec, sending the CID after login leads to questions
about how
you would use it to do your permission checking, when would you
say not
to a connection if it didn't include a CID, etc.
The idea is to be completely backwards compatible with existing
implementations. It would be up to the server how it wishes to
address this, a private server 'might' only accept connections where
the CID is presented, other servers might find 'opportunistic' ways
to utilize this, eg different authentication thresholds, or applying
trust factors, and maybe <sic> apple servers would only allow apple
devices.
Vendor servers accepting only vendor clients don't need a public spec,
they can just implement whatever they want.
I'm unclear of the backward compatibility issue, taking our example, the
client either uses PLAIN-CLIENTTOKEN or uses just PLAIN, both are still
supported.
Agreed. And if some servers would start insisting that the proposed CID
command is always issued before any email can be sent, that would
definitely not be backward compatible.
And one could use your CID if you specify that it must be sent prior to
AUTH, for example. That would allow the challenge to AUTH at the
appropriate time and with the standard status codes, without instead
perhaps reject at MAIL FROM.
SASL also has the concept of challenge-response, which means the client
could do something to gain a CID.
I think SASL would be the best way to integrate CID-like functionality,
but I appreciate that it might be more work to define. On a plus side, a
SASL mechanism can be reused in other protocols with no changes.
Best Regards,
Alexey
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp