TB 68 update: if you receive email in one account and reply or forward using another account, it fails because TB uses original receiving account SMTP.
You used to be able to receive an email in (say) an old email account inbox and then reply using (say) your newer email account and its SMTP. But since the 68 update, if you receive an email in Account 1 (IMAP) and you attempt to reply or to forward after choosing a different Account 2, by selecting your Account 2 email address on the pull down menu in the "From" field of the reply message window, the message will appear to indicate that it will be sent using Account 2 and its SMPT server in parentheses, but TB will in fact throw up an error. I noticed that the Sending Message dialog box that appears after you press the send button states that it is sending via Account 1's SMTP even though you have changed the "From" field. Therefore TB returns the error: "An error occurred while sending mail. The mail server responded: Request failed; Mailbox unavailable. Please verify that your email address is correct in your account settings and try again" because it is using the Account 1 SMTP with the Account 2 credentials.
This may seem to some as an eccentric thing to want to do, but say you have an old account that you get an email on, and you want to reply using your new email address. You can't without typing a whole new message and addressing it manually to all the recipients of the received message. Or, say, you receive something on a personal account that you wish to share with business colleagues sending it using your business email. Well, you can't. And for the avoidance of doubt, this used to be as easy as changing the "From" field. I think streamlining the code has hardwired in the SMPT in all reply and forward actions regardless of the "From" field.
Chosen solution
Yes. Contacted SmartTemplate developer through github, and he recognised there was an issue and corrected it. The users on github found the new version, which was pre-released there for us to test, did not exhibit the issue. The release notes for the new add-on version references this as bug fix Issue #51. http://smarttemplate4.mozdev.org/version.html#2.9.2 https://github.com/RealRaven2000/SmartTemplate4/issues/51
Read this answer in context 👍 2All Replies (11)
I don't think it's a flaw in TB, but the policy now with many mail providers is that you can't send From: account A through the smtp server for account B. In the case of gmail = B, the recipient will see the sender as B instead of A, unless A is added as an allowed sending address in gmail settings.
Open Tools/Account Settings, select an account in the left pane, then look at Outgoing Server (SMTP) in the right pane. Make sure that each account is sending through an smtp with the same domain, User Name and password as the account in the left pane, not a Default smtp for all accounts.
Sorry, you misunderstand. I am trying to send an email from my Gmail account, with a Gmail user login, using a Gmail SMTP sever, but TB nevertheless logs into the Yahoo SMTP server using my Gmail credentials simply because the original message I an replying to was received by me through my Yahoo account. TB is at fault because (since the update) it uses my email address / username in the From field in the new reply message but ignores the account to which that email belongs. TB reverts to the account of the original message received to decide which SMTP server to use.
Let me clarify with an example. Use TB 68,Windows version. Set up an AOL account with AOL user/address, AOL IMAP server and AOL SMTP server in the account settings
Then set up a Gmail account with Gmail user/address, Gmail IMAP server and Gmail SMTP server in account settings. You now have 2 accounts.
Now, receive an email in your AOL account. Select reply. In your reply change the sending email address/account in the reply message's "From" field to your Gmail address/account, select Send or Save.
It won't work on numerous trials. It won't work because TB 68 accepts the sending email username and uses those login credentials when sending the reply, but TB erroneously sends the reply message and Gmail credentials to the AOL SMTP server just because that is the account where the original message was received.
Forwarding or replying to an email message from a different account than the receiving account is something I find I need to do 10 times oer week. Ut used to work fine. The only work around is to create a new message From the Gmail account, re-enter all the reply addresses, mock up a reply style Subject line, and cut and paste the original message as if it were a reply.
Please note this is an _example_, the issue has nothing to do with AOL, or Gmail or any other email service. It is caused by TB ignoring the account you have selected in the From field when deciding which SMTP server to use.
I understand what you're problem is, but don't think it's a problem with TB. There's something wrong with your setup or profile. I have multiple accounts and don't experience any of these issues: accounts send through the correct server based on the account selected in the From: menu, no matter which folder is selected, for new messages or replies. Most users with multiple accounts see the same - otherwise there would be a deluge of complaints.
Help/Troubleshooting, click Copy text to clipboard and paste into a reply here, omitting everything after the list of Extensions.
I never had the issue until the latest update. No profile change or alteration of the account information. It only happens when you reply or forward a received email from another account, not when you generate a new message.
Let me try deactivating all of the extensions and then reply with the troubleshoot
OK. The problem yesterday was reliably repeatable, and survived application and OS reboots. sfhowes post sugested to me that I try deactivating all the add-ons (Lightning, LookOut, Provider to Google Calendar, Signature Switch, SmartTemplate4 and gContactSync). Almost all of these required update re-installations when TB was updated to 68 by the way. After deactivating all of these, the behavior disappeared.
Probably no one will be surprised to hear that after reactivating the add-ons one by one, the behavior has not returned. The only other change that I am aware of was that my Windows 10 OS updated automatically this morning; though that seems an unlikely source of the issue. It is possible that one of the add-ons did a silent update, they are all set to auto update.
So, thank you sfhowes for your suggestions, and if anyone else experiences this, my only advice would be to deactivate add-ons and then reactivate them one by one to test them as a source.
I have isolated the problem to an add-on: SmartTemplate4, and have notified the developer.
harriss.cook Question owner said
I have isolated the problem to an add-on: SmartTemplate4, and have notified the developer.
Did you ever get a reply from them? I am facing the same issue with the same plugin.
Chosen Solution
Yes. Contacted SmartTemplate developer through github, and he recognised there was an issue and corrected it. The users on github found the new version, which was pre-released there for us to test, did not exhibit the issue. The release notes for the new add-on version references this as bug fix Issue #51. http://smarttemplate4.mozdev.org/version.html#2.9.2 https://github.com/RealRaven2000/SmartTemplate4/issues/51
harriss.cook Question owner said
Yes. Contacted SmartTemplate developer through github, and he recognised there was an issue and corrected it. The users on github found the new version, which was pre-released there for us to test, did not exhibit the issue. The release notes for the new add-on version references this as bug fix Issue #51. http://smarttemplate4.mozdev.org/version.html#2.9.2 https://github.com/RealRaven2000/SmartTemplate4/issues/51
Thanks!