No incomming Mails after Update

Infos:

  • Used Zammad version: 4.1.x
  • Installation method (source, package, …):
  • Operating system: Ubuntu 20.04.2 LTS
  • Database + version: psql
  • Elasticsearch version: 7.13.1

Expected behavior:

  • Zammad accepts mails as usual

Actual behavior:

  • Zammad has been running with us for more than a year without any problems.
    Now we have the problem who we are updating [4.1.0-1628189510.ad8bc927.focal amd64 [upgradeable from: 4.1.0-1623058318.8522a752.focal]
    Incoming mails are no longer accepted by Zammad.
    Mail is configured as follows:
    Dispatch messages with Sendmail — Zammad Dokumentation
    we run an exim that accepts the emails and forwards them to Zammad.
    In the Exim Log, the mail is properly accepted and forwarded to Zammad.

After rollback a Snapshot, Zammad work.
I checked Zammad-Changelogs, but i cant found anything in this way…

Steps to reproduce the behavior:

Thanks in advanced

I’m afraid we can’t help you without logs.
You’re claiming “Zammad not accepting mails” - if that’s the case there must be error messages.

This is actually for outbound and technically has nothing to do with inbound configurations at all.

You may talk about this possibly:
https://admin-docs.zammad.org/de/latest/channels/email/advanced/fetchmail.html

Thanks for your reply.

Iam back from holiday on Monday.
I will reproduce the issue in the night from Monday to Thursday and send the Logs.
Give me a little time to explain everything correctly.

Greetings from Cyprus.

1 Like

Hello everyone.

I’ll try to explain it again.
We’re on the version, everithing work fine:
4.1.0-1623058318.8522a752.focal

After updating to:
4.1.0-1629522123.80c5aa09.focal

It is no longer possible to receive incoming mail.
So, a customer can no longer send us emails to the ticket system.

Outgoing mail sent from the ticket system will continue to work.

Our mail settings in Zammad are similar to the one described here:
https://admin-docs.zammad.org/en/latest/channels/email/advanced/fetchmail.html

We do not use “Fetchmail” to read the mailbox via POP3 / IMAP. We use “Exim” as a mail transfer agent to receive the mails directly to the Zammad host via SMTP incoming.
We piped the mail directly to “rails r ‘Channel :: Driver :: MailStdin.new (trusted: true)’”

Our Exim Config:
zammad_named_group:
debug_print = “R: zammad_named_group for $ local_part @ $ domain”
driver = accept
domains = + zammad_domains
local_parts = cdb; /etc/exim4/zammad-groups.cdb
transport = zammad_delivery
; transport = zammad_procmail_delivery
headers_add = “X-Zammad-Ticket-Group: $ {lookup {$ local_part} cdb {/etc/exim4/zammad-groups.cdb}}”
headers_remove = “cc”
headers_remove = “bcc”
headers_remove = “to”

zammad_delivery:
debug_print = “T: zammad_delivery for $ local_part @ $ domain”
driver = pipe
environment = “SYS_HOME = / home / zammad: RAILS_ENV = production: GEM_PATH = / opt / zammad / vendor / bundle / ruby ​​/ 2.5.0 /”
path = “/ opt / zammad / bin: / opt / zammad / vendor / bundle / bin: / sbin: / bin: / usr / sbin: / usr / bin”
command = rails r ‘Channel :: Driver :: MailStdin.new (trusted: true)’
user = zammad
group = zammad
delivery_date_add
return_path_add
envelope_to_add

We can see in our Exim.log that the mail arrives successfully via SMTP on the Exim and is also processed there.
But If the mail is pipped to “rails r Channel :: Driver …”, it disappears in a black hole, or something.

Exim.log:
2021-08-23 21:12:14 1mIFMk-000DZt-7k <= user@xxxx.net H = corp-mail.xx.xxx.net [xxx.xx.xxx.14] P = esmtps X = TLS1.3 : ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM: 256 CV = no S = 6081 id=627401b54792462da2efaa43225fd9b5@xxxx.net
2021-08-23 21:12:14 1mIFMk-000DZt-7k ** xxxxx@xxxxx.net R = zammad_named_group T = zammad_delivery: Child process of zammad_delivery transport returned 1 from command: / opt / zammad / bin / rails
2021-08-23 21:12:14 1mIFMk-000Da0-GJ <= <> R = 1mIFMk-000DZt-7k U = Debian-exim P = local S = 7333
2021-08-23 21:12:14 1mIFMk-000DZt-7k Completed
2021-08-23 21:12:14 1mIFMk-000Da0-GJ => user@xxxx.net R = dnslookup T = remote_smtp H = corp-xxxxx.net [xxx.xx.xxx.14] X = TLS1.3: ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM: 256 CV = yes C = “250 2.0.0 17NJCEea004075-17NJCEec004075 Message accepted for delivery”
2021-08-23 21:12:14 1mIFMk-000Da0-GJ Completed

If wie go back to the old version: (recover snapshot)
4.1.0-1623058318.8522a752.focal

Mail work normally

We think that something must have changed in the new Zammad version, since we only update Zammad, all other components remain untouched.

production.log

Hello all,
any news Information or help in this case? :wink:

Here’s the reason.
Return code 1 doesn’t seem right, does it?

Your production.log won’t hold the information your looking for because the command you’re using on exim end already fails.

Try running it manually to see what the issue is.
I can’t help you at this point.

Okay, thank you for your help and reply.
I will try to found the solution…
But for me, Something change in Zammad, without any information in changelog.
Its not normal that this solution happens after update, without any changes in our system!

Definitely NOTHING has changed from stable 4.1 to 4.1 in that scope mate.

Hello,

i found it…

In Our Exim Conf we use:
zammad_delivery:
command = rails r ‘Channel :: Driver :: MailStdin.new (trusted: true)’

Same part from admin docs you write:

Command line:
su - zammad cd /opt/zammad cat test/fixtures/mail1.box | rails r ‘Channel::Driver::MailStdin.new(trusted: true)’
https://admin-docs.zammad.org/en/latest/channels/email/advanced/fetchmail.html

But this is not working anymore, after Update to higher Zammad Version.
I change this after Update to:
command = zammad run rails r ‘Channel :: Driver :: MailStdin.new (trusted: true)’

and everything work normal.

Possible something with rails change in higher Version, i can not say. We are happy to make Updates now.

Greetings
Inline

This probably never worked because above command mentioned is for source code installations.
Maybe someone was hacking around that by providing environments for it until it accidently was killed by an update or migration. Can’t tell.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.