Reporting

Why are mailserver settings in alert_actions.conf not being followed?

jcrabb_splunk
Splunk Employee
Splunk Employee

I have configured alert_actions.conf in $SPLUNK_HOME/etc/system/local/ but some alerts are still using “localhost” and not being received. I have configured that there are no other alert_actions.conf besides the default ones and btool output confirms that the settings are being applied correctly.

/opt/splunk/etc/system/local/alert_actions.conf                [email]
/opt/splunk/etc/system/local/alert_actions.conf                mailserver = testmailhost.com

Looking in python.log I show both the new mail server and localhost being applied.

Working

2017-06-14 15:45:02,017 -0400 INFO  sendemail:124 - Sending email.subject="Splunk Alert: Test_Alert_01", results_link="http://hostname:8000/app/search/@go?sid=scheduler__admin__search__<SID>", recipients=“[u’user@mydomain.com']", server="testmailhost.com"

Not Working

2017-06-14 15:45:02,017 -0400 INFO  sendemail:124 - Sending email. subject="Splunk Alert: Test_Alert_02", results_link="http://hostname:8000/app/search/@go?sid=scheduler__admin__search__<SID>", recipients=“[u’user@mydomain.com']", server=“localhost”

What could be causing this behavior?

Jacob
Sr. Technical Support Engineer
1 Solution

jcrabb_splunk
Splunk Employee
Splunk Employee

Mailhost settings can be applied in both alert_actions.conf and savedsearches.conf. If you have applied alert_actions.conf globally (this configuration can be applied at an app or user level) but some alerts are going to a different mail host than specific there, it could be configured under savedsearches.conf. If you review the spec file, you will find it also has a mail server setting:

http://docs.splunk.com/Documentation/Splunk/6.6.1/Admin/Savedsearchesconf

[savedsearch-name]
action.email.mailserver = <string>
* Set the address of the MTA server to be used to send the emails.
* Defaults to <LOCALHOST> (or whatever is set in alert_actions.conf).

As demonstrated above, this can be applied to a search and will take precedent over the setting in alert_actions.conf. Confirm that the affected alerts do not contain this potential configuration.

Jacob
Sr. Technical Support Engineer

View solution in original post

jcrabb_splunk
Splunk Employee
Splunk Employee

Mailhost settings can be applied in both alert_actions.conf and savedsearches.conf. If you have applied alert_actions.conf globally (this configuration can be applied at an app or user level) but some alerts are going to a different mail host than specific there, it could be configured under savedsearches.conf. If you review the spec file, you will find it also has a mail server setting:

http://docs.splunk.com/Documentation/Splunk/6.6.1/Admin/Savedsearchesconf

[savedsearch-name]
action.email.mailserver = <string>
* Set the address of the MTA server to be used to send the emails.
* Defaults to <LOCALHOST> (or whatever is set in alert_actions.conf).

As demonstrated above, this can be applied to a search and will take precedent over the setting in alert_actions.conf. Confirm that the affected alerts do not contain this potential configuration.

Jacob
Sr. Technical Support Engineer

surekhasplunk
Communicator

Hi,

I have a similar issue.

I am declaring action.email.subject = REMINDER: Cur in my savedsearches.conf in one of my apps. But when the email is getting triggered the subject isnt getting changed. Its still taking from the default alert_actions.conf file i.e. SplunkAlert-.

Why my subject is not getting changed ?

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...