>> Есть идеи, что не так?
> Стандартно - проверяй пути, права...

Не совсем понял идею. Что конкретно глянуть?
Если бы не хватало прав на какую-то папку, то и письмо бы не ушло, не пришло.
Но всё работает как часы.

> Убери кашпировского из цепочки и сравни время.
> Тогда будет более понятно кто виноват.

Закоментил строку smtpd_milters = unix:/klms/klms_milter_sock
Время отправки без изменений.
По ощущениям какой-то медленный алгоритм приёма письма от клиента. Будто где-то надо указать другой совместимый протокол.

В порядке фантазий - разработчик по умолчанию включает в инсталляционном пакете предельно совместимый древний протокол обмена, и есть более современный, но несовместимый с каким-нибудь нетскейпом или типа того, но адекватно работающий с современными почтовыми клиентами. Надо только вписать опцию в конфиг...

> Ну если гадать только по логам и описанию проблемы, то можно посоветовать
> только http://www.postfix.org/TUNING_README.html
> Конфигурацию могли-бы показать. top можно посмотреть, количество сетевых подключений.

Буду крайне признателен.
По подключениям всё просто. Сервер в режиме тестирования - к нему обращаюсь только я.

Результат работы команды postconf -n

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 60s
append_dot_mydomain = no
biff = no
compatibility_level = 2
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 18000000
milter_command_timeout = 180
milter_connect_macros = j _ {daemon_name} {if_name} {if_addr}
milter_connect_timeout = 180
milter_content_timeout = 600
milter_default_action = tempfail
milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer}
milter_mail_macros = i {auth_type} {auth_authen} {auth_ssf} {auth_author} {mail_mailer} {mail_host} {mail_addr}
milter_protocol = 3
milter_rcpt_macros = {rcpt_mailer} {rcpt_host} {rcpt_addr}
mydestination = $myhostname, relpost, ubuntu, localhost.localdomain, localhost
myhostname = mx.mydomain.ru
mynetworks = /etc/postfix/mynetworks
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_connect_timeout = 75s
smtp_connection_cache_on_demand = yes
smtp_destination_concurrency_limit = 1
smtp_destination_rate_delay = 0s
smtp_extra_recipient_limit = 10
smtp_helo_timeout = 300s
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_client_message_rate_limit = 29
smtpd_helo_required = yes
smtpd_policy_service_max_idle = 300s```
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, check_recipient_access hash:/etc/postfix/recipient_access, defer_unauth_destination
smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, check_recipient_access hash:/etc/postfix/recipient_access, reject_unknown_sender_domain, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_unlisted_sender, reject_unauth_destination, reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport_map
virtual_alias_maps = hash:/etc/postfix/virtual,ldap:/etc/postfix/ldapalias.cf
virtual_gid_maps = static:109
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = se.local
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual_mailbox_maps.cf
virtual_minimum_uid = 100
virtual_uid_maps = static:109

Сразу отмечу, что мой IP внесён в mynetworks, и меня пропускает на самом начальном этапе проверки. Отключал и строки с ldap, но и оттуда влияния нет.
Именно медленно построчно передаётся тело письма.
Характерен итог отправки - параметр  ... delays=25/0.01/1/0.84, dsn=2.0.0, status=sent ...
Там первое число - время обработки в секундах до помещения в очередь, т.е. время приёма от клиента. Остальные цифры - время обработки на остальных этапах.
Анализ подробного лога показал, что передаётся от 1500 дл 2100 строк тела письма в секунду, что и набегает в 25 секунд на 4 мегабайта, а бывает и 32 секунды на то же самое письмо.
Гуглил немало - проблема довольно массовая, но решения не нашёл.
Работает это на виртуальной машине, под виндой 2016. Установлено в нескольких местах, проблема идентичная.
DNS вроде в норме, себя я даже в hosts прописал ))

> это куски логов выдернутые из контекста. подозрение может быть на milter, amavis
> если используется, DNS запросы, LDAP запросы.
> в master.cf что творится?
> есть логи где есть пару событий где идет начало приема почты и
> отправки чтобы судить правильнее.
>>(всего в логе более 50 000 строк на это сообщение с вложением 3М)
> сохраните на pastebin и ссюда ссылку.
> а без вложения как ведется себя?

Я выше упоминал, что в логе есть показательный параметр "delays=24/0.06/1/0.79"
Там первое число - секунды приёма тела письма сервером, а остальные три - проверки и отправка.
Т.е. за долю первой секунды проверяется мой IP на предмет "match_hostname: smtpd_client_event_limit_exceptions:", потом прочие "milter_macro_lookup" и ещё 450 строк логов предварительных ласк. И начинается поток строчек в логе типа "rec_put: type N len 76 data "
И этих строк приходится около 50 000. Длится это (в данном случае) аж 24 секунды.
На финише опять доли секунды на несколько строк завершения типа проверок хоста клиента "match_hostname: smtpd_client_event_limit_exceptions:"

Разумеется, без вложения всё происходит за секунду-две.
Каспера отключил, проблема не в нём.

Уверены, что выкладывание всего лога прольёт больше света на проблему?
Просто мне там многое надо будет "заретушировать"...