Заманчивая штука, попробовал, попользовался, проблевался и выкинул.

То есть вроде бы этот продукт работает, но как нормальный аплаянс для фильтрации почты оно не тянет. И вот вам несколько причин:
1. Он не знает, что такое recipient-фильтр
По идее, аплаянсы подобного типа должны отсечь письмо, если они не знают поле "To:"
И они отсекают, по принципу нет ящика/алиаса в инфраструктура - нет смысла делать запросы во внутреннюю инфраструктуру.
Принцип обычного аплаянса:
- загружаем и синхронизируем адресную книгу из внутренней инфраструктуры в локальный LDAP
- проверяем входящие письма на основе полей объекта inetOrgPerson (rfc2798)
- отсекаем письма с неверным recepient
- шлём стилизированные баунсы про "письмо не доставлено"
Принцип проксмокса:
- все письма, которые были проверены пайпланами проксмокса верны
- есть получатель или нет проверять нет смысла
- все письма шлём по SMTP во внутреннюю инфраструктуру.
То есть чисто теоретически можно самим поднять OpenLDAP, самим присосать адресную книгу из внутренней инфраструктуры и преобразовать её в удобоваримый формат для постфикса, самим подключить это к постфиксу и потом самим следить через консоль за своим фильтром, потому что интерфейс PMG это не поймёт. И это при том, что там LDAP-синхронизация есть, но она для другого... Она даёт пользователям из некоторого каталога доступ к веб-интерфейсу, чтобы менеджить ящик карантина, который PMG на себе держит.

2. Вечные проблемы с non-ASCII
Разработчики Proxmox не умеют решать проблемы с кодировками. Если вы так любите свой Perl5, так научитесь блин в нём писать с поддержкой Unicode. Хотя бы делайте Unicode Escape как в JSON. То есть русские буквы в имени пользователя приходили из LDAP-каталога и криво писались в строки, потому что строки не мультибайтные. А потом эти кракозяблики подавались во все интерфейсы вебки, потому что ни один вызов REST API в проксмоксовской вебке и помыслить не может, что что-то может прийти в другой кодировке.
Причем проблемы доходили до смешного. На 25-м порту висит postscreen, заворачивающий письмо в perl-скрипт. Письмо виснет в очереди, потому что в его заголовках присутствуют мультибайтные символы.
Когда я пробовал эти баги еще не были решены:
https://bugzilla.proxmox.com/show_bug.cgi?id=3005
https://bugzilla.proxmox.com/show_bug.cgi?id=2465
Я сталкивался с обоими. Сейчас вроде исправлены, но пробовать и искать новые проблемы с кодировками я уже не хочу. И если вы внимательно посмотрите на даты, то поймете сколько времени занимает у Proxmox исправления собственного неумения работать с мультибайтовыми символами. Перлопроблемы...

3. Пользователям из РФ на заметку. Cisco не даёт ClamAV в Россию, поэтому PMG, который его использует из коробки у вас не заработает. Настраивайте прокси-сервер и ходите за обновлениями через другую страну.

4. Оно конечно может быть отказоустойчивым и сбалансированным, но только через NAT/DR.
Его можно сделать отказоустойчивым через keepalived+conntrackd. 3 PMG + 2 балансировщика. Я использовал NAT для организации балансировки нагрузки, потому что сервера PMG по смыслу должны располагаться в DMZ.

А вот если вы попробуете настроить HAproxy с использованием милтера для Postfix, который она предоставляет для балансировки 25-го порта, то вы горя хапнете, когда откроете конфигурацию PMG и попытаетесь туда добавить. Заодно посмотрите, что они там навертели.

5. Как и многие разработчики Linux в Proxmox не умеют работать с каталогами.
Вот есть у вас служба каталогов во внутренней инфраструктуре с LDAP-ом и тикетами Kerberos. И вот вы хотите предоставить доступ к веб-интерфейсу управления карантинными ящиками.
Обычный аплаянс:
- заводится сервисная учетка
- настраивается делегирование и SPN
- HTTP Basic конвертируется в Kerberos
- приложение в DMZ ходит на выделеные сервера каталогов за аутентификацией и данными, на которых нет хэша паролей, аутентификация идёт по цепочке (приложение-> периметрически каталог-> внутренний каталог)
- предоставляется опция прицепить OpenID/SAML2, чтобы вынести аутентификацию вебки на прокси-сервера служб децентрализированной аутентификации в том же периметре.

PMG:
- зацепиться к основному каталогу по голому LDAP (порт 389)
- высосать объекты пользователей вместе с паролями
- хранить хэши паролей внутри LDAP-кэша перловых плугинах в недоверенной сетевой зоне.
Б - значит БЕЗОПАСНОСТЬ.

Причем я, конечно, могу поставить периметрический RODC (в случае с AD) или любой другой каталог с кастомным LDAP-фильтром, но PMG всё равно хочет хэши паролей, потому что аутентифицирует только через свою перловую форму и только относительно базы или кэша.

Ирония в том, что это решение должно было быть средством безопасности, а не дырой внутри нее. А еще оно должно быть антиспамом и мейл гейтвеем, который должен защитить от наплыва мусорного спама. И еще её кто-то там продвигал как решение для РФ, с тонной постоянно вылазящих проблем с кириллицей и заблокированным в РФ антивирусом. Ой всё...