1525885 - Message-Id not preserved when sending draft email

Status: NEW

(MailNews Core :: Composition, defect)

Description

[nicolas]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Using TB 60.3.0 on Linux:

• Create mail and save to Draft (IMAP account)
• Check Message-Id in mail source in Draft folder
• Double click email in Draft folder (or click edit)
• Send Later
• Check message-id in outbox
• Send unsent messages

Actual results:

Original message-Id in Draft folder:
Message-ID: <[e-mail]>

Message ID in Outbox:
Message-ID: <[e-mail]>

Received Message-Id:
Message-ID: <[e-mail]>

Expected results:

Message-Id should not be changed when sending a draft email.

Tools like git rely on this to sent patch series as threaded (git imap-send can be used to create drafts on the IMAP server)

Note that behavior is the same whether drafts were created manually or uploaded to the Draft folder by git

Comment 1

[Wayne Mery (:wsmwk)]

Sorta like bug 1421736 ?

Comment 2

[Jorg K (CEST = GMT+2)]

I don't understand the question. Bug 1421736 was about templates and we fixed it as part of bug 1389062.

I've just tried this:
ID in drafts:
Message-ID: <[e-mail]>

Edited and saved again, ID unchanged.

ID in outbox:
Message-ID: <[e-mail]>

I've read through bug 1279869 again, that was long ago, and it was about a different issue.

Reporter: Why is it bad to allocate a new ID upon send? Please explain the "Message-Id should not be changed when sending a draft email".

Magnus, do you have an opinion here?

Comment 3

[nicolas]

My use case is with git. When exporting a patch series, it is expected for all patches to be threaded (usually all are replies to the first one or to a cover letter)

To handle this, git uses the Message-Id from the first patch (or the cover letter) and adds a flag to mark the following patches as reply of this one (I'm on my phone so can't check the exact field name now)

Changing the Message-Id when sending means that the following patches will be marked as replies to a non existing Message-Id and not be threaded at reception.

Comment 4

[Jorg K (CEST = GMT+2)]

Hmm, generally threading uses the References: header. You get a message with ID1, you reply with ID2 and have ID1 in the References: header.

I think the key to understanding the use case is what you wrote in bug 1279869 comment #26 (quote):

• Generates patches from git into DRAFT (git format-patch | git imap-send)
• Editing the patch within the draft folder and saving it keeps the Message-ID
• When sending the patch, Message-ID has changed.

So somehow git produces some drafts(?) and instead of replying which would copy the message ID to the References: header, you edit the draft and hope that the ID is preserved upon sending. Hmm.

Comment 5

[nicolas]

I think it uses the In-Reply-To header (that's the CLI option name at least)
But yes the issue is that all the drafts are generated at once.
So the Message-Id of the sent first message is not yet available and so the Message-Id it currently has in the Draft folder is used.

I currently work around the issue by sending the first mail. Manually get his Message-Id and regenerating the other draft for ing the In-Reply-To value in the CLI.
It works but is highly unpractical.

is there a rationale behind changing the Message-Id between Draft and Sent email?

Comment 6

[Magnus Melin [:mkmelin]]

I agree the Message-Id should be kept. (There could be good reasons to make sure it stays otherwise too so you could refer to a mail you're sending by id.)
We must make sure the id is never reused though, and guaranteeing that might be tricky, e.g. in case someone goes back to a draft and creates another mail from it.

Comment 7

[Jorg K (CEST = GMT+2)]

Well, "edit as new" on a draft uses a new ID. It is possible that a superseded draft isn't deleted in which case you could edit it again and send a message with the same ID.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #6)

I agree the Message-Id should be kept. (There could be good reasons to make sure it stays otherwise too so you could refer to a mail you're sending by id.)
We must make sure the id is never reused though, and guaranteeing that might be tricky, e.g. in case someone goes back to a draft and creates another mail from it.

(In reply to Jorg K (GMT+1) (PTO to 15th Dec 2019, sporadically reading bugmail) from comment #7)

Well, "edit as new" on a draft uses a new ID. It is possible that a superseded draft isn't deleted in which case you could edit it again and send a message with the same ID.

So this bug should be marked NEW?

Comment 9

[Magnus Melin [:mkmelin]]

I suppose so.