> We're increasing this now to 120 seconds.
> How many attempts do you think that is?
Which parameter did you set? SMTP_TIMEOUT in UC_CLIENT_SETTINGS? I'd wager that doesn't trigger any repeat attempts at all, it will merely tell Automic to try to reach the SMTP server for up to 120 seconds before ultimately failing. I could be wrong and maybe it does retries upon receiving a temporary failure SMTP return code, but my gut feeling is it's more likely it doesn't.
> That seems like it should be enough time right?
I think for SMTP_TIMEOUT, 60 seems like plenty. If you can't reach the SMTP server in 60 seconds (or even reliably in 5 ...) I think some debugging of the root cause for that is advised. You're either then not reaching the server at all, or are being tar-pitted by your own SMTP server :)
For more retry options, I think (disclaimer: never been "the email guy") you could also have a local MTA act as a relay or SmartHost. That would allow Automic to deliver the mail into the local MTA's queue no matter what, and the SmartHost then takes care of tracking the mail in it's own queue and attempting repeat delivery. For sendmail, this usually follows an escalating timeline where the delays increase gradually up to three days or something up to I think three days, but it's configurable: Email, though today everyone expects it to be, historically isn't designed to be a real time thing - sorry.
A relay or SmartHost would give you increased control over retries and probably also better logging, but it ruptures the direct feedback into the application (i.e. Automic): if the Smarthost can't deliver the email either, it'll have long been flagged as "delivered OK" in Automic even though it may still fail further down the line.
Hth,
Original Message:
Sent: 10-28-2019 10:52 AM
From: Albrecht
Subject: Call objects getting SMTP rejection
We're increasing this now to 120 seconds. If anyone has any other insight on this I'd appreciate it. I am assuming that when this type of thing happens, Automic continues to try to send the email up to 120 seconds right? How many attempts do you think that is?
------------------------------
Enterprise Scheduling Lead
Takeda
Original Message:
Sent: 10-08-2019 10:26 AM
From: Albrecht
Subject: Call objects getting SMTP rejection
I'm actually having this same issue. It's intermittent, so some emails go through, but many don't. This means teams aren't getting their alerts when processes fail, which is obviously bad.
I did increase the timeout value to 60 seconds. I mainly get the message just indicating that the SMTP address did not respond within 60 seconds. That seems like it should be enough time right? Is this error indicative of a network issue?
TIA.
Laura
------------------------------
Enterprise Scheduling Lead
Takeda
Original Message:
Sent: 12-04-2017 11:26 AM
From: Carsten Schmitz
Subject: Call objects getting SMTP rejection
Rejected <SMTP address> sounds like it could also be spam prevention by the server. Check if it's always the same addresses that fail. If so, check why - do the email domains have proper DNS (reverse) records etc.
Timeouts could be network issues, but also throttling/tarpitting by the server, in case you are sending too many invalid addresses or making too many attempts (automation can lead to automating faults. too ;)
Either way, your best bet is the mail server's log, that should tell you the reasons for rejection - unless it's a network issue.