Open Bug 402828 Opened 17 years ago Updated 2 years ago

Alternative SMTP server is not tried if the default refuses the send request

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Linux
defect

Tracking

(Not tracked)

People

(Reporter: xlator, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: version 1.5.0.13 (20070809)

I have 2 SMTP servers defined. (The default is the preferred one if I'm connected to my primary network premises.)
However, if I connect my machine to another network place, the default SMTP server is not serving that address, therefore it gives "relaying denied".

Problem: In this case thunderbird doesn't try the other SMTP server that would actually accept the request.


Reproducible: Always

Steps to Reproduce:
1.define 2 smtp servers, the should default accept connection only from address1, the other from any address.
2.move the client to another place with address2 that is not served by the default SMTP server
3.Try to send a mail. The default server rejects the request, and the 2nd server is not contacted.
Actual Results:  
Progress window, connecting to <default server>
Error window: themail server responded: ... relaying denied

Expected Results:  
The 2nd SMTP server should be contacted after the failure
Sorry, the build ID should contain only the Thunderbird ID, that is:
Build Identifier: version 1.5.0.13 (20070809)
What do you mean by "Alternative SMTP server"?
Sorry but Tb doesn't have "Alternative SMTP server" feature yet, has "Multiple SMTP definition" and "Multiple Identities definition" only and an identity uses one SMTP only.
Read following MozillaZine Knoeledge Base articles, please.
  http://kb.mozillazine.org/Mail_concepts
  http://kb.mozillazine.org/Multiple_SMTP_servers_-_Thunderbird
  http://kb.mozillazine.org/Multiple_identities_per_e-mail_account

> relaying denied

Possible workaround in your case is use of "SMTP AUTH"(login to SMTP server), if your ISP supports "SMTP AUTH", and if your ISP doesn't reject other ISP's mail address when login to SMTP server is correctly done.
I use 3 ISPs, and all of 3 SMTP server permits use of other ISP's mail address as From: when login to SMTP is properly done.

If above is not applicable, combination of followings is currently available simplest/easiest solution for your problem.
 (1) Choose "Use Default Server" at "Outgoing Server(SMTP):" choice
     of Adccount Settings panel(for main identity)
     or each identity settings panel(Account Settings/Manage Identities).
 (2) Change "Default SMTP server" according to your location(using ISP)
     at Account Settings/Outgoing Server(SMTP), which is located at bottom
     of account list.
By (1), Tb always tries to use currently defaulted SMTP server, and by (2), you can easily change SMTP server which is used for mail sending with any identity (From: mail address used by a mail).
Bug 222388 is request for automatic (1).

Above workarounds are not effective if ISP-1 permits mail-addr-1 for smtp-1 only(mail-addr-2 of ISP-2 is rejected) and ISP-2 permits mail-addr-2 for smtp-2 only((mail-addr-1 of ISP-1 is rejected).
So some enhancements/improvements, including your ""Alternative SMTP server" feature, are already requested.
Please search bugzilla.mozilla.org.
Condition of "Summary contains SMTP & Status='---'(=open)" will be helpful for your search, I think.
As you state, "workarounds are not effective if ISP-1 permits mail-addr-1 for smtp-1 only(mail-addr-2 of ISP-2 is rejected) and ISP-2 permits mail-addr-2 for smtp-2 only((mail-addr-1 of ISP-1 is rejected)."

Exactly this is my situation.

I was not aware that the multiple SMTP servers are not acting as standby for each other but are statically tied to mail identities.

As a workaround, I defined 2 ID-s with the same mail address and set different SMTP servers for them. Then I can hopefully change the SMTP server by changing between the basically identical ID-s.
Well, quite a hack, isn't it ? :)
Is this a duplicate?
David, are there reasons why we wouldn't want to do this?
I can see how this would be useful - even better would be to learn which address(es) an smtp server doesn't allow, and don't try that server when sending from those addresses. 

I don't know if we'd need to add UI to let the user know we're doing this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I had thought this would be difficult to detect because network location might change the response of an SMTP server (being behind or out of a company firewall).

Trying to convey a learning system is a little scary in terms of UI.  There are lots of gotchas to explain why we learned something and prevent it from learning that way again. The simpler the learning system the better, but overall they are pretty tricky.

We could just offer to resent through the alternate SMTP server when sending through the default fails.  Assuming there is an alternate setup for the identity.  We could even offer to continue using that SMTP server for the remainder of the session.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.