If user doesn't modify the replied-to-msg subject, use the original subject

(which might be UTF-8 encoded). This works-around the problem that Accession
reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
terminal which resulted in a message body that was UTF-8 encoded but a message
subject that was CP437 encoded. This mix of encodings is not supported by FTN
standards.

This is just a work-around since if the user modifies the subject the result
could still have the CP437 unside-down question marks (indicating
non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's
still a bug here somewhere that I need to look into more.

src/sbbs3/postmsg.cpp

@@ -68,6 +68,7 @@ bool sbbs_t::postmsg(int subnum, int wm_mode, smb_t* resmb, smbmsg_t* remsg)
 {
 	char	str[256];
 	char	title[LEN_TITLE+1] = "";
+	char	org_title[LEN_TITLE+1] = "";
 	char	top[256] = "";
 	char	touser[64] = "";
 	char	from[64];
@@ -93,6 +94,7 @@ bool sbbs_t::postmsg(int subnum, int wm_mode, smb_t* resmb, smbmsg_t* remsg)
 
 	if(remsg) {
 		SAFECOPY_UTF8(title, msghdr_field(remsg, remsg->subj, NULL, term_supports(UTF8)));
+		SAFECOPY(org_title, title);
 		if(remsg->hdr.attr&MSG_ANONYMOUS)
 			SAFECOPY(from,text[Anonymous]);
 		else
@@ -300,6 +302,8 @@ bool sbbs_t::postmsg(int subnum, int wm_mode, smb_t* resmb, smbmsg_t* remsg)
 	msg_client_hfields(&msg,&client);
 	smb_hfield_str(&msg,SENDERSERVER, server_host_name());
 
+	if(remsg != NULL && remsg->subj != NULL && strcmp(title, org_title) == 0)
+		SAFECOPY(title, remsg->subj); // If msg subject not changed by user, use original (possibly UTF-8 encoded) subject
 	smb_hfield_str(&msg,SUBJECT,title);
 
 	add_msg_ids(&cfg, &smb, &msg, remsg);