Fix email-to-ticket sender detection for “via”/mailing-list emails

[zoltan151]

Summary

Prefer Reply-To and X-Original-* headers before From when parsing inbound mail. This fixes cases (e.g. Google Groups DMARC mitigation) where From is rewritten to the group address like support@…, causing ITFlow to misidentify the requester and break contact/domain matching + ticket threading. Falls back to From when Reply-To/original headers aren’t present; no other parsing behavior changed.

Detailed Explanation

Context

Some inbound emails arrive as "Customer Name" via {Group Name} <support@example.com> due to mailing-list/Google Groups DMARC behavior. In those cases, the visible From address is rewritten to the group address while the real sender is preserved in Reply-To (and sometimes X-Original-* headers). The cron parser previously relied solely on Webklex getFrom(), so ITFlow treated the message as coming from support@example.com, which broke requester attribution, contact/domain matching, and email-to-ticket threading.

What changed

Updated sender resolution in cron_ticket_email_parser.php to determine the requester email using this precedence order:

1. Reply-To (Webklex)
2. Reply-To (raw headers)
3. X-Original-From / X-Original-Sender / X-Original-Reply-To (raw headers)
4. From (Webklex)
5. From (raw headers)

The display name (from_name) remains sourced from the From header’s personal name for readability.

Why this works

For “via support@…” messages, Reply-To contains the customer’s real address (e.g. customer@placeholder.com), so ITFlow can correctly:

• match existing contacts by email
• match client domains when contacts don’t exist
• create/update tickets under the correct requester
  For standard direct emails, Reply-To is typically absent or matches From, so behavior remains effectively unchanged.

Testing / verification

• Reproduced issue with an email delivered via group/list behavior showing “via support@…”.
• Confirmed Reply-To contained the true sender.
• Ran parser and verified tickets were created/updated under the real sender address and matching/threading behaved correctly.
• Confirmed normal inbound mail continues to parse as expected.

Risk / rollback

Low risk; this only changes sender selection logic and includes fallbacks to previous behavior when Reply-To/original headers are not available. Rollback is a simple revert of this commit.

[github-actions]

Hello & Welcome! :)

Thanks for taking the time to help improve ITFlow. We're excited to review your contributions - we'll review this PR as soon as we can!

Whilst you're waiting, please feel free to check out the forum.

Just so you know, all contributions to ITFlow are licensed under the GNU GPL. By contributing you grant us a perpetual & irrevocable license to include your work in ITFlow.

[sonarqubecloud]

Quality Gate passed

Issues
38 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wrongecho]

Hi @zoltan151

Thanks for the PR!

Can you please share more details of the service causing this NDR so we may test how this change works?

In any event, I think it's probably worth including this newer NDR sender identification in the new NDR block that we have if at all possible. This is where we attach the NDR to the associated ticket, or simply alert on it. NDRs don't need to create tickets by themselves, and I don't think the core 'from' code needs to be so complex to account for an edge case when it can be caught later on.

Please also ensure you're familiar with our contributing guidelines, in particular our policy on the use of AI/LLM for code contributions.

Thanks,
Wrongecho