[Top] [All Lists]

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

2016-03-06 11:13:42
(See Embedded Comments)

On 16-03-02 05:04 PM, 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>> 

        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.

Of course, and we will be implementing some form of this, but we know how difficult it can be for vendor's if there is no standard, eg every vendor using their own spec.

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.

Exactly. CID MUST come before AUTH in order for it's ability to reduce exposure to credentials from dictionary and brute force to take effect.

A client/server interaction where CID is presented, can simply report back that the connecting client is not entitled present AUTH credentials, rather than exposing the presence of the AUTH (user) credentials, or the success/failure of the AUTH (password) presented.

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

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

No, but it provides for the opportunity for an individual who has an account on an email server, to be able to store directives based on their personal preferences, eg I will only every attempt to log into my account using "these" clients, where clients could be identified by different factors, one of those might be his various licensed software, which might be from various vendors.

Or it could be that the email server vendor prefers to let his customers specify by another type of CID, that email clients might support.

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.

This is a two parter...
First of all, we are using this forum to help encourage discussion on what kinds of CID types can be foreseen, and hopefully that can be made succinct and small, but at this time we cannot foresee what others might prefer so we elected to allow flexibility by not restricting the types at this time. We do hope that at some time, CID types can be some from of registered, or RFC know types, and the list will stay limited in scope and number. Clients of course, would only have to send one CID to provide effectiveness, if the server supports that CID type. Vendor to Vendor in theory could have their own spec, but even one agreed CID type to start would be effective.

Part two, pipelining is a whole separate can of worms, unrelated to this, but many forms of server abuse controls are not pipeline friendly

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

Which is might be the way it has to go, however it could be that the fact that any CID is presented, might help to some extent even if the type is not recognized by the server.


ietf-smtp mailing list

"Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at @linuxmagic
A Wizard IT Company - For More Info
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

ietf-smtp mailing list

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