Rejected mails released from quarantine lack "Received" header and spam report

[ralfbergs]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

Checklist prior issue creation

• I understand that failure to follow below instructions may cause this issue to be closed.
• I understand that vague, incomplete or inaccurate information may cause this issue to be closed.
• I understand that this form is intended solely for reporting software bugs and not for support-related inquiries.
• I understand that all responses are voluntary and community-driven, and do not constitute commercial support.
• I confirm that I have reviewed previous issues to ensure this matter has not already been addressed.
• I confirm that my environment meets all prerequisite requirements as specified in the official documentation.

Description

I noticed that a "rejected" message that was quarantined and later released into the inbox does not have a "Received" header that indicates when the message was originally received by the mailcow host.

There is a "Received" header that indicates when the message was released from quarantine (which I herewith acknowledge as being a positive surprise!), but you can't reproduce how and when the message reached the mailcow host.

The message also lacks a "spam report" in the header of the message, so that you can understand why the message collected such a big spam score so that it was rejected.

Steps to reproduce:

1. Wait until you receive a message that has such a large spam score that the original message is rejected, and a copy of the message is quarantined.
2. Release the message from quarantine into your inbox.
3. Note that a "Received" header for the original receipt of the message on the mailcow host is missing as well as the X-Spamd-Result header with the identified spam tags.

Logs:

N/A

Which branch are you using?

master (stable)

Which architecture are you using?

x86_64

Operating System:

Debian GNU/Linux 13 (trixie)

Server/VM specifications:

N/A

Is Apparmor, SELinux or similar active?

N/A

Virtualization technology:

N/A

Docker version:

N/A

docker-compose version or docker compose version:

N/A

mailcow version:

2025-12a

Reverse proxy:

N/A

Logs of git diff:

Logs of iptables -L -vn:

N/A

Logs of ip6tables -L -vn:

N/A

Logs of iptables -L -vn -t nat:

N/A

Logs of ip6tables -L -vn -t nat:

N/A

DNS check:

N/A

[mkuron]

This actually makes sense if you consider how quarantine is implemented. Technically the message is never received by Postfix, it is rejected (but we store a copy is in the quarantine database). That rejection is reported to the sender as an error.

The missing headers could certainly be inserted either in the code where the message is stored or where it is released. The information required for the Received header is probably readily available, while the information required for the spam header may need to be retrieved from the rspamd history. Please feel free to submit a pull request.

[ralfbergs]

This actually makes sense if you consider how quarantine is implemented. Technically the message is never received by Postfix, it is rejected (but we store a copy is in the quarantine database). That rejection is reported to the sender as an error.

I don't think this is technically correct. Without actually knowing how it's implemented, I'm guessing that it must be Postfix (or which component is listening on port 25/TCP, if not Postfix?) receiving the incoming message. If during the SMTP-time spam scanning the spam score is so high that the message should be rejected, Postfix then rejects the message during SMTP time towards the sending MTA, resulting in a proper non-delivery from the client MTA's perspective.

However, Postfix has received a full copy of the email. Why should there not be a Received header indicating this fact? It is exactly what happened. And even if it's not Postfix listening on port 25/TCP, then whatever component is listening there and has received the message should be listed as such in a Received header. It's bad practice having an "invisible" component that doesn't show up in a Received header.

The missing headers could certainly be inserted either in the code where the message is stored or where it is released.

I would argue both should be listed there. It's two different "hops" from the message's point of view.

The information required for the Received header is probably readily available, while the information required for the spam header may need to be retrieved from the rspamd history.

For sure.

Please feel free to submit a pull request.

Thanks, but at the moment I cannot devote the substantial amount of time to dig into it, implement it, test it, and submit it. I hope that someone who agrees with my point of view and who is familiar with the code and the architecture can do it.

[mkuron]

I'm guessing that it must be Postfix (or which component is listening on port 25/TCP, if not Postfix?) receiving the incoming message.

The terminology is a bit confusing here. The spam check happens as part of Postfix's pre-receive checks. At the end, the message is either rejected, or receipt is acknowledged and the Received header is added.

[ralfbergs]

I'm guessing that it must be Postfix (or which component is listening on port 25/TCP, if not Postfix?) receiving the incoming message.

The terminology is a bit confusing here. The spam check happens as part of Postfix's pre-receive checks. At the end, the message is either rejected, or receipt is acknowledged and the Received header is added.

Yes, it's very confusing, and it gets even more confusing...

Quoting from the Postfix doc:

default action when a Milter (mail filter) response is unavailable (for example, bad Postfix configuration or Milter failure): [...] quarantine

I could not find another scenario apart from the above where the term "quarantine" is used in Postfix.

What you call "pre-receive checks" seems to be "milter filtering" according to the official wording. And "quarantine" only occurs (according to that official wording) when there is an issue with a Milter application ("for example, bad Postfix configuration or Milter failure").

So "quarantine" in mailcow is something different than the above "quarantine" in Postfix. 🤷🏻‍♂️