Description

This issue is created from: https://github.com/wazuh/wazuh/issues/22901

The user and I have detected that the email alerts are not received when using the full or default format in the <email_alerts> block configuration of the Wazuh manager.

I noticed that two types of notifications are sent:

"Wazuh notification".
"Wazuh <alert_level>" - <RULE_ID>.

I suppose the first one are alerts generated from the email configuration of the global configuration, and the second one are alerts generated from the email_alerts configuration.

The configuration used is the following:

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>yes</email_notification>
    <smtp_server>localhost</smtp_server>
    <email_from>[email protected]</email_from>
    <email_to>[email protected]</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>10m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>3</level>
    <format>default</format>
    <do_not_delay />
  </email_alerts>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>3</email_alert_level>
  </alerts>
...

The emails of the green block received using the full or default format. As you can see, Gmail notifies that he could not send the emails. The emails of the red block are emails using the sms format. This behavior is exactly the same the community user reports.

Steps to reproduce

On a Ubuntu 22.04 system:

Install Wazuh v4.7.3.
Configure the STMP server: https://documentation.wazuh.com/current/user-manual/manager/manual-email-report/smtp-authentication.html
Configure the email alerts: https://documentation.wazuh.com/current/user-manual/manager/manual-email-report/index.html
Configure the email alerts using the sms format. Check that you receive the emails correctly.
Configure the email alerts using the full or default format. Check that you get Gmail warnings notifying that some emails could not be sent.

Conclusion

It is necessary to investigate why this is happening and fix it if it is a problem.

May 08 '24 16:05 davidcr01

Hello, Not functional even with reproduction steps 1 and 5 only. Not functional even with unencrypted SMTP on port 25. SMS format does not need to be configured.

Email notifications generated by global settings or in rules <options>alert_by_email</options> work. Using <email_alerts> does not. Eliminating this problem would make the job much easier.

May 22 '24 08:05 Kobrik1

Update

The code related to this feature will be refactored in 5.0.0

Does it make sense to analyze this?
We can move this to 4.8.1 as an alternative

CC: @Dwordcito

Jun 06 '24 14:06 sebasfalcone

Update 06/10

Unable to reproduce any kind of issue using full format, the mail was sent without issues

Wazuh Notification.
2024 Jun 10 18:25:32

Received From: jammy->syscheck
Rule: 553 fired (level 7) -> "File deleted."
Portion of the log(s):

File '/home/vagrant/test/file' deleted

[!NOTE] This was related to group field

Update 06/11

I was able to reproduce the issue, the key field seems to be "group", removing that field we get the following messages

Expand

[!NOTE] All of a sudden the environment stopped working. It does not send anything with mail CLI due to limit exceeded

said: 550-5.4.5 Daily user sending limit exceeded

Working configuration

Expand

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>yes</email_notification>
    <smtp_server>localhost</smtp_server>
    <email_from>[email protected]</email_from>
    <email_to>[email protected]</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>10m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
    <update_check>yes</update_check>
  </global>

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <!--<group>sshd,</group>-->
        <format>sms</format>
        <do_not_delay/>
  </email_alerts>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>5</email_alert_level>
  </alerts>

Notifications received

Wazuh 5 - 554 - File added to the system.

File '/home/vagrant/test/file2' added
Mode: realtime

Attributes:
 - Size: 0
 - Permissions: rw-r--r--
 - Date: Tue Jun 1

Wazuh notification - jammy - Alert level 5

Wazuh Notification.
2024 Jun 11 15:56:42

Received From: jammy->syscheck
Rule: 554 fired (level 5) -> "File added to the system."
Portion of the log(s):

File '/home/vagrant/test/file2' added
Mode: realtime

Attributes:
 - Size: 0
 - Permissions: rw-r--r--
 - Date: Tue Jun 11 15:56:42 2024
 - Inode: 512080
 - User: root (0)
 - Group: root (0)
 - MD5: d41d8cd98f00b204e9800998ecf8427e
 - SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709
 - SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855




 --END OF NOTIFICATION

Also

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <group>sshd,</group>
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

Wazuh Notification.
2024 Jun 11 16:11:28

Received From: jammy->netstat listening ports
Rule: 533 fired (level 7) -> "Listened ports status (netstat) changed (new port opened or closed)."
Portion of the log(s):

ossec: output: 'netstat listening ports':
tcp [0.0.0.0:22](http://0.0.0.0:22/) 0.0.0.0:* /usr
tcp6 :::22 :::* /usr
tcp [0.0.0.0:25](http://0.0.0.0:25/) 0.0.0.0:* 20502/master
tcp6 :::25 :::* 20502/master
tcp [127.0.0.53:53](http://127.0.0.53:53/) 0.0.0.0:* 537/systemd-resolve
udp [127.0.0.53:53](http://127.0.0.53:53/) 0.0.0.0:* 537/systemd-resolve
udp [10.0.2.15:68](http://10.0.2.15:68/) 0.0.0.0:* 512/systemd-network
tcp [0.0.0.0:1514](http://0.0.0.0:1514/) 0.0.0.0:* 30311/wazuh-remoted
tcp [0.0.0.0:1515](http://0.0.0.0:1515/) 0.0.0.0:* 30132/wazuh-authd
tcp [127.0.0.1:35837](http://127.0.0.1:35837/) 0.0.0.0:* 636/containerd
tcp [127.0.0.1:43675](http://127.0.0.1:43675/) 0.0.0.0:* 4223/code-89de5a8d4
tcp [0.0.0.0:55000](http://0.0.0.0:55000/) 0.0.0.0:* 30084/python3
Previous output:
ossec: output: 'netstat listening ports':
tcp [0.0.0.0:22](http://0.0.0.0:22/) 0.0.0.0:* /usr
tcp6 :::22 :::* /usr
tcp [0.0.0.0:25](http://0.0.0.0:25/) 0.0.0.0:* 20502/master
tcp6 :::25 :::* 20502/master
tcp [127.0.0.53:53](http://127.0.0.53:53/) 0.0.0.0:* 537/systemd-resolve
udp [127.0.0.53:53](http://127.0.0.53:53/) 0.0.0.0:* 537/systemd-resolve
udp [10.0.2.15:68](http://10.0.2.15:68/) 0.0.0.0:* 512/systemd-network
tcp [0.0.0.0:1514](http://0.0.0.0:1514/) 0.0.0.0:* 28980/wazuh-remoted
tcp [0.0.0.0:1515](http://0.0.0.0:1515/) 0.0.0.0:* 28898/wazuh-authd
tcp [127.0.0.1:35837](http://127.0.0.1:35837/) 0.0.0.0:* 636/containerd
tcp [127.0.0.1:43675](http://127.0.0.1:43675/) 0.0.0.0:* 4223/code-89de5a8d4
tcp [0.0.0.0:55000](http://0.0.0.0:55000/) 0.0.0.0:* 28850/python3




 --END OF NOTIFICATION

Invalid configuration

With this configuration the notification for listened ports stops working

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <!--<group>sshd,</group>-->
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

With this configuration the notification for syscheck stops working

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <group>sshd,syscheck</group>
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

[!NOTE] The group tag is parsed as a regex. We should use pipes

Any group string. For multiple groups, separate the strings with a pipe character

Undelivered Mail Returned to Sender

This is the mail system at host jammy.localdomain.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<[[email protected]](mailto:[email protected])>: host [smtp.gmail.com](http://smtp.gmail.com/)[142.250.0.109] said: 550-5.7.1 This
    message is not RFC 5322 compliant. There are multiple To headers. 550-5.7.1
    To reduce the amount of spam sent to Gmail, this message has been 550-5.7.1
    blocked. For more information, go to 550-5.7.1
    https://support.google.com/mail/?p=RfcMessageNonCompliant and review 550
    5.7.1 RFC 5322 specifications. d2e1a72fcca58-7042571df69sm6084428b3a.52 -
    gsmtp (in reply to end of DATA command)

Jun 10 '24 21:06 MiguelazoDS

Update 06/12

Due to the abovementioned limit, it is tedious to use a Gmail account. But it is possible to use the local machine and check the mails at /var/mail/root

    <email_from>[email protected]</email_from>
    <email_to>[email protected]</email_to>

From there we can use the mail command line tool to read the messages, or directly open that file.

Working configuration

Already mentioned above

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>yes</email_notification>
    <smtp_server>localhost</smtp_server>
    <email_from>[email protected]</email_from>
    <email_to>[email protected]</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>10m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
    <update_check>yes</update_check>
  </global>

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <!--<group>syscheck,|sshd,</group>-->
        <format>sms</format>
        <do_not_delay/>
  </email_alerts>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>5</email_alert_level>
  </alerts>

The outputs are the following (two messages) - Syscheck delete example

Header

From [email protected] Wed Jun 12 12:44:42 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 7BBBD2565
	for <[email protected]>; Wed, 12 Jun 2024 12:44:42 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Wed, 12 Jun 2024 12:44:42 -0300
Subject: Wazuh 7 - 553 - File deleted.
Message-Id: <[email protected]>
X-UID: 3
Status: O

Body

File '/home/vagrant/test/file' deleted
Mode: realtime

Attributes:
 - Size: 0
 - Permissions: rw-r--r--
 - Date: Wed Jun

Header

From [email protected] Wed Jun 12 12:44:52 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 7F2F52565
	for <[email protected]>; Wed, 12 Jun 2024 12:44:52 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Wed, 12 Jun 2024 12:44:52 -0300
Subject: Wazuh notification - jammy - Alert level 7
Message-Id: <[email protected]>
X-UID: 4
Status: O

Body

Wazuh Notification.
2024 Jun 12 12:44:38

Received From: jammy->syscheck
Rule: 553 fired (level 7) -> "File deleted."
Portion of the log(s):

File '/home/vagrant/test/file' deleted
Mode: realtime

Attributes:
 - Size: 0
 - Permissions: rw-r--r--
 - Date: Wed Jun 12 11:58:48 2024
 - Inode: 512081
 - User: root (0)
 - Group: root (0)
 - MD5: d41d8cd98f00b204e9800998ecf8427e
 - SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709
 - SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855




 --END OF NOTIFICATION

Invalid configuration (full format without group)

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <!--<group>syscheck,|sshd,</group>-->
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

The output is the following - Syscheck delete example

Header

From [email protected] Wed Jun 12 12:48:34 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id C0E5759;
	Wed, 12 Jun 2024 12:48:34 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
To: <[email protected]>
Date: Wed, 12 Jun 2024 12:48:34 -0300
Subject: Wazuh notification - jammy - Alert level 7
Message-Id: <[email protected]>
X-UID: 2
Status: O

Body

Wazuh Notification.
2024 Jun 12 12:48:31

Received From: jammy->syscheck
Rule: 553 fired (level 7) -> "File deleted."
Portion of the log(s):

File '/home/vagrant/test/file' deleted
Mode: realtime

Attributes:
 - Size: 0
 - Permissions: rw-r--r--
 - Date: Wed Jun 12 12:44:58 2024
 - Inode: 512081
 - User: root (0)
 - Group: root (0)
 - MD5: d41d8cd98f00b204e9800998ecf8427e
 - SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709
 - SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855




 --END OF NOTIFICATION

Difference with the working configuration

In the invalid configuration case (root 2) the line <[email protected]> is missing and there's a duplicate To. What is the report we got before (Undelivered Mail Returned to Sender)

... There are multiple To headers. 550-5.7.1 ...

The for line is missing and there's a extra To when there's no group and the format is full.

Invalid configuration (added groups sshd, syscheck, random_group)

The following configurations

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <group>syscheck,|sshd,</group>
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <group>syscheck,</group>
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

  <email_alerts>
        <email_to>[email protected]</email_to>
        <level>5</level>
        <group>random_non_existent_group,</group>
        <format>full</format>
        <do_not_delay/>
  </email_alerts>

fix the case for listening ports (and other notifications) but it does not work for Syscheck (file added/deleted)

From [email protected] Wed Jun 12 13:32:32 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 5E2EA2565
	for <[email protected]>; Wed, 12 Jun 2024 13:32:32 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Wed, 12 Jun 2024 13:32:32 -0300
Subject: Wazuh notification - jammy - Alert level 7
Message-Id: <[email protected]>
X-IMAPbase:           1718210205                    4
X-UID: 1
Status: O


Wazuh Notification.
2024 Jun 12 13:32:21

Received From: jammy->netstat listening ports
Rule: 533 fired (level 7) -> "Listened ports status (netstat) changed (new port opened or closed)."
Portion of the log(s):
...

From [email protected] Wed Jun 12 13:36:17 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id BAF6159;
	Wed, 12 Jun 2024 13:36:17 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
To: <[email protected]>
Date: Wed, 12 Jun 2024 13:36:17 -0300
Subject: Wazuh notification - jammy - Alert level 7
Message-Id: <[email protected]>
X-UID: 2
Status: O


Wazuh Notification.
2024 Jun 12 13:36:13

Received From: jammy->syscheck
Rule: 553 fired (level 7) -> "File deleted."
Portion of the log(s):
...

Jun 12 '24 16:06 MiguelazoDS

Update 06/13

We're not checking for NULL here (although it doesn't fail there due to that, the check is missing).

https://github.com/wazuh/wazuh/blob/e44fab6fb7733d803153471996d2590dda24fca2/src/os_maild/sendmail.c#L421

When we use group the value there is different than FULL_FORMAT (zero) and it enters the if ignoring completely the full option in the configuration file and due to that the following line is not executed.

https://github.com/wazuh/wazuh/blob/e44fab6fb7733d803153471996d2590dda24fca2/src/os_maild/sendmail.c#L428

But when we don't use group, the value in gran_set is 2 (FULL_FORMAT), the i is not incremented and the code above is executed, duplicating the To header.

We can see how the group entry is changing the behavior.

Jun 13 '24 21:06 MiguelazoDS

Conclusions

The code was not easy to follow, and it seems there are many linked options (not sure if on purpose or not) for granular configuration that change the behavior unexpectedly.

Below is the complete overview considering the examples above and some others.

Configurations and results

Format sms, no group tag

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <!--<group>syscheck,</group>-->
    <format>sms</format>
    <do_not_delay/>
  </email_alerts>

This is the working example the user mentioned

From [email protected]  Fri Jun 14 11:15:40 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 8E06F2509
	for <[email protected]>; Fri, 14 Jun 2024 11:15:40 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Fri, 14 Jun 2024 11:15:40 -0300
Subject: Wazuh 7 - 510 - Host-based anomaly detection event (rootcheck).
Message-Id: <[email protected]>

Trojaned version of file '/bin/diff' detected. Signature used: 'bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh' (Generic).

From [email protected]  Fri Jun 14 11:15:40 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 8F2C3250C
	for <[email protected]>; Fri, 14 Jun 2024 11:15:40 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Fri, 14 Jun 2024 11:15:40 -0300
Subject: Wazuh 7 - 510 - Host-based anomaly detection event (rootcheck).
Message-Id: <[email protected]>

Trojaned version of file '/usr/bin/diff' detected. Signature used: 'bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh' (Generi

From [email protected]  Fri Jun 14 11:15:40 2024
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from notify.ossec.net (localhost [127.0.0.1])
	by jammy.localdomain (Postfix) with SMTP id 90751250E
	for <[email protected]>; Fri, 14 Jun 2024 11:15:40 -0300 (-03)
To: <[email protected]>
From: Wazuh <[email protected]>
Date: Fri, 14 Jun 2024 11:15:40 -0300
Subject: Wazuh 7 - 533 - Listened ports status (netstat) changed (new port opened or closed).
Message-Id: <[email protected]>

ossec: output: 'netstat listening ports':
tcp 0.0.0.0:22 0.0.0.0:* /usr
tcp6 :::22 :::* /usr
tcp 0.0.0.0:25 0.0.0.0:* 1306/m

[!NOTE] We can see there that the body of the messages is short and not very descriptive as the user said. But there are some cases where the information is more verbose and it does not seem to respect the sms format.

The full mail file has different subject descriptions

https://github.com/wazuh/wazuh/blob/1a5ff212358b8be693eb3331f2afe68cbd1e9252/src/os_maild/maild.h#L25-L26

root.log

Format SMS, group set with random value

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <group>random_group,</group>
    <format>sms</format>
    <do_not_delay/>
  </email_alerts>

There are no SMS format messages in the /var/mail/root file, all messages are in full format.

root.log

All messages show the following subject

https://github.com/wazuh/wazuh/blob/1a5ff212358b8be693eb3331f2afe68cbd1e9252/src/os_maild/maild.h#L26

The function in charge to send sms messages that wasn't called is

https://github.com/wazuh/wazuh/blob/071a7a59b019f6b57c3abc8da0b28adb8c48cd74/src/os_maild/sendmail.c#L57

The function is called if this variable is not NULL

https://github.com/wazuh/wazuh/blob/b294a4189c3ce0a0128629378ca9f9783f04ebbc/src/os_maild/maild.c#L238

The variable is set here

https://github.com/wazuh/wazuh/blob/02029e27d1945ca7dec870da2e98cb00ee838e9b/src/os_maild/maild.c#L398

But taking a look inside the function we see that the variable is set if this other variable is set

https://github.com/wazuh/wazuh/blob/b294a4189c3ce0a0128629378ca9f9783f04ebbc/src/os_maild/os_maild_client.c#L306

sms_set is never set, the code in the line below is not executed, which is correct, because the regex does not match, but the behavior after a wrong group is unexpected.

https://github.com/wazuh/wazuh/blob/b294a4189c3ce0a0128629378ca9f9783f04ebbc/src/os_maild/os_maild_client.c#L255

[!NOTE] For the case without group tag mentioned before, the code never reaches the continue and the code below is executed https://github.com/wazuh/wazuh/blob/071a7a59b019f6b57c3abc8da0b28adb8c48cd74/src/os_maild/os_maild_client.c#L208

format sms, group set with valid groups

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <group>rootcheck,|syscheck,|vulnerability-detector,</group>
    <format>full</format>
    <do_not_delay/>
  </email_alerts>

The behavior is similar to the first case but sometimes some notifications are missing, this is probably related to the grouping option where many notifications are grouped in a single mail.

root.log

Adding some logs here

https://github.com/wazuh/wazuh/blob/071a7a59b019f6b57c3abc8da0b28adb8c48cd74/src/os_maild/os_maild_client.c#L203

We get the following logs, but sometimes there are less than expected

2024/06/14 16:09:35 wazuh-maild: INFO: Check group: ossec,rootcheck,pci_dss_10.6.1,gdpr_IV_35.7.d,
2024/06/14 16:09:35 wazuh-maild: INFO: Check group: ossec,rootcheck,pci_dss_10.6.1,gdpr_IV_35.7.d,
2024/06/14 16:09:41 wazuh-maild[110930] os_maild_client.c:281 at OS_RecvMailQ(): INFO: Check group: ossec,syscheck,syscheck_entry_added,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2024/06/14 16:11:36 wazuh-maild[110930] os_maild_client.c:281 at OS_RecvMailQ(): INFO: Check group: vulnerability-detector,gdpr_IV_35.7.d,pci_dss_11.2.1,pci_dss_11.2.3,tsc_CC7.1,tsc_CC7.2,

Format full (default), group tag missing

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <!--<group>syscheck,</group>-->
    <format>full</format>
    <do_not_delay/>
  </email_alerts>

This reproduces the behavior described in the issue and the one reported by the user. The messages are returned to the sender due to a duplicate To header

root.log

This behavior was described here https://github.com/wazuh/wazuh/issues/23350#issuecomment-2166811685

Format full (default), random group

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <group>random_group,</group>
    <format>full</format>
    <do_not_delay/>
  </email_alerts>

root.log

This, according to the analysis, "fixes" the issue because of an unexpected behavior. Described here https://github.com/wazuh/wazuh/issues/23350#issuecomment-2166811685.

Real cases

Format sms, group tag missing

Expand

[!NOTE] Although the format is SMS, the information shouldn't be incomplete.

[!NOTE] No SMS format

Format full, random group

Couldn't reproduce the real cases due to limit exceeded. But the output is the same as the "No SMS format" shown above.

Jun 14 '24 20:06 MiguelazoDS

Amazing work @MiguelazoDS great effort 💪🏼

Conclusion

Given these three points:

The effort for 5.0.0 will be to refactor code into C++
Fixing this behavior will demand a huge effort
There is a workaround

Workaround

To fix the issue, we can add a <group> tag to the configuration:

[!NOTE] Is not necessary that the group exist

Configuration not working

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <format>full</format>
    <do_not_delay/>
  </email_alerts>

Configuration working

  <email_alerts>
    <email_to>[email protected]</email_to>
    <level>5</level>
    <group>random_group,</group>
    <format>full</format>
    <do_not_delay/>
  </email_alerts>

We conclude that we can close these issues

Jun 14 '24 20:06 sebasfalcone

Email alerts are not sent when using `full` or `default` format

Description

Steps to reproduce

Conclusion

Update

Update 06/10

Update 06/11

Working configuration

Invalid configuration

Update 06/12

Working configuration

Invalid configuration (full format without group)

Invalid configuration (added groups sshd, syscheck, random_group)

Update 06/13

Conclusions

Configurations and results

Format sms, no group tag

Format SMS, group set with random value

format sms, group set with valid groups

Format full (default), group tag missing

Format full (default), random group

Real cases

Format sms, group tag missing

Format full, random group

Conclusion

Workaround