MBOX-Line: From michael at linuxmagic.com Fri Apr 5 14:36:49 2019 To: imap-protocol@u.washington.edu From: Michael Peddemors 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.