IBM Support

QRadar: Events going to the wrong log source when Postfix and Linux OS log sources have the same Log Source Identifier



When a Postfix and a Linux log source have the same identifier, Postfix events might get parsed by the Linux log source and vice versa in QRadar Security Information and Event Management (SIEM).


  • QRadar Traffic Analysis (TA) evaluates events to determine whether they belong to an existing log source. If TA finds a matching log source identifier (LSI), and if the events, or payload, look similar, the incoming events might be correlated to an incorrect log source type.
  • Another typical reason is that Postfix events might be sent to QRadar port 514 instead of a separate port as described in the DSM Configuration Guide: UDP Multiline Syslog log source parameters for PostFix MTA - IBM Documentation.

Diagnosing The Problem

To find your event payloads:
  1. Log in to the QRadar GUI.
  2. Open the log source management app: Admin > Log Sources
  3. Use the Search field to search for a specific log source identifier (LSI), or for the name of a log source.
  4. To make the LSI column visible in the list, click the cogwheel icon to the far right.
  5. Enable Log Source Identifier to spot shared LSIs easier. You can move the LSI column in the list to avoid having to scroll horizontally.
  6. When you find your log source, select the log source and click Events to see the recent events associated with this log source in Log Activity.
  7. From the Display drop-down menu, select Raw Events, or double-click single events to drill down and see the event payloads.
    Example Linux Payload:
    <35>Dec 2 17:09:35 HOSTNAME saslpasswd2: error-deleting entry from sasldb: BDB0073 DB_NOTFOUND: No matching key/data pair found
    Example Postfix Payload:
    <22>Mar 10 09:36:00 HOSTNAME postfix/smtpd[30964]: 681B0600960: client=unknown, sasl_method=LOGIN, sasl_username=XXXXX

Resolving The Problem

If the Traffic Analysis does not identify the correct log source type of the event, do the following to ensure that events are associated with the correct log source type, try the following steps. If two or more log sources share the log source identifier (LSI), but are of different log source types, you might also want to check and adjust Parsing Order.

Before you begin
Note: These steps include a Deploy Changes, so plan this activity during a maintenance schedule.

  1. Log in to QRadar GUI.
  2. Click Admin tab.
  3. Click Log Sources.
  4. If Linux OS events are incorrectly associated with a Postfix log source, identify the incorrect Postfix log source and disable it.
  5. If the events continue to be associated with an incorrect log source type, create three log sources following this example:
  6. First log source - the Gateway log source
    Note: When correctly configured, no events are associated with this log source.
    1. Log Source Type: Universal DSM
    2. Protocol: UDP Multiline
    3. Log Source Identifier: something unique that is not found in a Syslog Header in the events, example - postfix_gw_517.
    4. Listen Port: 517
      Note: You might need to adjust the target port on the Postfix host. You can also use a workaround to redirect events from a certain IP address to port 517 on QRadar: Configuring IPtables for UDP Multiline Syslog events - IBM Documentation.
    5. Message ID pattern: postfix\/.*?[ \[]\d+[ \]](?:- - |: )([A-Z0-9]{8,})
    6. Event Formatter: No formatting
    7. Show Advanced Options: Yes
    8. Use As A Gateway Log Source: Yes

      Image: Example log source configuration
  7. Create a second log source. This log source is for parsing the Postfix events:
    1. Log Source Type: PostFix MailTransferAgent
    2. Protocol: Forwarded (or Syslog)
    3. Log Source Identifier: Hostname, FQDN, or IP that matches the event Syslog Header information.

      Image: Example log source configuration
  8. Create a third log source. This log source is for parsing the Linux OS events:
    1. Log Source Type: Linux OS
    2. Protocol: Syslog
    3. Log Source Identifier: Hostname, FQDN, or IP that matches the event Syslog Header information.

      Image: Example log source configuration
  9. Once the log sources are created, perform Admin tab > Deploy Changes.
  10. Important: Restart Event Collecting results in a service being restarted. While the service is restarted, event collection stops until service restart. Administrators with strict outage policies are advised to complete this step during a scheduled maintenance window for their organization.
    Optional: If you can't see any events in Log Activity, you can also restart the event collecting services from Admin tab > Advanced > Restart Event Collecting Services to make sure all the services are running.

    Events are now be associated with the correct log source.


Document Location


[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwt0AAA","label":"Log Source"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
22 March 2023