[SOLVED] detected undelivered mail to

The 'detected undelivered mail' message is usually the result of the new security checks on malformed MIME parts. If you see 'message has ambiguous content' or 'unable to parse message' in your logs, that is the culprit. You can get these moving again by following the documentation to allow broken messages for specific rules. It is a common pain point right now for anyone receiving automated reports or legacy system emails that do not strictly follow MIME standards.
 
Stoiko Ivanov said:
an e-mail (putting the .eml and logs in a zip-file so they don't get rejected by our PMG) to s.ivanov _at_ proxmox.com would work
Click to expand...
Done.
Stoiko Ivanov said:
Anyways - enabling the 'Allow Broken MIME Structure' checkbox should bring back the behavior before the patch (only adding the X-Proxmox-Broken-Message header) - it's just nothing we'd recommend in general - if mail in your environment are vastly affected by this I think it can be ok, else if you can identify which senders/content of a mail cause this - adding rules to your rule-system to only accept those mail, and reject all other broken mime mails would be better.

I hope this helps!
Click to expand...
lilydawson said:
The 'detected undelivered mail' message is usually the result of the new security checks on malformed MIME parts. If you see 'message has ambiguous content' or 'unable to parse message' in your logs, that is the culprit. You can get these moving again by following the documentation to allow broken messages for specific rules. It is a common pain point right now for anyone receiving automated reports or legacy system emails that do not strictly follow MIME standards.
Click to expand...
Already allowed it. Things are working now, but as Stoiko Ivanov said, better to use fine-grained rules.
 
laurensb said:
Done.
Click to expand...
Thanks ! As a summary for the public:
* Issue with the mails was that the pdf-attachments have technically 2 'filename' parameters in their content-disposition headers - one as 'filename', the other as RFC2231 (https://datatracker.ietf.org/doc/html/rfc2231) encoded 'filename*0*' - as both of these are present the parser (arguably so) says it's ambiguous.

This is the same issue that @sterzy addressed in: https://lore.proxmox.com/pbs-devel/20260225112107.99905-1-s.sterz@proxmox.com/T/#u - see the commit message for further details.
 
Hi, I have applied the fix, but the emails are still stuck in queue, si there anyway we can get these emails to deliver?
 
andres-asm said:
I am still in proxmox 8, would rolling back to 8.1.3 from 8.1.4 work like on the other person's case?
Click to expand...
installing the update, and allowing broken mime should work - the mails should either be resent by the sending server (before-queue-filtering) - or by postfix on PMG (after-queue-filtering) eventually (can take up to a few hours depending on how long they have been queued) - and with accept broken mime enabled they should be processed successfully.

I hope this helps!
 
if they are queued on your PMG - you can try with `postqueue -i <queue-id>`
 
Stoiko Ivanov said:
* please run `pmgconfig sync -restart 1` - then check the main.cf again.
* do you have any overrides in /etc/pmg/templates?

if this does not help, please do share the contents of /etc/resolv.conf, /etc/hosts, and the rendered /etc/postfix/main.cf
Click to expand...

no more localdomain reports into the log files. Problem should be solved. Thanks for you fast help.
 
  • Like
Reactions: Stoiko Ivanov
in PMG 8 the issue remains... I was having login issues due to the downgraded PMG API (I resorted to that the other day).
I updated again this week and the issue came back:

1772744451373.png

This is enabled but the issue still happens
 
and I updated to PMG9 and the issue is still there for me with Accept Broken MIME Structure enabled

8A9C4181F9C 367715 Thu Mar 5 15:53:23 carla.flores@qsi.ec
(host 127.0.0.1[127.0.0.1] said: 451 4.4.0 detected undelivered mail to <ana@redacted.com> (in reply to end of DATA command))
ana@redacted.com
(host 127.0.0.1[127.0.0.1] said: 451 4.4.0 detected undelivered mail to <info@redacted.com> (in reply to end of DATA command))
info@redacted.com
(host 127.0.0.1[127.0.0.1] said: 451 4.4.0 detected undelivered mail to <rober@redacted.com> (in reply to end of DATA command))
rober@redacted.com
 
please share the complete journal around that time - this is not the only cause of "detected undelivered mail to"... - maybe pmg-smtp-filter had another issue, or postfix is not running properly...
 
Same Problem on my side.
Mail Gateway 9.0.6 - All Enterprise Repo Updates applied

Emails from one our internal appservers to external O365 (special transport rule with no MX) are failed to send today.

As you requested some journal logs I found for this:
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[869]: Starting "1" children
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[1283]: 2026/04/16-07:51:41 CONNECT TCP Peer: "[127.0.0.1]:44402" Local: "[127.0.0.1]:10023"
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[1281]: C154469E078ED09A7F: unable to parse message - unexpected end of preamble
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[1281]: fast exit because of errors (free 245129216 bytes)
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[1283]: C157169E078ED123BD: unable to parse message - unexpected end of preamble
Apr 16 07:51:41 spmmg1 pmg-smtp-filter[1283]: fast exit because of errors (free 245129216 bytes)

After accept-broken-mime = 1 it worked:
Apr 16 08:00:00 spmmg1 pmg-smtp-filter[1663]: 2026/04/16-08:00:00 CONNECT TCP Peer: "[127.0.0.1]:54280" Local: "[127.0.0.1]:10023"
Apr 16 08:00:00 spmmg1 pmg-smtp-filter[1663]: C18C569E07AE0E65EE: new mail message-id=<1485470407.6010.1776319200881@appserver1>
Apr 16 08:00:01 spmmg1 pmg-smtp-filter[1663]: C18C569E07AE0E65EE: accept mail to <user@ourdomain.de> (0F174C18C9) (rule: default-accept)
Apr 16 08:00:01 spmmg1 pmg-smtp-filter[1663]: C18C569E07AE0E65EE: processing time: 0.163 seconds (0, 0.082, 0)

In Tracking Center I also found this message:
message caused errors during parsing: unexpected end of preamble#012 adding header

Hope that helps to find the real issue
 
AlexanderH said:
Same Problem on my side.
Mail Gateway 9.0.6 - All Enterprise Repo Updates applied
Click to expand...
The issue is with the format of the e-mail, which does not pass the stricter parsing introduced due to:
ProxmoxSecurityAdvisory

Post in thread 'Proxmox Mail Gateway - Security Advisories'

Subject: PSA-2026-00005-1: Bypass of mail filters through confusion of the MIME Parser​


Advisory date: 2026-02-17

Packages: pmg-api, libmime-tools-perl

Details: The parser initially processing e-mails for further analysis was set to not cause an error on non-standard and ambiguous information in the 'Content-Type' header:
- multiple occurrences of a 'Content-Type' header
- mulitple boundary parameters for multipart messages
- backslash as part of the boundary parameter for multipart messages
- non-printable and non ASCII characters as part of the boundary...

The options for fixing this (in order of preference):
* Fix the mails that fail being parsed on the sending system
* create a rule that matches only the senders sending such mails, and allow them, create another rule that blocks mails having the header added and enable accept-broken-mime
* just enable accept-broken-mime and be aware that some malicious e-mails can pass through

see also:
https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_broken_mime

I hope this helps!
 
You must log in or register to reply here.
Top Bottom
Back