> On 24 Apr 2025, at 4:23 AM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 2025-04-23 at 12:19:46, Aditya Garg wrote:
>> This is a problem because the Message-ID is crucial when we are sending
>> multiple emails in a thread. The current implementation for threads in
>> the script replies to the Message-ID it generated, but due to Outlook's
>> behavior, it is not the same as the one that the recipient got, thus
>> breaking threads. So a need arises to retrieve the Message-ID from the
>> server response and set it in the In-Reply-To and References email
>> headers instead of using the self generated one for the purpose of
>> replies.
>
> This behaviour is allowed by the standard. It's not uncommon for
> smarthosts to replace the Message-ID header because they are responsible
> for making it unique.
>
> I certainly don't love it and it has the possibility to break lots of
> things, as this patch demonstrates, but it is technically allowed.
>
>> The $smtp->message variable in this script for outlook is something like
>> this:
>>
>> 2.0.0 OK <Message-ID> [Hostname=Some-hostname]
>>
>> The Message-ID here is the one the receipient gets, rather than the one
>> the script generated.
>
> "recipient"
>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index a6cafda29c..a18e978e22 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -1636,6 +1636,11 @@ sub gen_header {
>> return ($recipients_ref, $to, $date, $gitversion, $cc, $ccline, $header);
>> }
>>
>> +sub is_outlook {
>> + my ($host) = @_;
>> + return ($host eq 'smtp.office365.com' || $host eq 'smtp-mail.outlook.com');
>> +}
>
> Are we certain that these are the only two possible values for this? My
> worry is that we'll have some other host (or the same host with some
> other hostname) that does the same thing and then they'll have the same
> problem. For instance, if I set my domain `smtp-outlook.example.com` to
> be a CNAME for `smtp.office365.com`, then this would fail and I'm
> concerned that we'll have corporate environments with that
> configuration.
>
> What I would recommend here is that instead we set an option that
> controls the message ID generation. We might have "as-is" for the
> default behaviour, "auto" to use the `is_outlook` function above to
> guess, and something like "data-response" to always use the approach
> you've written below.
Tbh I'm against using additional options. They are an unecessary complication
for users. I would say the patch is a good start for such problems, and can be
expanded further as per needs. Also, I don't know how the server response is
for other non outlook email providers modifying the message ID, so data-response
isn't really ideal.
Talking about corporate environments, they have their own ways to send emails
and I doubt they really use git send-email.
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA
> <signature.asc>
