[Top] [All Lists]

Re: [ietf-smtp] Discussion of draft-storey-smtp-client-id-01

2016-03-08 11:16:15
On 03/03/2016 01:04, Brandon Long wrote:

On Mon, Feb 29, 2016 at 4:57 PM, Michael Peddemors
<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
        implementing it across multiple protocols.

        Ultimately, we instead decided that OAUTHBEARER would be our
        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

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

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,

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>