MBOX-Line: From michael at linuxmagic.com  Fri Apr  5 14:36:49 2019
To: imap-protocol@u.washington.edu
From: Michael Peddemors <michael@linuxmagic.com>
Date: Fri Apr  5 14:37:17 2019
Subject: [Imap-protocol]  CLIENTID capability for IMAP (and SMTP)
Message-ID: <1a8a4997-1edc-6567-7cc3-1f2450b0e49d@linuxmagic.com>

 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.
