[Top] [All Lists]

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

2016-03-02 19:04:14
On Mon, Feb 29, 2016 at 4:57 PM, Michael Peddemors 

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

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.

Also, advanced MTA's might even let customers 'choose' what type of CID
needs to be presented before AUTH attempts are made.

I'm also not clear on why you need multiple types of CID tokens.

In order to allow as much flexibility for email server vendors.  Some
might 'like' a certain type, eg an email client software license.  But the
benefit is that 'any' form of client ID can be beneficial.

software license sounds like another vendor to vendor thing, not an
interoperability thing.

Our privacy folks would also not be happy with using the MAC address for
this, they would want it to be something that would be cleared by the
user on various use cases, and not necessarily the same across different
accounts so we wouldn't be storing something that could link multiple
accounts together.

And of course, by keeping the CID concept flexible enough, your privacy
folks might only have your MTA's action on specific CID types, if
presented. (eg Android Device Identifier), and silently ignore if a device
presents the MAC as part of CID.  Eg, A Google customer might say only
Android Devices are allowed to attempt authentications.  Any other attempt
would not have to reveal the existence of the email for instance.

Does that help understand a bit more?

I feel that this level of flexibility leads you in the direction of the
IMAP ID command, where there is almost no consensus on what fields there
are and what to present.  That's theoretically fine for ID as there was a
deliberate attempt to limit programmatic usage of the information... but is
annoying to us in terms of dashboard slicing and dicing, and also makes
things much more complicated if you wanted to implement some sort of poor
man's MDM policies for IMAP (because, you're not supposed to).

Without more specification, clients would have to send as many CIDs as they
have in order to increase the likelihood of acceptance, with no feedback.
Without pipelining, that's a lot of round trips, which is especially
annoying for mobile clients (higher latency, more battery usage as the
radio is kept active longer).  Pipelining is of course supported by smtp,
probably should be encouraged in your spec.

Of course, you could include the list of supported CID in the EHLO
response, similar to how AUTH lists the supported SASL mechanisms.

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>