On Wed, Apr 18 2012, Jani Nikula <jani@nikula.org> wrote: > On Wed, 18 Apr 2012, Felipe Contreras <felipe.contreras@gmail.com> wrote: >> On Wed, Apr 18, 2012 at 5:20 PM, Jani Nikula <jani@nikula.org> wrote: >>> On Wed, 18 Apr 2012 16:34:30 +0300, Felipe Contreras <felipe.contreras@gmail.com> wrote: >>>> On Wed, Apr 18, 2012 at 4:06 PM, Jani Nikula <jani@nikula.org> wrote: >>>> >>>> > Running "notmuch compose" more than once within a second would result in >>>> > identical message ids for the messages, which is not a good idea. That's >>>> > not likely in interactive use, but the notmuch cli is highly scriptable, >>>> > so someone is bound to hit this. >>>> > >>>> > Some paranoid might also be worried about "leaking" the time you run >>>> > "notmuch compose"... which may be different from the actual time you >>>> > send the message. >>>> >>>> It's still better than the current situation; nothing. In any case, >>>> people that have not needed this would not be affected; their UI would >>>> override the Message-ID. >>>> >>>> So do you have a better suggestion for a Message-ID? >>> >>> The easy way would be to just use g_mime_utils_generate_message_id() >>> [1]. It doesn't give you any control of the part before @, but I'm not >>> sure if that really matters. >> >> This is what gmime does: >> g_strdup_printf ("%lu.%lu.%lu@%s", (unsigned long int) time (NULL), >> (unsigned long int) getpid (), count++, fqdn); >> >> Which actually has some of the issues you mentioned. > > Thanks for looking into gmime source. The implementation is a bit of a > disappointment. > >> I can do the same if you want (add pid and count). The advantage of >> using our own format is that not only would it be more unique, but it >> would not have "@fqdn". > > I'm starting to think doing our own would be the best, although I > wouldn't object to using the gmime implementation "for now". I think I would be disappointed if I had to use message id:s generated by gmime -- just that "time leakage" problem. I guess the message-id is usually generated just before the mail is sent so the date in message id and Date: header are about equal. If message id is generated one time and Date: another then the time taking to write an email leaks... (except if Date: is also generate at 'notmuch compose' execution time (uhh ;/) Anyway, gmime implementation or something having time(NULL).getpid() could be used "for now". >>> Alternatively you can write your own according to e.g. [2]. Glib appears >>> to have decent and portable support for pseudo random number >>> generation. But why bother? I'd go with gmime. >> >> But gmime doesn't have anything random. I would actually prefer to >> have something random though. > > Agreed. Me too. > > > BR, > Jani. Tomi