From Bron's email..
"For what it's worth, this work was brought to the EXTRA working group
at IETF at Montreal last year, and the group decided that it wasn't the
right level in the stack for this kind of ID - that it would be better
placed in the SASL layer."
For the record, and correct me if I am wrong, the only "consensus" there
was that since it was for both SMTP and IMAP, it wasn't really in the
mandate of the working group.. albeit now there is discussion about the
'extra' including some SMTP items.
It was also suggested that more discussions should happen, and a 'home'
(eg working group) to take this on might be found ..
There WERE some comments that SASL might be preferred, to which we
responding that CLIENTID is 'not' authentication, but identification, so
belongs at a higher level, albeit it can be made available to any and
all SASL implementations by the SMTP/IMAP implementation, as well as to
any other identification or ACL systems that are not part of the
authentication layer..
Also, feedback was provided that the term CLIENTID (rather than the
original moniker of simply CID) was preferred which was incorporated
into the DRAFT, as well as the suggestion that client implementations
should take into the consideration whether CLIENTID should be presented
on a per client, or per service.
But Bron thank you for the following..
"On the flip side, I'm sensitive to the argument from Linux Magic that
this solves a problem RIGHT NOW which a perfect future solution might
solve better, but a future solution doesn't fix anything for the current
environment."
Thanks, because that is exactly the reason for it's inception, and why
others are open to adopting it now. We are trying to 'change' SMTP/IMAP,
simply make it easier to prevent the kind of abuse that is increasing
worldwide right now..
IT IS easier than many other ideas, easier to understand, adopt, and
implement, and is 100% backwards compatible until all email clients
support this, and it sure stops brute force attacks, and/or leaked
password from 3rd party data breaches. And allows the little players to
be able to implement what until now was really only available to the big
boys.
There is a fundamental problem today, for which this (CLIENTID) is "a"
solution, and our team has been working hard with partners, open source
projects, and other commercial vendors to expand on the adoption of this
worldwide.
And it is something that has proven already very successfully in our
implementations. Looking forward to more email clients and more servers
supporting CLIENTID, to widen the available number of email clients that
can be used when customers want to better secure their in-boxes.
"Lock Your Mailbox" ;)
--
"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.