> 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,