Discussion:
[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids
Michael Hudson
2009-07-30 00:32:16 UTC
Permalink
New submission from Michael Hudson <mwh at users.sourceforge.net>:

If you call email.utils.make_msgid a number of times within the same
second, the uniqueness of the results depends on random.randint(100000)
returning different values each time.

A little mathematics proves that you don't have to call make_msgid
*that* often to get the same message id twice: if you call it 'n' times,
the probability of a collision is approximately "1 -
math.exp(-n*(n-1)/200000.0)", and for n == 100, that's about 5%. For n
== 1000, it's over 99%.
... msgids = [make_msgid() for i in range(n)]
... return len(msgids) - len(set(msgids))
...
sum((collisions(100)>0) for i in range(1000))
49
sum((collisions(1000)>0) for i in range(1000))
991

I think probably having a counter in addition to the randomness would be
a good fix for the problem, though I guess then you have to worry about
thread safety.

----------
components: Library (Lib)
messages: 91073
nosy: mwh
severity: normal
status: open
title: calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids
type: behavior
versions: 3rd party, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Michael Hudson
2009-07-30 00:34:48 UTC
Permalink
Michael Hudson <mwh at users.sourceforge.net> added the comment:

A higher resolution timer would also help, of course.

(Thanks to James Knight for the prod).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gavin Panella
2009-07-30 08:21:31 UTC
Permalink
Changes by Gavin Panella <gavin at gromper.net>:


----------
nosy: +allenap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-04 04:30:57 UTC
Permalink
Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch replaces the random part with an increasing sequence (in a
thread safe way).
Also, added a test case for make_msgid (there was none previously)

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file14643/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-04 04:31:30 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file14644/test_email.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-04 04:32:45 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
versions: -3rd party, Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Antoine Pitrou
2009-08-06 18:19:01 UTC
Permalink
Antoine Pitrou <pitrou at free.fr> added the comment:

Is it ok if the message id is predictable?
Besides, _gen_next_number() can more efficiently be written as:

_gen_next_number = itertools.cycle(xrange(N))

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-07 19:34:17 UTC
Permalink
Post by Antoine Pitrou
Antoine Pitrou <pitrou at free.fr>
Is it ok if the message id is predictable?
I don't know of any use of message ids apart from uniquely identifying the message, but we could still keep a random part followed by the sequence.
Post by Antoine Pitrou
Besides, _gen_next_number() can more efficiently be written
_gen_next_number = itertools.cycle(xrange(N))
Written that way it will eventually hold a list with 100000 integers forever.

Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.

http://ar.mujer.yahoo.com/cocina/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-07 19:59:18 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14643/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-08-07 19:59:53 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file14676/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-11-15 10:12:30 UTC
Permalink
Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

An updated version of the make_msgid patch.
Includes a random part plus a sequential part. Testing takes at most 3
seconds now (we're interested in those msgids generated in a whole
second)

----------
Added file: http://bugs.python.org/file15339/make_msgid.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-11-15 10:12:43 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14644/test_email.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Gabriel Genellina
2009-11-15 10:12:49 UTC
Permalink
Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14676/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Éric Araujo
2010-11-30 05:42:21 UTC
Permalink
Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +r.david.murray
versions: -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Varun Sharma
2014-02-28 20:27:27 UTC
Permalink
Changes by Varun Sharma <varunsharmalive at gmail.com>:


----------
nosy: +varun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Mark Lawrence
2015-02-24 15:18:59 UTC
Permalink
Mark Lawrence added the comment:

Can we have a patch review please. If nothing else xrange will have to change for Python 3.

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-02-24 17:52:00 UTC
Permalink
Serhiy Storchaka added the comment:

The probability of a collision when generated n numbers from 0 to m-1 is

1 - factorial(m)/factorial(m-n)/m**n

When n << sqrt(m), it is approximately equal to n**2/(2*m). When m = 1000000, we have problems for n about 1000. When increase m to 2**32, the probability of collisions is decreased to 0.01%. When increase m to 2**64 as recommended in [1], it is decreased to 2.7e-14. I.e. when generate 1000 IDs per second, collisions happen one per a million years.

We could also take datetime with larger precision. E.g with 2 digits after the dot, as recommended in [1].

When apply both changes, we could generate 100000 IDs per second with one collision per 10000 years or 10000 IDs per second with one collision per 1000000 years.

[1] https://tools.ietf.org/html/draft-ietf-usefor-message-id-01

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-05-17 12:19:31 UTC
Permalink
Serhiy Storchaka added the comment:

Here is a patch that changes the generating of message IDs:

1. The datetime is taken with higher precision, 2 decimal digits after dot.
2. The datetime is written as Unix time in 0.01 second units, not as YYYYmmddHHMMSS. This is more compact and faster.
3. The random part is taken as the random integer in the range 0 from to 2**64, not from 0 to 10**5.

This increases the length of generated part of the ID from 26 to 39 characters in average. Perhaps in new releases we can use non-decimal or even non-alphanumeric characters in ID for compactness.

----------
nosy: +barry
stage: -> patch review
Added file: http://bugs.python.org/file39405/make_msgid_2.diff

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
R. David Murray
2015-05-17 13:15:45 UTC
Permalink
R. David Murray added the comment:

Looking at my mail store, it looks like one more more mail clients use a GUID for the messageid, which is 36 characters. So 39 doesn't seem so bad. There's even one that is 74 characters long. There are also shorter ones, though, so compactifying the result wouldn't be a bad thing.

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Barry A. Warsaw
2015-05-17 16:03:48 UTC
Permalink
Barry A. Warsaw added the comment:

An increase of 13 characters doesn't seem so bad.

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-05-17 17:46:32 UTC
Permalink
Serhiy Storchaka added the comment:

Currently the maximal length of local part is

14+1+len(str(2**16))+1+len(str(10**5-1)) == 26

With the patch it will be

len(str(2**31*100))+1+len(str(2**16))+1+len(str(2**64)) = 39

If encode all three numbers with hexadecimal, it will be

len('%x'%(2**31*100))+1+len('%x'%(2**16))+1+len('%x'%(2**64)) = 34

If encode their with base32:

math.ceil((31+math.log(100)/math.log(2))/5)+1+math.ceil(16/5)+1+math.ceil(64/5) = 27

Using base64 or base85 can be not safe, because message ID can be used as file name in case-insensitive file system.

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-05-19 07:04:32 UTC
Permalink
Changes by Serhiy Storchaka <***@gmail.com>:


----------
assignee: -> serhiy.storchaka

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Roundup Robot
2015-05-19 07:11:08 UTC
Permalink
Roundup Robot added the comment:

New changeset 6969bac411fa by Serhiy Storchaka in branch '2.7':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/6969bac411fa

New changeset ea878f847eee by Serhiy Storchaka in branch '3.4':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/ea878f847eee

New changeset 933addbc7041 by Serhiy Storchaka in branch 'default':
Issue #6598: Increased time precision and random number range in
https://hg.python.org/cpython/rev/933addbc7041

----------
nosy: +python-dev

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-05-19 07:23:10 UTC
Permalink
Serhiy Storchaka added the comment:

Now there is a question. Is it worth to use base16 (hexadecimal) to compact message id to 34 characters or base32 to compact it to 27 characters? Using base16 is pretty easy: just replace %d with %x. Using base32 is more complicated.

With base64 and base85 the length can be decreased to 23 and 21, but I doubt that this is safe.

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Barry A. Warsaw
2015-05-19 12:33:37 UTC
Permalink
Post by Serhiy Storchaka
Now there is a question. Is it worth to use base16 (hexadecimal) to compact
message id to 34 characters or base32 to compact it to 27 characters? Using
base16 is pretty easy: just replace %d with %x. Using base32 is more
complicated.
It might not be relevant, but we're using base 32 in Message-ID-Hash:

http://wiki.list.org/DEV/Stable%20URLs

We settled on base 32 after consulting with the curators of mail-archive.com
and others.

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Serhiy Storchaka
2015-11-10 17:43:49 UTC
Permalink
Serhiy Storchaka added the comment:

http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/3246/steps/test/logs/stdio
======================================================================
FAIL: test_make_msgid_collisions (email.test.test_email.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/email/test/test_email.py", line 2434, in test_make_msgid_collisions
pass
File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/contextlib.py", line 24, in __exit__
self.gen.next()
File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_support.py", line 1570, in start_threads
raise AssertionError('Unable to join %d threads' % len(started))
AssertionError: Unable to join 5 threads

----------------------------------------------------------------------

Threads that should be finished for 3 seconds can't be finished for 15 minutes. It looks as clock() wrapped around. From clock (3) manpage:

Note that the time can wrap around. On a 32-bit system where CLOCKS_PER_SEC equals 1000000 this function will return the same value approximately every 72 minutes.

The solution is to use monotonic() (time() on older releases) instead of clock().

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
Roundup Robot
2015-11-10 17:54:15 UTC
Permalink
Roundup Robot added the comment:

New changeset 3c0a817ab616 by Serhiy Storchaka in branch '3.4':
Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions.
https://hg.python.org/cpython/rev/3c0a817ab616

New changeset e259c0ab7a69 by Serhiy Storchaka in branch '3.5':
Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions.
https://hg.python.org/cpython/rev/e259c0ab7a69

New changeset d1c11a78b43a by Serhiy Storchaka in branch 'default':
Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions.
https://hg.python.org/cpython/rev/d1c11a78b43a

New changeset bdd257d60da2 by Serhiy Storchaka in branch '2.7':
Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions.
https://hg.python.org/cpython/rev/bdd257d60da2

----------

_______________________________________
Python tracker <***@bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

Loading...