Re: [PATCH v2 1/3] Add 'compose' command

Subject: Re: [PATCH v2 1/3] Add 'compose' command

Date: Thu, 19 Apr 2012 12:31:58 +0300

To: Jani Nikula, Felipe Contreras

Cc: Felipe Contreras, notmuch@notmuchmail.org

From: Tomi Ollila


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

Thread: