UC4 email connection

[PhatTran612036]

Hello,

As I read the document, we need to configure email connection to send mail, we have to configure UC_CLIENT_SETTINGS.
https://docs.automic.com/documentation/webhelp/english/ARA/12.0/DOCU/12.0/ARA%20Guides/Content/AWA/Installation/install_mail_connection.htm

But in my case, no setting in UC_CLIENT_SETTINGS, but I still receive the email.
https://us.v-cdn.net/5019921/uploads/editor/2u/kleb5hl49edo.png" width="853">
Could you please advise me.

Regards,
Phat

[Robin_Markwitz_6324]

And you are sure you are logged in client 0? 

[PhatTran612036]

Robin_Markwitz_6324,

Yes, I logged in client 0.

[PhatTran612036]

Here is the screenshot

[Carsten Schmitz]

Just a hunch: It could be using a local MTA on the server machine by default. Sometimes in Automic, there are such undocumented fallback mechanismsms.

I would simply add the SMTP lines to UC_CLIENT_SETTINGS if they are indeed missing. Puts you on the safe side.

You can do that per client or in client 0 - the later then goes for any client that does not have dedicated SMTP settings. Or in other words, client specific settings override those in client 0.

[Anon Anon]

Carsten Schmitz said:

You can do that per client or in client 0 - the later then goes for any client that does not have dedicated SMTP settings. Or in other words, client specific settings override those in client 0.

Absolutely right.

In this case I would suppose client 0's setings are not set, but your specific client settings regarding SMTP.

If neither clt0 nor your client have the SMTP setting you would get an err message from AE.

[PhatTran612036]

Hello,

As I check on my client (not client 0), it doesn't have settings in UC_CLIENT_SETTINGS too :(

[Anon Anon]

Then its magic.... :-)

the only possibility left I can imagine in this case is using an OS job for sending mails.

linux: e.g. mailx, WIN: e.g. Powershell

[PhatTran612036]

In my client setting (not client 0) nothing can help.
https://us.v-cdn.net/5019921/uploads/editor/oa/16hgntyrnqbv.png" width="849">

[PhatTran612036]

:( so magic

[PhatTran612036]

We are using CALL object with Variable in sending mail notification. But no info about the mail server setting.

[Carsten Schmitz]

You or a UNIX admin:

Try finding out of your UC4 server has a local MTA. Check for running processes of sendmail / postfix / exim, or "netstat -anp | grep -i listen | grep :25" (the end of the line has the process ID), or simply try telnetting to locahost port 25.

If something is listening: You could try stopping the local MTA and see if the mails still arrive if it's stopped.

If no mails arrive when the local MTA is stopped, my hunch that UC4 has a hidden fallback to the localhost MTA is correct. Then you know why it's sending emails even with no configuration.

If you don't have a local MTA listening, or mails still arrive eventhough it's stopped, then it's magic. In that case, appreciate UC4 for the "magical" thing it is, and possibly just enter the SMTP configuration values as they should be regardless :)

[PhatTran612036]

Carsten_Schmitz_7883,

My UC4 is installed on windows machine. And on this machine, I don't find the process of mail server or port 25 running. So I think there is a magic here.

[Anon Anon]

I think I found one part of the error:

Your screenshot above is NOT showing a UC_CLIENT_SETTINGS VARA because this in the screenshot is a SQL VARA but UC_CLIENT_SETTINGS is a static VARA object....

possibly renamed?

per default an UC_CLIENT_SETTINGS VARA looks like this:

[PhatTran612036]

Hello,

Here is a part of the document. Does it mean AE itself a local MTA?https://us.v-cdn.net/5019921/uploads/editor/cx/0aff1p8l8thg.png" width="609">. I

[Carsten Schmitz]

Nope, AE is not an MTA.

MTA: Mail Transfer Agent, such as Sendmail, Exim, Postfix, Qmail. Mostly a UNIX term.

AE just generates emails and sends them (much like an Email client) via classic, unencrypted port 25 of an email server. It does NOT incorporate it's own email server (or for that matter, MTA).

[PhatTran612036]

so I don't know for this case. It's magic. Maybe someone configured it in the other variable and connection/login object or via script

[Carsten Schmitz]

Well ... if you really want to get invested in this (warning: this gets into the thick of it):

• If you're on a really old AE version, there used to be a MAPI interface (Windows Mail API, a competing technology to SMTP). I don't know how and where that was configured, but this should only concern you if your AE version is older than 9.00A.
  
  
• The content of the emails must be telling in some way, no? What emails are those mails that you reportedly receive? If you post one of them (sans security relevant details please), maybe someone here will recognize what generates them (whether it's a call object, or a script or somesuch), and that might give further clues. Do they look like emails from a call object, or do they look hand-crafted, like from a script of some of your employees?
  
  
• As Wolfgang said, your variable looks like an SQL variable. This is wrong. I'd look into that and get that cleared up. Even if it's not an immediate problem now, having an essential system variable of the wrong object type sure will be confusing for folks further down the road.
  
  
• you could try sending yourself a mail that is DEFINETLY from the engine (e.g. a plain CALL object). Do those arrive as well?
  
  
• If the emails you do get include external job output, then they may even get sent by the Agent, not the engine.  The same can be forced with a script command (SEND_MAIL then has the agent name). So you might need to consider some agent as the source. But that's just a heads-up for the sake of completeness, in most cases it will still be your AE engine sending the emails (or an OS job, see below). Agents also DO have a "mail" trace flag that can be enabled via System Overview -> Properties, the trace would tell you the SMTP server name being used. (for some reason that's beyond me, the engine processes do NOT have a mail trace flag though ...).
  
  
• you might want to look at the email SMTP headers ("Internet Headers" is what the funky folks from Microsoft call them, in "Message Options" in Outlook) of the email in question. You will find the IP address (and probably reverse DNS name) of the sending machine, that will definetly tell you if it comes from the engine, or an agent, or some other machine.
  
  If it comes from a machine that has an agent, you could go looking for jobs on that agent ("search for use" in UC4), you might find that it is being sent from an OS job (e.g. with PowerShell), not UC4 itself.
  
  If it's definetly the engine or an agent, you can find the initial SMTP server in the chain of internet headers (the one UC4 has handed the mail off to). Then you could hunt down it's name or IP address in the UC4 database. It should be in there somewhere, no matter where in the UI someone has put it, because Automic (tries to) store everything in the database. You could search an entire database for that IP address or DNS name, e.g. with something like this:
  
  https://stackoverflow.com/questions/9185871/how-to-search-sql-server-database-for-string
  
  (That's for MS SQL, I assume that's what you're using. Disclaimer: I did not test this procedure myself, I only used something similar once on Oracle).
  
  If you find it, you can probably discover what object it's stored in.
  
  Or, if all of this fails, then ... you know ...
  
  https://us.v-cdn.net/5019921/uploads/editor/5p/vwordys1bwl8.jpg" width="413">
  
  :)
  

[Matthias Schelp]

Hi Phat Tran,

what is the senders mail address? Usually it has folowing pattern <username>@<ServerName>. If the <ServerName> is your Automic server it's send via the AE engine. If it's not, it's send via the agent. In this case check the agents ini file for a [MAIL] section.

Matthias

[PhatTran612036]

Carsten_Schmitz_7883 MatthiasSchelp

My AE version is here:
https://us.v-cdn.net/5019921/uploads/editor/wi/zqv25wd7xjx0.png" width="382">
Here is the email I received


My AE is also the agent for itself too.

Here is the mail header including the info from sender

Received: from DB6PR0301MB2421.eurprd03.prod.outlook.com (2603:10a6:6:2f::29)
 by VI1PR03MB1263.eurprd03.prod.outlook.com with HTTPS via
 DB6P190CA0016.EURP190.PROD.OUTLOOK.COM; Tue, 22 Aug 2017 22:01:00 +0000
Received: from DB6PR0301CA0058.eurprd03.prod.outlook.com (2603:10a6:4:54::26)
 by DB6PR0301MB2421.eurprd03.prod.outlook.com (2603:10a6:4:59::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.18; Tue, 22
 Aug 2017 22:00:58 +0000
Received: from AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com
 (2a01:111:f400:7e08::207) by DB6PR0301CA0058.outlook.office365.com
 (2603:10a6:4:54::26) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.18 via
 Frontend Transport; Tue, 22 Aug 2017 22:00:58 +0000
Authentication-Results: spf=neutral (sender IP is 93.188.169.251)

[Carsten Schmitz]

Hi,

Are you sure these are all the SMTP headers? Is there not possibly more? Because according to this, your UC4 machine is either in the domain outlook.com, or is smtp-out.linkbynet.com, which in both cases I consider unlikely :)

But if your agent and your engine live on the same machine, the utility of SMTP headers is probably limited anyway, since it'll tell us the same origin, no matter whether it's sent from the engine or agent. So we might as well let that rest.

By the looks of the mail itself, has an activation report, a report and some sort of output attached. That means it's (at least according to the documentation) very likely being sent by the agent, not by the engine. Now I thought that the agent has it's own SMTP configuration (eventhough I could not find anything about it in the documentation), so that would have explained why you get these mails without an engine SMTP config.

BUT today I found this on the subject of SMTP for agents:

"Only configure the Email connection for the AutomationEngine, it applies automatically for all Agents that support the sending of emails"
(https://docs.automic.com/documentation/webhelp/english/ALL/components/AE/9/All%20Guides/Content/ucaaro.htm)

This is part of some old release notes, and I'm not sure whether I entirely believe this. But if it's true, then the fact that you get these mails is a mystery to me as well.

One more lead though: All the attachments have "6655282" as part of the file name. That's probably the RunID. You can look up the RunID, that will show you the job that generated this email. Then you can find conclusively how it was sent (probably a call object). Once you found it, and if you really have no SMTP configuration in the engine in any client, I suggest you open a ticket with Automic and include all the information gathered thus far. Because that would, imho, mean that either their documentation is wrong or there is something truly unexplained going on.

Best,
Carsten

[Anon Anon]

Just FYI - the mail in the screenshot indicates that it was sent by a Notification object and has added Activation-, Post Process and Job Report using "Add Reports from Task" within the CALL object.

https://docs.automic.com/documentation/WEBHELP/English/AWA/11.2/AE/11.2/All%20Guides/help.htm#ucacox.htm%3FTocPath%3DUser%2520Guide%7CObjects%7CAlphabetical%2520Listing%7CNotification%7C_____6


I personally would try searching for the SMTP settings within AE Client 0 AND your Client - without these settings the AE is not able to send emails.

AS I suggested some posts ago, search for the correct (!) UC_CLIENT_SETTINGS VARA object.

[PhatTran612036]

FrankMuffke

Here is what I found in the client0
https://us.v-cdn.net/5019921/uploads/editor/o3/1a7gujatn60n.png" width="1138">
Yes, we have postprocess, notification, and variable

!Get Script
:read &UC_CAUSE_NAME,,
:read &UC_CAUSE_NR,,
:read &UC_CAUSE_STATE,,
:read &UC_CAUSE_RETCODE,,
:PRINT &UC_CAUSE_NAME
!
!Get correct User and Department based on job name
:set &user_to_inform# = get_var(VARA._NOTIFICATION,'&UC_CAUSE_NAME',1)
:set &dep_to_inform# = get_var(VARA._NOTIFICATION,'&UC_CAUSE_NAME',2)
:set &tz_to_inform# = get_var(VARA._NOTIFICATION,'&UC_CAUSE_NAME',3)
:PRINT &user_to_inform#
:SET &user_length#=STR_LENGTH(&user_to_inform#)
:PRINT &user_length#
:IF &user_length#=1
:  set &user_to_inform# = get_var(VARA.DFS_NOTIFICATION,'ALL',1)
:  set &dep_to_inform# = get_var(VARA.DFS_NOTIFICATION,'ALL',2)
:  set &tz_to_inform# = get_var(VARA.DFS_NOTIFICATION,'ALL',3)
:ENDIF
:IF &dep_to_inform#='group'
:  ADD_ATT RECIPIENT, '&user_to_inform#'
:ELSE
:  ADD_ATT RECIPIENT, '&user_to_inform#/&dep_to_inform#'
:ENDIF

:set &nl# = UC_CRLF
!
:set &parentname# = SYS_ACT_PARENT_NAME('ACT')
:set &parentnr# = SYS_ACT_PARENT_NR('ACT')
:set &parenttyp# = SYS_ACT_PARENT_TYP('ACT')
:set &system# = GET_UC_SYSTEM_NAME
:set &client# = SYS_ACT_CLIENT
! :set &date# = SYS_DATE_PHYSICAL(,'&tz_to_inform#')
! :set &time# = SYS_TIME_PHYSICAL("HH:MM:SS",'&tz_to_inform#')
:set &ori_date_time#=SYS_TIMESTAMP_PHYSICAL("TZ.SING")
:set &date_time#=SYS_TIMESTAMP_PHYSICAL("&tz_to_inform#")
:print "original:&ori_date_time#"
:print "converted:&date_time#"
:set &statustext# = get_msg_txt(&UC_CAUSE_STATE,'')
:print &date_time#
:print &ori_date_time#
:put_att SUBJECT = "&UC_CAUSE_NAME status Date/Time: &ori_date_time#"
:PUT_ATT CALL_TEXT = "Please escalate! The Job &UC_CAUSE_NAME exceeded the time limit. &nl# &nl#"

the variable
https://us.v-cdn.net/5019921/uploads/editor/7t/txc3ootrum14.png" width="581">

[PhatTran612036]

Carsten_Schmitz_7883
It's a header. I just copied a part of it. the rest contains my company information :)

[Carsten Schmitz]

Phat Tran said:

Carsten_Schmitz_7883
It's a header. I just copied a part of it. the rest contains my company information :)

Ok, I understand :)

[PhatTran612036]

How about SEND_MAIL command? this command can send email as 1 local MTA? And we can use it in the postprocess script?

[PhatTran612036]

I check on my linux agent, we have 1 MTA sendmail

tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      3531/sendmail

so, maybe, the agent is sending the email notification.

so, but how can we know that the agent is sending email instead of AE?

[Carsten Schmitz]

SEND_MAIL is an Automic script command. It needs, at least as per the documentation, an SMTP configuration in client 0 or the active client, so it knows which SMTP server to connect to.

[Carsten Schmitz]

Phat Tran said:

I check on my linux agent, we have 1 MTA sendmail

[...]

so, but how can we know that the agent is sending email instead of AE?

Okay, I'm officially confused now.

You said your engine runs on Windows, and your agent runs on the same machine as the engine. But there is also a Linux agent involved in this problem?

It should, by the job name which seems to be in your email, or the run ID, be possible to identify the job that sends the mail. And thus, the agent. If it is that Linux agent, that brings us right back to the part of the SMTP headers you didn't post: The originating machine will either be the Linux machine (agent), or the Windows machine (AE engine).

Or, check the agents log file, or even set the "mail" trace flag of the agent in system overview to a value greater 0 (probably 9 works well). Then trigger the job again. The agent log or the trace file will contain info if it did send an email.

[Anon Anon]

again:

AS I suggested some more posts ago, search for the correct (!) UC_CLIENT_SETTINGS VARA object.

BTW: an admin training from Automic would be very helpful in your case :-)

[PhatTran612036]

Carsten Schmitz said:

Phat Tran said:

I check on my linux agent, we have 1 MTA sendmail

[...]

so, but how can we know that the agent is sending email instead of AE?

Okay, I'm officially confused now.

You said your engine runs on Windows, and your agent runs on the same machine as the engine. But there is also a Linux agent involved in this problem?

It should, by the job name which seems to be in your email, or the run ID, be possible to identify the job that sends the mail. And thus, the agent. If it is that Linux agent, that brings us right back to the part of the SMTP headers you didn't post: The originating machine will either be the Linux machine (agent), or the Windows machine (AE engine).

Or, check the agents log file, or even set the "mail" trace flag of the agent in system overview to a value greater 0 (probably 9 works well). Then trigger the job again. The agent log or the trace file will contain info if it did send an email.

Carsten_Schmitz_7883 ,

In my system, AE is installed on the windows machine, and I find itself in the agent list. And we have also installed agent on another machines including linux agent. That's the context.

[PhatTran612036]

Wolfgang Brueckler said:

again:

AS I suggested some more posts ago, search for the correct (!) UC_CLIENT_SETTINGS VARA object.

BTW: an admin training from Automic would be very helpful in your case :-)

https://us.v-cdn.net/5019921/uploads/editor/v2/s8yj5mr7lizi.png" width="745">
FrankMuffke
That's what I search for UC_CLIENT_SETTINGS. Is it correct what you recommend?

[PhatTran612036]

Can you please help share with the screenshot of correct UC_CLIENT_SETTINGS VARA?

[PhatTran612036]

Hello,

On my test system, I found the UC_CLIENT_SETTINGS in "No Folder"
https://us.v-cdn.net/5019921/uploads/editor/0t/jjj1ul7rmnan.png" width="372">

But on my production system also in "No Folder", it looks like this:


So, confusing me with my Prod :(

[Carsten Schmitz]

As Wolfgang already speculated, you appear to have an SQL-type variable called "UC_CLIENT_SETTINGS" in your production system. This is wrong, probably someone tried to create the variable from scratch and chose the wrong variable type. Since you can't have two objects of the same name (per client, not only per folder), this means you can't ever have a UC_CLIENT_SETTINGS of the correct type unless the SQL variable is removed.

This should be fixed in your system.

Whether it has any relations to the unexpected receiving of emails, I can not tell (I suspect not, but ...).

[PhatTran612036]

Carsten Schmitz said:

As Wolfgang already speculated, you appear to have an SQL-type variable called "UC_CLIENT_SETTINGS" in your production system. This is wrong, probably someone tried to create the variable from scratch and chose the wrong variable type. Since you can't have two objects of the same name (per client, not only per folder), this means you can't ever have a UC_CLIENT_SETTINGS of the correct type unless the SQL variable is removed.

This should be fixed in your system.

Whether it has any relations to the unexpected receiving of emails, I can not tell (I suspect not, but ...).

If this is the case, I wander why it can send email :(

[PhatTran612036]

cannot rename it
https://us.v-cdn.net/5019921/uploads/editor/wp/evbsttkjn25l.png" width="455">

[Carsten Schmitz]

Phat Tran said:

cannot rename it
https://us.v-cdn.net/5019921/uploads/editor/wp/evbsttkjn25l.png" width="455">

Hmmm ... I don't know, could be something I don't grasp, or could be a bug. I have separate UC_CLIENT_SETTINGS in my client 0 and my "proper" client as well, and I am getting the same message if I try to rename it in my "proper" client.

Sorry. No idea. Unless someone else has an idea, might want to ask their support for help with cleaning up your SQL variable.

[PhatTran612036]

I think so :(

[Legacy User]

That means the variable UC_CLIENT_SETTINGS was overwritten by a transport case. System variables in client 0 cannot be renamed. Export the variable from another client and import it into client 0. Then you can type in the appropriate values.

[Carsten Schmitz]

Alexander Trenker said:

That means the variable UC_CLIENT_SETTINGS was overwritten by a transport case. System variables in client 0 cannot be renamed. Export the variable from another client and import it into client 0. Then you can type in the appropriate values.

I don't quite understand. He (and myself during my tests) did not try to rename the UC_CLIENT_SETTINGS in client 0, but the one in the actual client. That's where he gets the error.

[PhatTran612036]

Yes, I tried to rename it in my own client. Not client 0.

[Pete Wirfs]

Clobbering your UC_CLIENT_SETTINGS object in production is not to be taken lightly.

In my opinion you should be working with support on this!

I would be seriously concerned that the next time your production AE is recycled, a lot of things might stop working.

[Legacy User]

I misread it then, I thought it was in client 0, my bad. In this case you can unload it from client 0 (right click on it --> External & Printing --> Transport), use DB.UNLOAD which creates a file called uc_data.txt in the utility\db folder, use the DB.LOAD to load it in the client you want too. During the load you will be prompted to overwrite the variable, because it already exists in the other client. Just press 'Yes'.

https://us.v-cdn.net/5019921/uploads/editor/gh/u2mtxgmhvz0o.png" width="761">

Ignore the second variable i had in my transport case (UC_CUSTOM_ATTRIBUTES).