Re: [PATCH v4 2/3] send-email: retrieve Message-ID from outlook SMTP server

> On 24 Apr 2025, at 4:23 AM, brian m. carlson <sandals@crustytoothpaste.net> 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.