Strange behavior with automatic e-mail replies

[MinecollYT]

Hello everyone,

I currently have my own e-mail server with mailcow. So far, every service works without any problems, including the emails that are sent from/in the tickets itself from the OTOBO agent interface.

Only as soon as it is an automatic reply, e.g. after creating a ticket, I have noticed the following two behaviours:

1. We have a domain-wide footer for all emails, which gets attached to every email. These are the only emails which do not have this footer.
2. The automatic replies cannot be delivered to @gmail addresses. The reason given for this is a DMARC / SPF problem, which definitely does not exist.

5B81F85507: to=<xxxx@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.27]:25, delay=2.9, delays=2.4/0.08/0.13/0.24, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[142.250.27.27] said: 550-5.7.26 Unauthenticated email from xxxx.de is not accepted 550-5.7.26 due to domain's DMARC policy. Please contact the administrator of 550-5.7.26 xxxx.de domain if this was a legitimate mail. To 550-5.7.26 learn about the DMARC initiative, go to 550 5.7.26 https://support.google.com/mail/?p=DmarcRejection a640c23a62f3a-a7a33dee461si59154566b.743 - gsmtp (in reply to end of DATA command))

Does this indicate a misconfiguration on my part, or is this a faulty behavior on OTOBO's part?

With kind regards Jonas Leiner

[MinecollYT]

Just for clarification: This behavior only occurs with the automatic replies, emails send manually out of the ticket itself work fine with @gmail and any other addresses.

[wornet-aer]

Sounds like an issue with OTOBO itself or the configuration. This otobo-docker repo is only for installing/updating OTOBO and does not contain the main project itself.

How is your email routing configured? Are you using an explicit smarthost (your Mailcow) with OTOBO?

[MinecollYT]

Okay, I wasn't sure if I should open the issue here or in the normal OTOBO github repo.

Mailcow is almost on default settings and there are no changes regarding routing, ... and on the otobo site I just entered the normal smtp data that many other services also use without problems. So since all other emails are working, except the automatic otobo emails, I'm pretty sure my current configuration is correct. It does show an error message because of the “domain's DMARC policy”, but every other email sent via smtp works fine and without error. Is there a possibility that otobo is using a different function/method for sending these auto replies?

[wornet-aer]

Which version of OTOBO are you currently using? I am running several OTOBO instances and never had any problems with emails being routed differently than configured. I'm also a heavy Mailcow user and have one OTOBO instance connected with Mailcow for SMTP outbound sending.

What sender address have you configured for your automatic emails? It's set in SystemConfig at Core::Email::NotificationSenderEmail.

Could you try sending both types of email to an external mailbox that is not strictly DMARC checking? Both emails should have the same Received header lines. If not, you have the proof that they have been using different routes, which is probably causing your issue.

[MinecollYT]

We are currently running OTOBO 11.0.3.

My sender address is the same as the smtp auth user -->

Automatic Reply:

--

Normal/Direct Reply:

--

If I'm honest I host finished my apprenticeship in the it field and I'm not sure what exactly is going on there and why the two received datas are so extremely different and that the automatic reply even lacks the whole dkim signatur. The "x" marks the place where the signature image would normally be, as it can be seen in the direct reply

[wornet-aer]

We are still running OTOBO 10.x here on our instances. So it could be also a 11.x bug. I'll try to upgrade my first instance today, maybe I can reproduce this behaviour then.

The Received headers of your emails are looking quite similar to me. So I'd guess the routing is correct in both cases.

What I do not really understand yet, is the fact that the Return-Path Header in your broken email is <>, which makes it behave like a postmaster/bounce-mail. Probably this is also the reason, why your Mailcow is not applying the DKIM and footer signature to those emails. In our OTOBO 10.x setups the Return-Path of notification emails contains our system's sender address and is not empty <>.

I just checked the SysConfig settings again. Maybe this is the solution for your problems: Enable SendmailNotificationEnvelopeFrom::FallbackToEmailFrom or explicitly setting a sender address in SendmailNotificationEnvelopeFrom.

[MinecollYT]

That fixed the issue