Search results

from a quick look in the code and a quick check on a testsystem - no (the part rewriting the postfix config templates calls postmap for all needed files)

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...

Currently /etc/pmg/transport and /etc/pmg/domains are the authoritative source of the information in the API - so it should work fine to just edit those files. This might change in the future (for all readers who read this later) - so check the changelogs/release notes for versions after 9.0...

hm - just to not miss anything - is the affected system a Proxmox Mail Gateway? In any case - the issue seems rooted in Veeam - so asking there might yield better results. I don't have experience with Veeam application backups - so I might miss something. The error message seems like Veeam's...

hm - that response code does not look like it's coming from a regular PMG - maybe check the logs of the mailserver that should have received the message. else - yes the message is gone (technically it is still on the disk as long as the quarantine life-time of the message has not expired) in...

see: https://forum.proxmox.com/threads/proxmox-mail-gateway-security-advisories.149333/post-838667:

if they are queued on your PMG - you can try with `postqueue -i <queue-id>`

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...

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...

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 Interesting - we tested the functionality of the change (rooted in: https://metacpan.org/pod/MIME::Head#ambiguous_content and...

The log-lines give already a good hint at the area of the issue - with those (and the complete mail as .eml) it's usually possible to find the issue.

* 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

See https://forum.proxmox.com/threads/detected-undelivered-mail-to.180292/post-840426 for a bit more details - else this change is due to: https://forum.proxmox.com/threads/proxmox-mail-gateway-security-advisories.149333/post-838667 and you can allow such mails - and then selectively decide...

The change is related to a potential security issue addressed in: https://forum.proxmox.com/threads/proxmox-mail-gateway-security-advisories.149333/post-838667 You can selectively allow broken mails by adding rules that match on the added X-Proxmox-Broken-Message header - see the documentation...

You can use the None matches modifier for the who-object: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_application_of_rules else - add accept to the rule with your who-object, and add the disclaimer in a rule with lower priority I hope this helps!

the first status `accepted` says that PMG has accepted the mail for delivering it to the next server (instead of blocking it, adding it to quarantine, rejecting it in postscreen) - the second status `delivered` says that PMG sent the mail to the receiving mailserver and got a 250 OK back yes -...

genau, das ist das neue Verhalten - ich würde anregen, solche mails eher nur von eingeschränkten Gruppe an Sendern anzunehmen (wie in den docs beschreiben eine dementsprechende Regel machen). die Logs können wieder hier gelöscht werden (da ja doch echte mail-adressen drinnenstehen).

bitte mal die gesamten logs zu einer betroffenen mail posten. Potentiell schickt das ticket-system mails, die missverstaendliche, oder nicht ganz korrekte MIME-Struktur haben: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_broken_mime Solche mails werden seit kurzem...

siehe: https://forum.proxmox.com/threads/dkim_invalid-but-dkim-is-valid.180964/post-839411 (ist die max spamsize >= die max email size)? falls das nicht das problem ist - könnte es noch am verwendeten DNS Resolver für PMG liegen. ein lokaler unbound sollte das richtig machen...

This is explained in the docs, which @mfederanko linked: you need to change the signing domain source to 'header' instead of envelope. I hope this helps!