> On 23 Apr 2025, at 9:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Aditya Garg <gargaditya08@xxxxxxxx> writes:
>
>>>> On 23 Apr 2025, at 3:36 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>
>>> Aditya Garg <gargaditya08@xxxxxxxx> writes:
>>>
>>>> Outlook does not accept the Message-ID header in the email body. Instead
>>>> it saves it in its own proprietary X-Microsoft-Original-Message-ID
>>>> header and a random Message-ID is set my the server. As a result,
>>>> replying to threads does not work.
>>>>
>>>> The $smtp->message variable in this script for outlook is something like
>>>> this:
>>>>
>>>> 2.0.0 OK <Message-ID> [Hostname=Some-hostname]
>>>>
>>>> This contains the Message-ID set by Microsoft in the first <>.
>>>>
>>>> This patch retrieves the Message-ID from this server response
>>>> and sets it in the email headers instead of using the self generated one.
>>>
>>> Hmph.
>>>
>>> send_message calls gen_header as the first thing. This prepares the
>>> usual From:/To:/Subject:/Date:/Message-ID: lines and returns the
>>> header text as well as recipient addresses broken out into different
>>> classes, among other things.
>>>
>>>> Signed-off-by: Aditya Garg <gargaditya08@xxxxxxxx>
>>>> ---
>>>> git-send-email.perl | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/git-send-email.perl b/git-send-email.perl
>>>> index a6cafda29c..216b23caa5 100755
>>>> --- a/git-send-email.perl
>>>> +++ b/git-send-email.perl
>>>> @@ -1799,6 +1799,17 @@ sub send_message {
>>>
>>> And before these pre-context lines, the composed $header that
>>> contains the message_id has already been sent by calling datasend()
>>> method on the smtp object. After that, we are ...
>>>
>>>> $smtp->datasend("$line") or die $smtp->message;
>>>> }
>>>
>>> ... sending the body of the e-mail here.
>>>
>>> So it is not clear to me how ovewriting the $message_id variable
>>> after the message with $header with "Message-ID:" line that
>>> contained the ID we generated has already given to the SMTP server.
>>> What the code is doing certainly contradicts with what the proposed
>>> log message explains it does, i.e.
>>>
>>> ... sets it in the email headers instead of using ...
>>>
>>> It would affect the message-ID that is used by subsequent messages
>>> when they are sent as replies to this message. I do not think we
>>> computed the header (the In-Reply-To: field) for the next message
>>> at this point of the code, and I can well believe that mucking with
>>> the $message variable at this point would make the next message
>>> correctly a response to this one.
>>>
>>> Perhaps you meant that Outlook DISCARDS the Message-ID: field in the
>>> message it was instructed to send out, and INSERTS its own? Then I
>>> can see how this patch would improve the situation, but the last
>>> paragraph in the proposed log message needs to be rewritten.
>>
>> Exactly. We don't care what message id the script is sending here. We just
>> send the first mail, and then retrieve the message ID that was set by outlook.
>>
>>
>> Then we change the variable so that In-reply-to and References work properly.
>>
>>> After sending a message, retrieve the message-ID the Outlook
>>> server assigned to the message and store it in $message_id
>>> variable; this value will be used when next and subsequent
>>> message are sent as replies to the message, preserving the
>>> threading of the messages.
>>>
>>> or something.
>>>
>>
>> I'll change the log message, although it seemed clear to me.
>
> Sounds good. What confused me was "and sets it in the email
> headers" in the proposed log message looked as if it was referring
> to the Message-ID: field of the message we retrieved the ID Outlook
> would assign to it, i.e. as if the order of events were (0) we grab
> an ID from Outlook, (1) we compose the header, embedding the ID in
> its Message-ID: field, (2) we send the result out. What happens in
> reality, if I understand you correctly, is that (0) we compose the
> header, with our message-ID in its Message-ID: field, (1) Outlook
> discard our Message-ID: field, replaces it with its own, (2) we can
> learn the ID Outlook used, and (3) we'll pretend as if that ID is
> what we gave the message we just sent in the first place, which
> would be used in In-Reply-To: field of the messages sent as replies
> to it, but it was unclear from the description which one you meant.
You understood correctly. I've already sent a v4 with detailed description as well
>
> Thanks.
