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

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

Date: Thu, 19 Apr 2012 17:03:50 +0300

To: Tomi Ollila

Cc: Felipe Contreras, notmuch@notmuchmail.org

From: Felipe Contreras


On Thu, Apr 19, 2012 at 12:31 PM, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> 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".

I agree. I was going to send a first batch of patches using gmime's
implementation for now, but since apparently I have to add a bunch of
features to my notmuch-compose patch, I'm most likely going to wait
since I'm having trouble getting even a working setup right now.

Cheers.

-- 
Felipe Contreras

Thread: