address rejected with reverse-check - Что это означает?

[fly]

Часто возникают автоматические ответы с указанием такого вот ответа

Код: Выделить всё

SMTP error from remote mail server after MAIL FROM:<user@domen> SIZE=69128:
    host smtp2.alkar.net [195.248.191.95]: 578  user@domen address rejected with reverse-check

user@domen - естественно это изменено, чтобы программы сбора адресов для спамеров не подхватили адрес.

Как я понимаю reverse-check - это обратная проверка, т.е. определение имени по адресу. Прямое и обратное преобразование совпадают.
Подскажите хоть что ему не нравиться. Уже все ноги обгуглил =(.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Laa]

Может понимается sender-verify callout?
Ну или A-PTR-A в ДНС. Возможно вы проверили у себя, а на каком-то из ваших секондари DNS остались еще старые записи или что-то в этом духе, проверьте тщательнее.

[fly]

Да вот это тоже присутствует

Код: Выделить всё

sender-verify callout

Что означает если этот коллаут не проходит?

Врядли есть еще Днсы которые бы не обновились - уже очень давно была сделана запись у провайдера для правильного обратного резолва.

[Laa]

1. Попытка отправить письмо вашему пользователю (отправителю изначального письма), чтобы понять существует ли такой адрес. Если такая попытка закончится неудачей, то удаленный почтовый сервер будет считать что адрес отправителя подделан.

2. Проверяете и А и PTR? На всех возможных примари и секондари ДНС-серверах? Результаты одинаковы и совпадают?

[fly]

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

Код: Выделить всё

  deny    condition     = ${if eq{$sender_address}{}{yes}{no}}          
          hosts         = !127.0.0.1 : !localhost : *                   
          message       = "No sender?! Use RFC!"

Вот получается если их система проверки сама не указывает адресс отправителя то их не пустит мой сервер и в итоге от меня они тоже ниче не примут. Похоже на правду?

[dikens3]

Думаю так и есть, решение в прилепленной теме - Полезные скрипты для Exim.

[fly]

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

[Laa]

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

Код: Выделить всё

  deny    condition     = ${if eq{$sender_address}{}{yes}{no}}          
          hosts         = !127.0.0.1 : !localhost : *                   
          message       = "No sender?! Use RFC!"

Вот получается если их система проверки сама не указывает адресс отправителя то их не пустит мой сервер и в итоге от меня они тоже ниче не примут. Похоже на правду?

Эту проверку выкиньте вообще!!!
Она вам будет рубить sender verify, это раз, два -- не будете получать боунсы, которые могут лишний раз сообщить почему письмо вашего отправителя недоставлено и тд. Короче, скорее вы нарушаете rfc, а не отправитель.

Вот кусочек из rfc:
http://www.rfc-editor.org/rfc/rfc5321.txt :

Код: Выделить всё

4.5.5.  Messages with a Null Reverse-Path

   There are several types of notification messages that are required by
   existing and proposed Standards to be sent with a null reverse-path,
   namely non-delivery notifications as discussed in Section 3.7, other
   kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
   Message Disposition Notifications (MDNs, RFC 3798 [37]).  All of
   these kinds of messages are notifications about a previous message,
   and they are sent to the reverse-path of the previous mail message.
   (If the delivery of such a notification message fails, that usually
   indicates a problem with the mail system of the host to which the
   notification message is addressed.  For this reason, at some hosts
   the MTA is set up to forward such failed notification messages to
   someone who is able to fix problems with the mail system, e.g., via
   the postmaster alias.)

[dikens3]

Вынужден не согласиться с вами Laa,т.к. RFC - это не прямое требование, а всего лишь рекомендации, и, при соответствующих условиях имеет смысл им не следовать. Конечно же, если это устраивает админа почтового сервера, который идёт на эти меры.

Короче на RFC можно иногда наплевать. Вполне добротно так.

Считаю, что от пустого(<>) пользователя письма принимать не нужно, но рубить его нужно на этапе PREDATA, т.к. проверку своих пользователей можно нормально пропускать. Конечно у меня был корпоративный сервер, а не портал какой-нибудь, там не знаю.

[Laa]

dikens3, во первых можно на ты.
А во вторых с Рождеством всех!

Я сам от <> иногда рублю почту, но рублю либо на стадии predata либо на стадии data. И не рублю на стадии rcpt. Некоторые письма бывают нужные от <>, и их нельзя потерять. Бывает отправит мой пользователь письмо, а на почтовом сервере получателя пересылка куда-то, так вот такая пересылка если не сработает, то придет отлуп как раз от <>, и отправитель, если такой отлуп не получит, то будет считать что его письмо доставлено получателю... а в письме может быть контракт на сто мульонов долларов... Так что у каждого свои требования и задачи, свои истерики у своих пользователей.

[fly]

С рождеством всех !!! Спасибо за помощь в понимании сих не легких тем.
Так что бы Вы посоветовали в итоге? Совсем закоментить, перенести в другое место, или изменить как то это правило?

[dikens3]

Повторю свой совет, зайдите в полезные скрипты, там есть решение.

Блокируйте на этапе predata или data c пустым отправителем.

[Laa]

Ну если и будете блокировать на этапе predata, data, то понаблюдайте в логах за результатом. Чтобы потом не было мучительно больно. Возможно так и оставите, но возможно, что и рубанется что-то нужное