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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux