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

Aditya Garg <gargaditya08@live.com> writes:

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.

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 ...

... 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.

	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.

Perhaps a small helper sub

	sub is_outlook {
		my ($host) = @_;
		return ($host eq '...' ||
			$host eq '...');
	}

would make it easier to maintain (and read).

Is this worth reporting, or more or less a leftover debugging aid?

The fact that we retrieved (as opposed to "could not retrieve" case) may have been significant during the development of this feature, but to end-users who see this message, retrieved is not at all interesting. What is interesting to them is that the server gave your message some random Message-ID you've never heard of, so while it may make sense to report what that ID is, perhaps

	Outlook reassigned Messsage-ID: %s

might be more meaningful to them. rewritten, reassigned, used, there may be even better verbs, but the point is that the subject of that sentence is the outlook smtp serveron the other end of the connection (as opposed to the actor of "retrived" is the program running on our end).