91 lines
3.7 KiB
Plaintext
91 lines
3.7 KiB
Plaintext
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.
|