Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id E3DC9431FB6 for ; Thu, 19 Apr 2012 02:32:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l4XPBRXHTx4 for ; Thu, 19 Apr 2012 02:32:03 -0700 (PDT) Received: from guru.guru-group.fi (guru-group.fi [87.108.86.66]) by olra.theworths.org (Postfix) with ESMTP id 957FF431FAE for ; Thu, 19 Apr 2012 02:32:03 -0700 (PDT) Received: by guru.guru-group.fi (Postfix, from userid 501) id 7CFD668056; Thu, 19 Apr 2012 12:31:58 +0300 (EEST) From: Tomi Ollila To: Jani Nikula , Felipe Contreras Subject: Re: [PATCH v2 1/3] Add 'compose' command In-Reply-To: <8739819ey5.fsf@nikula.org> References: <1334752753-23970-1-git-send-email-felipe.contreras@gmail.com> <1334752753-23970-2-git-send-email-felipe.contreras@gmail.com> <873981chpj.fsf@nikula.org> <87vckxazq7.fsf@nikula.org> <8739819ey5.fsf@nikula.org> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Felipe Contreras , notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 09:32:08 -0000 On Wed, Apr 18 2012, Jani Nikula wrote: > On Wed, 18 Apr 2012, Felipe Contreras wrote: >> On Wed, Apr 18, 2012 at 5:20 PM, Jani Nikula wrote: >>> On Wed, 18 Apr 2012 16:34:30 +0300, Felipe Contreras wrote: >>>> On Wed, Apr 18, 2012 at 4:06 PM, Jani Nikula 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