Attachments from Incoming Email Tickets Download as 0-Byte Files

Technical assistance
1

Infos:

  • Used Zammad version: Docker Image 6.3.1-109
  • Used Zammad installation type: (source, package, docker-compose, …) docker-compose
  • Elasticsearch version: [e.g. 7.17] 8.14.3
  • Operating system: Debian 12
  • Browser + version: Firefox 129.0
ELASTICSEARCH_VERSION=8.14.3
IMAGE_REPO=ghcr.io/zammad/zammad
MEMCACHE_SERVERS=zammad-memcached:11211
MEMCACHE_VERSION=1.6.29-alpine
NGINX_PORT=8080
NGINX_EXPOSE_PORT=8080
POSTGRES_DB=zammad_production
POSTGRES_PASS=redacted
POSTGRES_USER=zammad
POSTGRES_HOST=zammad-postgresql
POSTGRES_PORT=5432
POSTGRES_VERSION=16.3-alpine
POSTGRESQL_OPTIONS=?pool=50
REDIS_URL=redis://zammad-redis:6379
REDIS_VERSION=7.2.5-alpine
RESTART=always
# Use a fixed version. You are responsible to update this to newer patch level versions yourself.
VERSION=6.3.1-109
# You can also use floating versions that will give you automatic updates:
# VERSION=6.2     # all patchlevel updates
# VERSION=6       # including minor updates
# VERSION=latest  # all updates of stable versions, including major
# VERSION=develop # bleeding-edge development version

Expected behavior:

  • Attachments should download with their full size and content

Actual behavior:

Attachments from incoming email tickets are being downloaded as 0-byte files when using the desktop web interface. The files can be downloaded just fine via API calls (curl -H "Authorization: Token token=supersecrettoken" https://tickets.replaceddomain.org/api/v1/ticket_attachment/10479/14039/32228?disposition=attachment -o test.pdf)

Forwarding the email to a personal mailbox via Zammad allows the attachments to be downloaded without any issues. Additionally, attachments from older tickets in the system can still be downloaded without any problems.

Steps to reproduce the behavior:

  • Receive an email with a PDF or DOCX attachment in Zammad.
  • Access the ticket via the Zammad Web-UI.
  • Attempt to download the attachment.
  • Observe that the downloaded file is 0 bytes.

Troubleshooting Steps Taken:

  • Attempted downloading the attachment on different desktop devices and browser configurations.
  • Rebuilt the Elasticsearch cluster.
  • Downgraded Zammad to Docker Image version 6.3.0.
  • Verified that the issue is consistent across various setups.
  • Verified that the download URL seems correct and the server logs show the corresponding GET request.
  • The dev console did not log any errors during the download attempt.
  • The attachment appears to be saved correctly with its contents in the Zammad database, as verified by downloading via the API call or by forwarding the ticket to a normal mailbox.

Additional Information:

  • The problem is specific to new email attachments. Older attachments in the system can still be downloaded without issue.
  • Files uploaded via the Zammad UI can be downloaded normally.
  • The issue now persists even on mobile browsers after further testing.
  • An example .eml file has been attached (zipped due to GitHub restrictions).

And gerenall just a big thank you for providing Zammad and you guys helping out the community—it has been an invaluable tool for us over the years!

The GH issues in question for the logs, attachments, etc: Empty attachments after download · Issue #5297 · zammad/zammad · GitHub

2

I’ll throw a wild guess and say that you’re using Microsoft 365 Mailboxes?
If so, Microsoft has a “security feature” that is a issue for automated ticket systems due to the way it works.

It’s called “Safe Attachment Policy” and, if set to Dynamic Deliverywill cause Microsoft to put the mail with attachment into the recipients mailbox, but replaces the attachment with a place holder while scanning the attachment.

While this process ideally is fast, Zammad might be “faster” in fetching the incorrect / incomplete email. Zammad will not re-fetch fetched emails and thus the attachment is a incorrect place holder.

Choose Block instead (which should be the default) which will cause slight delay in mail processing, however, will ensure that Zammad doesn’t fetch incomplete and broken stuff.

3

Hi,

Thank you for your response.

In the meantime, I managed to resolve the issue. It turns out we are using Traefik as a reverse proxy for the instance, and the problem was caused by incorrect headers in the configuration. These headers were preventing attachment downloads. Once I commented out the relevant parameters, everything worked as expected.

The headers I excluded from the configuration are as follows:

      headers:
        browserXssFilter: true
        contentTypeNosniff: true
        forceSTSHeader: true
        frameDeny: true
        referrerPolicy: same-origin
        stsIncludeSubdomains: true
        stsPreload: true
        stsSeconds: 31536000
        customFrameOptionsValue: "SAMEORIGIN"
1 Like