Re: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP

Michael Peddemors <> Thu, 22 August 2019 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABBE5120A87 for <>; Thu, 22 Aug 2019 11:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.2
X-Spam-Level: *
X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_A1=3.099, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DouU839Q6E6b for <>; Thu, 22 Aug 2019 11:17:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF2DA120904 for <>; Thu, 22 Aug 2019 11:17:20 -0700 (PDT)
Received: (qmail 6036 invoked from network); 22 Aug 2019 18:17:20 -0000
Received: from (HELO []) ( by with (AES128-SHA encrypted) SMTP (14778102-c509-11e9-b7ad-00188b456935); Thu, 22 Aug 2019 11:17:20 -0700
From: Michael Peddemors <>
Organization: LinuxMagic Inc.
Message-ID: <>
Date: Thu, 22 Aug 2019 11:17:19 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: 14778102-c509-11e9-b7ad-00188b456935
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <>
X-Archive: Yes
Archived-At: <>
Subject: Re: [ietf-privacy] Privacy of CLIENTID for IMAP/SMTP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2019 18:17:23 -0000

Replying to Nick..

Sorry, late to the party, but welcome this thread.  We are still hoping 
to find an appropriate IETF 'working group' for these drafts as well, 
and this might encourage that.. the 'extra' working group had decided 
that it was beyond the mandate of that group, and it was suggested a 
'security' group might be better suited to handle this..

While we do not see that the use of CLIENTID in itself is a privacy 
issue, especially given that it is an interchange between two parties 
that are probably governed by a terms of use (eg the person and their 
email provider) discussing the merits of what is contained in a CLIENTID 
constitutes a healthy discussion..

To your points..

But I am especially concerned about the suggestions for different types 
of identifiers in these drafts. Sending a permanent or semi-permanent 
hardware identifier (like the MAC address or other hardware ID) is 
especially dangerous:
* it’s necessarily shared between accounts and users of the same device, 
disclosing correlation between accounts;
* it’s less useful for security purposes because, if it’s disclosed to 
the attacker, it can’t easily be changed;
* the user can’t easily change it when they want to clear their identity 
* it allows for collusion between servers to identify two accounts at 
two different servers as connected to the same device;
* it unnecessarily reveals other information about the user’s device, 
like the hardware vendor, and sensitive information that may be used as 
an authentication signal in other protocols or for other purposes.
</end quote>

As a contributor to these drafts, in hind sight even "mentioning" MAC 
address as a possible choice that someone might decide on to use as 
CLIENTID has turned into a lightning rod for concern.

While the draft was intended to show that the identifier should be up to 
the implementation, eg that a email client developer should be able to 
choose what is the preferred identifier to uniquely identify a device, 
and not be limited to a specific form of identifier, some misread that 
possibility as a recommendation.

I 'can' see a use case, eg a manufacturer of IoT devices might have a 
reason for identifying the hardware (thousands of temperature/moisture 
reading devices designed to send email alerts for instance) where they 
want this MAC information, eg to allow/revoke privileges when devices 
are lost/stolen/replaced, but I don't expect it to be a common choice, 
and would assume that they would take into consideration the issues 
surrounding using an identifier in an environment that may be easily be 
abused, or they correlate that information for other reasons..

It was meant solely as a discussion point and example.  But let's leave 
aside any discussion of using MAC for a CLIENTID, until someone has a 
use case for actually doing that, and under what conditions..

* Hardware identifiers for devices of course should not be used for 
devices that are designed for multi-user capabilities, eg a desktop.. IMHO

* While a hardware identifier may be difficult to 'replace', it is easy 
to 'revoke' privileges associated with a device when 
lost/stolen/replaced.  I could see that someone might say, 'I lost my 
phone, so I don't want it to access my email any more, until I find it.'

One thing that appears to be repeated in these discussions, and I think 
it muddies the waters, that an 'identifier' is a privacy concern.  Aside 
from the fact that email historically has always used identifiers, such 
as IP Address, EHLO, TLS information that 'could' be abuse to become a 
privacy concern, it is only a privacy concern if the data was shared or 
used in a fashion it wasn't intended.

That possibility of abuse (which would be a privacy concern) should not 
be confused with the technical merits.

For example, we all hear about the possibility that it is technically 
possible for Google to determine exactly where you were standing when 
you checked your email already, by combining data points they have 
access to, and while that might be 'scary' to some, it is only a privacy 
concern,  IF they do something unexpected or unauthorized with that 
data, eg sharing it with 3rd parties, or doing something outside of the 
terms of use for that service.

There are many 'identifiers' that are healthy, but can be abused. ( I am 
sure your Android phone already has enough ways to identify that two 
accounts are using the same phone if companies 'collude' but there are 
privacy laws that prevent such activity for ANY identifier.

This identifier simply makes the ability to say 'these devices are 
approved to access my account'.  Eg, I only want the identifier that 
accurately indicates it is my laptop, my phone, my home computer, and my 
office computer, to be used when accessing my email account.

And frankly, I would prefer if my 'trusted' email provider who promises 
not to share this information (just like I expect them not to share my 
email password, or credit card, or what IP(s) I access it from) as per 
the terms of use we agreed to when I signed up, DID provide me with 
obvious information about the device, so when I look at my device 
history, I can see which ones should be allowed.

While it is technically possible in SOME environments for an email 
provider to gather some information, it isn't always easy for every 
email provider.  (eg, gathering OS Fingerprints etc)

For instance, I just had an 'alert' delivered to my mailbox, based on 
the fact it wasn't one of my approved devices, as evidenced by the CLIENTID.


This is an auto-generated system alert.

Your account ( had an access attempt rejected.

Device Signature: POP3 Client, Windows (Unknown Mail Software)
Authentication: Failure
IP Address:
Country Code: US
Date: Thu, 22 Aug 2019 07:31:35 -0700

(another example)

Device Signature: SMTP Client, Windows (Unknown Mail Software)
Authentication: Failure
IP Address:
Country Code: AR
Date: Thu, 22 Aug 2019 08:44:06 -0700

Don't recognize this activity?

If this WAS you, or one of your devices and you are travelling, or have 
a new device, visit the 'Security Settings' in your webmail or portal 
from a known registered device, and adjust your restrictions and/or 
permitted devices accordingly.

-- Automated Security Notification System --
Note: The location is approximate and determined by the source IP 
address of the attempted login.

Frankly, many use cases, eg tighter corporate email environments, closed 
email environments, might want information contained in the CLIENTID to 
be made available to the end user, eg exactly WHAT mail software was 
used, or what type of device was used.

This kind of information is already available at the largest providers, 
but is not available as a general rule of thumb.  I can see that some 
email clients, or devices MAY wish to provide more information so their 
users can more easily make their own determinations instead having to 
manually compare random strings to each device settings.

All in all, the DRAFT itself is meant to be flexible enough for all use 
cases.   It will be up to the email client developers to decide what 
information best suits the purposes of their customers use cases.

But nothing stops that email client developer to use a completely 
anonymous string like a UUID if they think that is best..

*Phew* a lot longer email than I planned..

"Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at @linuxmagic
A Wizard IT Company - For More Info
"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.