Could a Fallback connection do more harm than good? (422 error)

  • Resolved markussss

    (@markussss)


    2 weeks, 2 days ago

    Hello,

    I am in a situation where SMTP server is external from a different hosting provider. I have a phpmail Fallback connection with correctly setup SPF.

    It happened already that the Telegram bot informed me SMTP Error: Could not connect to SMTP host. Failed to connect to server

    The result was that the email was not sent at all (according to the log). It shows still “Failed” in the log. When I open the log items (3 entries in total that all belong to one booking on the website) I see the Mailer: PHP mail() and not SMTP.

    Now I wonder what that all could mean?

    • The bot tells me a connection to the main email provider (SMTP) was not possible
    • The log tells me it failed (I am not sure if it really did, I cannot check) however, it shows PHP Mail and not SMTP
    • Does it mean SMTP failed → Fallback to PHP → and then PHP also failed? (that would be a lot of fails)

    When is the fallback connection used?

    How long is it trying to send via the main connection (SMTP) until it falls back to the PHPmail connection?

    Could it be harmful and maybe better to keep only one main connection so that it can re-try more often before it falls back to PHPmail?

    —

    edit:

    {
      "code": 422,
      "message": "SMTP Error: Could not connect to SMTP host. Failed to connect to server",
      "errors": [
        "SMTP Error: Could not connect to SMTP host. Failed to connect to server"
      ],
      "fallback": "Tried to send using fallback but failed. websitename
      "fallback_response": {
        "code": 400,
        "message": "",
        "errors": []
      }
    }

    Thanks

    best regards
    Markus

    • This topic was modified 2 weeks, 2 days ago by markussss.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support Ibrahim Sharif

    (@ibrahimsharif)

    Hello @markussss,

    Regarding your question about the fallback connection potentially doing more harm than good, it’s a valid concern. Here’s how FluentSMTP handles the fallback:

    • Immediate Fallback:?The fallback connection is indeed attempted immediately after the main connection (SMTP) fails to establish a connection. This explains why you’re seeing PHP Mail() in the logs after the SMTP connection failure. It’s FluentSMTP’s automatic attempt to ensure email delivery.
    • Log Interpretation:?The log entries you shared are very helpful. The?SMTP Error: Could not connect to SMTP host. Failed to connect to server?message combined with the fallback attempt indicates a potential problem preventing FluentSMTP from reaching your external SMTP server.

    Based on the error and the behavior you’re seeing, the most likely cause is:

    1. Firewall Interference:?A firewall on your hosting server might be blocking outgoing connections to your external SMTP server.
    2. Incorrect Hostname:?The hostname you’ve configured for your SMTP server within FluentSMTP might be incorrect or unresolved.
    • Retries & Cron:?FluentSMTP utilizes WordPress’s Cron system to handle retries. If an email fails to send, the plugin will automatically schedule a retry attempt.

    Let me know if checking the firewall and hostname resolves the issue! If not, we can investigate further.

    Thread Starter markussss

    (@markussss)

    Hello @ibrahimsharif

    Thanks that’s very important information and probably should go into the documentation, perhaps here or here. This topic is important in my eyes, because it tells me there is room for improving the reliability and maybe adapt how FluentSMTP is handling this.

    @ Immediate Fallback
    I am not an expert in email but is this the “industry standard” (I know there is probably no standard); I just wonder if immediate fallback is actually good. Why not give it 30 seconds?

    @ Log Interpretation:
    The problem is that the email was not sent at all. I had to manually go to the log and “re-send”. That’s why I came up with the other idea about the “messed up” resend timestamps. It did not send via the primary email connection (SMTP). It went immediately to the fallback email connection (in my eyes especially external servers giving it a few seconds and maybe 3 attempts would be good, but I don’t know how the “protocols” work under the hood). The Fallback is completely internal (phpmail) and it did not send. We interpreted the SMTP error from the main connection, but not the error from the fallback connection Tried to send using fallback but failed.

    So it was a double-fail and it just gave up. I manually went to resend it a few minutes later and it sent it successfully..

    I checked with both hosting providers and they say nothing is blocked. CURL attempts show the same (I don’t know much about it, I just applied it for testing). There is also a server cron job running.

    If an email fails to send, the plugin will automatically schedule a retry attempt.

    When are you scheduling a retry attempt and how many times? does it mean when an email fails completely (main connection fails + fallback connection fails)?

    Thanks again

    best regards
    Markus

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.