столкнулись с такой интересной ситуацией:
При отправке писем наружу (на 2 конкретных доменных имени) в логах на своем postfix (exchange server пересылает письма наружу через postfix, то есть postfix выступает как MTA) мы наблюдаем ситуацию, при которой письма, отправляемые на два конкретных внешних почтовых домена не достигают получателей, причем объем этого письма буквально несколько КБ:
Jun 26 12:38:37 postservice postfix/smtp[16792]: F22BC40AA2: to=<user@domain.ru>, relay=mx.domain.ru[89.89.89.89]:25,delay=123, delays=0.01/0/0.12/123, dsn=4.4.2, status=deferred (lost connection with mx.domain.ru[89.89.89.89] while sending end of data -- message may be sent more than once)
Из-за невозможности доставить postfix повторял отправку письма 4 раза до достижения результата:
Jun 26 13:30:44 postsetvice postfix/smtp[16951]: F22BC40AA2: to=<user@domain.ru>, relay=mx.domain.ru[89.89.89.89]:25,delay=3251, delays=3250/0/0.11/0.76, dsn=2.0.0, status=sent (250 ok: Message 647962 accepted)
И вроде, все ок, почта доставлена, но… в компании, которой принадлежат эти почтовый домены утверждают, что все получатели, которым было предназначено это письмо получили его по 4 раза – ровно столько, сколько было попыток пересылки. Так же в этой компании говорят что проблемы с многократным получением одного письма имеют место быть только если отправителем является наша организация.
Проблема, повторюсь, исключительно с 2-мя почтовыми доменами. Все остальные внешние получатели проблем не испытывают. Опять же проблемы бывают не всегда, большая часть писем получателям в этом почтовом домене уходит беспрепятственно. Бывают ситуации, когда буквально с разницей в несколько секунд 3 письма отправляется на этот почтовый домен, 2 из них сразу оказываются доставленными, а одно болтается в очереди с формулировкой status=deferred (lost connection with mx.domain.ru).
Вопрос: не вдаваясь в то, какая почтовая система у той организации, куда копать на нашем postfix, чтобы диагностировать неисправность, если она на нашей стороне.local_recipient_maps =
mydestination = $mydomain, $myhostname, localhost.$mydomain
transport_maps = hash:/etc/postfix/transport
relay_domains = $mydomain, mydomain.ru.
smtpd_banner = $myhostname ESMTP.
queue_minfree = 720000000
mailbox_size_limit = 0
message_size_limit = 52582912
bounce_queue_lifetime = 230m
maximal_queue_lifetime = 4h
minimal_backoff_time = 15m
maximal_backoff_time = 240m
delay_warning_time = 50m
local_destination_concurrency_limit = 3
smtp_recipient_limit = 10
default_destination_concurrency_limit = 6
#smtpd_reject_unlisted_sender = yes
disable_vrfy_command = yes
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
smtp_always_send_ehlo = yes
smtpd_hard_error_limit = 4
connection_cache_protocol_timeout = 120s
kolabpolicy_time_limit = 3600
#kolabpolicy_max_idle = 20
#smtp_generic_maps = hash:/etc/postfix/maps
smtp_helo_name = smtp.mydomain.ru
smtp_helo_timeout = 600s
smtp_data_done_timeout = 650s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 220s
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access hash:/etc/postfix/sender_access
reject_unknown_client_hostname
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_helo_hostname
reject_non_fqdn_sender
reject_non_fqdn_hostname
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client zen.spamhaus.org
# reject
receive_override_options = no_address_mappings
> Вопрос: не вдаваясь в то, какая почтовая система у той организации, куда
> копать на нашем postfix, чтобы диагностировать неисправность, если она на нашей
> стороне.Снимать полный tcpdump сессии доставки почты, вместе с передаваемыми данными, потом смотреть и разбирать по=полочкам.
> Снимать полный tcpdump сессии доставки почты, вместе с передаваемыми данными, потом смотреть
> и разбирать по=полочкам.никогда не делал подобное.
оно?
tcpdump -w /file/name -s 2000 host example.com 25
>> Снимать полный tcpdump сессии доставки почты, вместе с передаваемыми данными, потом смотреть
>> и разбирать по=полочкам.
> никогда не делал подобное.
> оно?
> tcpdump -w /file/name -s 2000 host example.com 25tcpdump -w /file/name -s 2000 host example.com and port 25
У меня бывали случаи когда антивирусы не давали корректно завершить smtp-сеанс.
> У меня бывали случаи когда антивирусы не давали корректно завершить smtp-сеанс.На юниксе с постфиксом? 8-)
>> У меня бывали случаи когда антивирусы не давали корректно завершить smtp-сеанс.
> На юниксе с постфиксом? 8-)Анононим не вкурсе :)
А если попинговать с большими размерами пакетов?Было подобное, кажется решали проблему установкой MTU
> А если попинговать с большими размерами пакетов?
> Было подобное, кажется решали проблему установкой MTUFAQ Постфикса тоже с Вами согласен. http://www.hsc.fr/ressources/cours/postfix/doc/faq.html#time...
Ну и вдогонку.
------------------
*Enable* Path MTU discovery, or set a reasonably
low MTU (usually something around 1380 rather than 1500 is enough to
accomodate most MTU reducing VPNs). Don't block ICMP "unreachable"
messages.
----------------
> А если попинговать с большими размерами пакетов?к сожалению, пинги к тому почтовому серверу не ходят.
Видимо ICMP протокол на их стороне заблокирован.> Было подобное, кажется решали проблему установкой MTU
меньше 1500?
> меньше 1500?Исесвенна (вон вверху все написано). Но вообще сетевой стек должен сам уменьшать размер MTU на основании анализа "трассы" до конечной точки. Но в случае, если разрешно то, что называется Path MTU Discovery (не заблокировано на файрволле). Вот тут, например, можно почитать об ентом зверюге - http://habrahabr.ru/post/136871/
>-- message may be sent more than once)структуру сети давай, роуты итд. это вопрос явно не по postfix.
> столкнулись с такой интересной ситуацией:
> Вопрос: не вдаваясь в то, какая почтовая система у той организации, куда
> копать на нашем postfix, чтобы диагностировать неисправность, если она на нашей
> стороне.Не раз такое было, на принимающем сервере происходит перегрузка антиспама, антивируса и прочих "наворотов". Обычно такое лечится сравнением логов на обоих серверах.
Еще вариант убрать:
smtp_helo_timeout = 600s
smtp_data_done_timeout = 650s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 220s.
Если у них, или у тебя канал забит, письмо может не уложиться в указанный интервал.P.S. Postfix написали вполне грамотные люди, и тюнить его без крайней необходимости не надо. Достаточно изменить только необходимые параметры:
mydestination
transport_maps
relay_domains
smtpd_banner
message_size_limit
disable_vrfy_command
smtpd_recipient_restrictions
disable_vrfy_command
smtpd_helo_required
smtp_recipient_limit