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

> > Not only Outlook comes with such quirk, AFAIK the mail service that
> > Tencent provides for personal usage does as well. I don't think it's a
> > good idea to hardcode the problematic providers.
> > 
> > Not sure whether similar ideas have been proposed earlier: since this
> > quirk affects only following e-mails but not the coverletter which
> > doesn't have a In-reply-to field, is it possible to detect the quirk
> > with the response of sending the coverletter by comparing the desired
> > Message-ID and the one in response? We could throw a warning and
> > automatically fixes following mails if the bad case really happens.
> 
> From what I understand, what you want here is, that
> 
> 1. Irrespective of the email provider, I use the logic I am using for each mail.
> 2. I extract the message-id, and compare it with the intended one.
> 3. Give a warning and fix it.

> But, no. Outlook luckily shows the message ID in its response, and is there in
> $smtp->message. In fact you can see the whole server response here:
> 
> https://github.com/marlam/msmtp/issues/190#issuecomment-2794784869
> 
> Now say I use this logic with gmail. The $smtp->message in gmail is similar to
> outlook, but has 2 main differences:
> 
> 1. The angular brackets <> are missing.
> 2. There is no message id! Rather it has a random string of numbers and letters
>    that I also am not aware of what they mean.
> 
> So, different providers have different ways, to respond.

> In any case I don't find any way to automatically determine this. And I certainly
> don't think we can poke into receiver's email to see what message id they got.
> 
> I also don't know how corporates work. Is the SMTP server for them the same ultimately?
> Or are they using some Azure server?
> 
> Tbh Microsoft does not like following standards with Outlook. It doesn't even support
> OAUTHBEARER which is supposed to be the standard, rather uses Google's XOAUTH2. So why
> not hardcode? Do you have any other solution?> 
> > This could avoid a broken thread for newcomers and should play well with
> > an option introduced together for specifying dedicated behaviour.
> > 
> >> thanks,
> >>
> >> greg k-h
> > 
> > Please Cc me on future updates of the series, thank you Aditya.
> > 
> > Best regards,
> > Yao Zi
>