Call objects getting SMTP rejection

[Bhavpreet_Bains_7888]

Hello, 

Some of our call objects randomly get the SMTP rejection error (U00050006 SMTP server '' has rejected the E-mail command: '<SMTP address>') or time out error (U00050012 Timeout - SMTP Server '<SMTP address>' did not answer within '20' seconds). 
It happen on different objects at different time. E.g. on Nov 21, 3 objects got the smtp rejection error at 10:42:26 pm, 8:00:42 pm, 4:07:44 am and a time out at 1:34:06 pm. 

We are using the cloud host for routing the emails. 

Just wondering if someone else is getting similar issue and what can be done to resolve it. 

Thank you.

[Anon Anon]

Hi

thats usually not an Automation Engine error but some SMTP Servers (sry, no idea if its necessary using cloud services) require an authorisation of the sender`s IP address....

So its most likely an SMTP config issue...

[Legacy User]

It might be helpful to increase the timeout value from 20 seconds to a higher value. Maybe it takes longer to establish to connection to the cloud SMTP service or to relay the service than 20 seconds

[Carsten Schmitz]

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.

[Laura Albrecht]

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

[Laura Albrecht]

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

[Carsten Schmitz]

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

[Carsten Schmitz]

​Oh, and since Automic likely won't document those things, if you really want to find out how many retries (if any) are done, and what SMTP error codes are possibly exchanged, and you don't control the SMTP server, you could do a tcpdump on the mail port on the Automic machine. It's all unencrypted SMTP I guess, so you should be able to see text dumps of the SMTP conversations in it :)

[Nicole Boeger]

We have the Timeouts every once in a while, too. The email always was sent so far anyway. In our environment it looks like the email server just doesn‘t response in 20 seconds. It happens at night when backups occupy our Network, I believe.

It‘s an issue for us also, since we will soon send emails to other companies. Being uncertain if the email was sent and probably sending it twice is a bad situation.

Tracing is a good idea but hard to do because of the intermittency.



Von meinem iPhone gesendet
Kassenärztliche Vereinigung Niedersachsen
Körperschaft des öffentlichen Rechts | Berliner Allee 22 | 30175 Hannover
Vorstand: Mark Barjenbruch (Vorsitzender), Dr. Jörg Berling | Vertreterversammlung: Dr. Christoph Titz (Vorsitzender)