День добрый!
Стоит Linux + postfix.
Возникла следующая ситуация с отправкой почты на один домен.
Отправляю письмо, удаленная система пытается сделать проверку MAIL FROM. Мой почтовик делает проверку входящего запроса и возвращает Client host rejected: cannot find your hostname.
Удаленная система считает что проверка MAIL FROM провалилась и сообщает мне 478 ... reverse check protocol error (in reply to MAIL FROM command)Причина всей этой фигни в том что мой почтовик не может сделать resolveip для удаленного сервера.
resolveip 212.154.167.215
resolveip: Unable to find hostname for '212.154.167.215'Как понимаю за блокировку отвечает reject_unknown_client?!
Должен ли я принимать почту от таких хостов или администратор удаленной системы должен настроить обратную зону для своего домена? Или можно добавить IP этого сервера в "белый список"?
Кто виноват и что делать? =)
в конфиге:
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_client,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
# check_policy_service unix:private/policy
# reject_unknown_hostname,
# reject_non_fqdn_sender,
reject_unknown_sender_domain
>Причина всей этой фигни в том что мой почтовик не может сделать
>resolveip для удаленного сервера.
>resolveip 212.154.167.215
>resolveip: Unable to find hostname for '212.154.167.215'
>
>Как понимаю за блокировку отвечает reject_unknown_client?!
>
>Должен ли я принимать почту от таких хостов или администратор удаленной системы
>должен настроить обратную зону для своего домена? Или можно добавить IP
>этого сервера в "белый список"?Вопрос чисто идеологический. Можно вообще не принимать почту ни от кого, тогда и спама не будет :)
Каждый админ решает для себя сам - на основании каких критериев он будет или не будет принимать почту. Можно проверять rdns, можно проверять по блэклистам, можно поставить spamassassin и проверять по группе параметров и начислять баллы. То же самое с фильтрацией - можно не принимать почту, можно не доставлять её пользователю, но бэкапить, например. Тут, скорее, вопрос в начальстве - что ему важнее: платить за лишний траффик, или рисковать потерей важного письма при ложном срабатывании.
>Вопрос чисто идеологический. Можно вообще не принимать почту ни от кого, тогда
>и спама не будет :)
>Каждый админ решает для себя сам - на основании каких критериев он
>будет или не будет принимать почту. Можно проверять rdns, можно проверять
>по блэклистам, можно поставить spamassassin и проверять по группе параметров и
>начислять баллы. То же самое с фильтрацией - можно не принимать
>почту, можно не доставлять её пользователю, но бэкапить, например. Тут, скорее,
>вопрос в начальстве - что ему важнее: платить за лишний траффик,
>или рисковать потерей важного письма при ложном срабатывании.Имел в виду правила. Должна ли быть указана обратная зона для почтового сервера?
>Имел в виду правила. Должна ли быть указана обратная зона для почтового
>сервера?Общих правил на эту тему нет. Есть фраза в RFC 1912 (раздел 2.1):
Every Internet-reachable host should have a name. The consequences
of this are becoming more and more obvious. Many services available
on the Internet will not talk to you if you aren't correctly
registered in the DNS.
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).Но RFC - это не требование, это рекомендация, которой можно следовать или не следовать.
На практике - если у хоста нет rDNS, очень многие от него почту принимать не будут. Поэтому лучше, чтобы было.
>Но RFC - это не требование, это рекомендация, которой можно следовать или
>не следовать.
>
>На практике - если у хоста нет rDNS, очень многие от него
>почту принимать не будут. Поэтому лучше, чтобы было.Понятно, спасибо
>>Но RFC - это не требование, это рекомендация, которой можно следовать или
>>не следовать.
>>
>>На практике - если у хоста нет rDNS, очень многие от него
>>почту принимать не будут. Поэтому лучше, чтобы было.
> Понятно, спасибоЕщё столкнулся с идентичным отлупом на реверсной проверке, когда один из сотрудников в имени хоста почтового (после @) использовал заглавные буквы. Переотослал нормально строчными - проблема была устранена.