(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>>
wrote:
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.
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
beneficial.
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.
Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp