Проверка сертификата Postfix TLS от клиентов в локальной подсети за брандмауэром

У меня есть рабочий постфиксный сервер за брандмауэром, настроенный с серым списком, DKIM, SFP, amavis и clamav, и правильно настроенный MX, запись «A» и обратная запись DNS. Я могу отправлять и получать почту на другие домены в Интернете. Постфикс использует сертификаты от LetsEncrypt для домена. Почтовый сервер расположен в частной подсети, скажем 192.168.10.0/24 за брандмауэром. И для того, чтобы это работало, я выполняю переадресацию портов для следующих портов 25,587, 465, 993, а также 80 и 443 для certbot. Я также настроил ручной статический outband nat для разрешения только на общедоступный IP-адрес, зарезервированный для почтового сервера. Пока все работает.

У меня проблема в том, что этот почтовый сервер расположен в сети 192.168.10.0/24, и отправка почты не работает для клиентов, находящихся за брандмауэром в другой локальной подсети (192.168.20.10/24) для портов TLS, т.е. 465 и 587, 25 работает !!!. Если клиенты приходят извне, все работает хорошо. Теперь каждый раз, когда эти внутренние клиенты пытаются связаться с почтовым сервером, они проходят через брандмауэр, который в данном случае также является маршрутизатором. Эти клиенты пытаются разрешить почтовый сервер, скажем, mail.mySimpleMailProject.com, и они видят, что сертификат недействителен, поскольку он сопоставляется с неправильным IP-адресом, то есть 192.168.10.5, а не с общедоступным IP-адресом.

Однако я могу отправлять почту от этих внутренних клиентов только через порт 25, и это работает. Но моя цель - отправить почту по защищенному каналу также во внутренней сети.

Я прочитал о возможном решении, т.е.

Настроить Nat Reflection

Теперь я действительно действительно НЕ хочу отражать NAT, NAT - это зло, и я пытаюсь избежать его любой ценой.

Я думаю о следующем: есть ли способ сообщить postfix

1) принять соединение из локальной сети

для этой цели у меня есть запись permission_mynetworks в smtpd_recipient_restrictions, т.е.

smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,

    reject_non_fqdn_helo_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_invalid_helo_hostname,
    reject_unknown_helo_hostname,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,

    reject_rbl_client zen.spamhaus.org,

    check_policy_service unix:postgrey/socket,
    permit

2) когда соединение, исходящее из внутренней сети 192.168.20.0/24, представляет другой самозаверяющий сертификат, который я позже могу импортировать в этих клиентов и сделать их счастливыми.

Может быть, есть другое лучшее решение этой проблемы. Любые подсказки приветствуются.