Это - хорошая практика или слишком драконовский для отклонения писем от mailservers без RDNS
Ничто не на 100% прозрачно. Отказоустойчивой кластеризации связали время простоя во время остановки, и запустите на другом узле. Если приложение с поддержкой кластеров и/или имеет логику повторной попытки, не проблему. Имя экземпляра остается тем же, таким образом, на том уровне кластеризация прозрачна.
Репликация и передача журналов имеют различные имена серверов (источник/место назначения), таким образом, необходимо использовать своего рода technology/alias/whatever, чтобы абстрагировать смену имени и/или смочь изменить конфигурацию приложения (предполагающий, что они не сделали имен hardcode). Зеркальное отражение базы данных имеет несколько подобную историю, но если приложение кодируется к SNAC, Вы можете использовать автоматическую обработку отказа со Свидетелем.
DBM/log shipping/repl также требуют, чтобы Вы синхронизировали объекты не вне базы данных и удостоверились, что резервное устройство имеет все, что это должно выполнять (включая логины на уровне экземпляра).
Таким образом, только отказоустойчивая кластеризация и DBM со Свидетелем и высокой безопасностью дадут Вам автоматическую обработку отказа. Это не означает прозрачный обязательно.
Нет никакого абсолютного правильного способа сделать это. Это основано на Ваших требованиях (включая полный SLAs, RTOs и RPOs).
Если у Вас есть проблемы с зеркальным отражением, это мог бы быть ввод-вывод и/или связанная сеть. Это может не иметь никакого отношения к SQL. Таким образом, поскольку Вы смотрите на новую архитектуру, удостоверьтесь, что Вы оцениваете все уровни решения.
Я пробовал несколько подходов с проверкой HELO / EHLO с довольно приличной клиентской базой от 100 000 до 200 000 пользователей и в итоге выбрал решение который выполняет следующие действия:
- Убедитесь, что HELO / EHLO содержит доменное имя. - В основном это сводится к тому, есть ли в названии точка. Проверка DNS на имени привела к МНОГИМ отказавшим серверам, так как нередко сервер представляет внутреннее имя или что-то, что вы не можете правильно разрешить.
- Убедитесь, что IP имеет обратную запись DNS. - Опять же, это слабая настройка, поскольку мы не сравниваем ее с HELO / EHLO. Проверяя HELO / EHLO, созданное так много билетов, эта настройка не длилась даже одного дня.
- Проверьте правильность доменного имени отправителя. - Это базовая проверка, чтобы убедиться, что, если нам действительно нужно отклонить сообщение, будет хотя бы какой-то способ найти для него сервер.
Вот блок Postfix, который мы используем для этих проверок:
smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_unauth_destination,
reject_unknown_reverse_client_hostname,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_sender_domain,
reject_non_fqdn_recipient
Чрезвычайно часто блокируют SMTP-серверы, у которых нет этих основ:
- Имя хоста в пересылке HELO разрешается как IP-соединение, с которого было отправлено.
- IP-адрес источника соединения меняется на заявленное имя хоста в HELO.
- Если существуют политики SPF, DKIM или DMARC, проверьте.
Любой, кто борется за то, чтобы его заблокировали из-за одной из этих политик, должен быть заморожен. Я сочувствую людям, которые в конечном итоге оказываются заблокированными по другим причинам, особенно в ситуациях, когда в «ненормальных» ситуациях полагается на соответствие RFC. Спам - такая проблема, что нет оправдания упущению основ.
Я бы ожидал, что отправка MTA будет иметь действительный RDNS, но настаивание на совпадении EHLO будет зависеть от того, кто такие «клиенты». Вы можете найти некоторые интересные рекомендации в RFC5321 :
2.3.5.
(...) Имя домена, указанное в команде EHLO, ДОЛЖНО быть либо первичное имя хоста (доменное имя, которое разрешается в адрес RR) или, если у хоста нет имени, литерал адреса (...)
4.1.4.
(...) SMTP-сервер МОЖЕТ проверить, что аргумент имени домена в Команда EHLO фактически соответствует IP-адресу клиента. Однако, если проверка не удалась, сервер НЕ ДОЛЖЕН отказываться принимать сообщение на этой основе.
но затем в 7.9.
Это хорошо установленный принцип, согласно которому SMTP-сервер может отказать в приеме почты по любой оперативной или технической причине, которая делает смысл сайта, предоставляющего сервер. (...)
Обратный поиск не обязательно указывает на имя хоста, указанное в HELO. Иногда несколько доменов размещаются на одном хосте, и все они имеют один и тот же IP-адрес. Но когда вы попытаетесь выполнить обратный поиск, вы получите имя, которое было помещено в PTR-запись. Очевидно, что оба FQDN будут разными - и это вполне приемлемо.
Единственное обстоятельство, которое позволяет отбросить сообщение, - это неудачный обратный поиск. Любой успешный поиск означает, что хост действителен. Имена не должны совпадать.
Мне интересно, следует ли мне также блокировать хосты, у которых нет действительного RDNS, соответствующего EHLO?
Нет, не следует. Блокирует всю электронную почту только по одному критерию, это плохая практика.
Если я сделаю это, буду ли я создавать проблемы из-за большого количества законной почты и расстраивать своих клиентов?
более вероятно, что вы это сделаете, и вы потеряете законную почту.
Мне также интересно, могу ли я пойти на компромисс, проверив, что RDNS хотя бы настроен на что-то, но не пытаюсь сопоставить его с EHLO. Возможно ли это с Postfix (и полезно ли это)?
Да, возможно. Вы можете использовать reject_unknown_reverse_client_hostname вместо reject_unknown_client_hostname
К сожалению, postfix не имеет гибких опций для «сложного решения». В exim вы можете добавить несколько очков для таких писем, например,
Score = 0
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...
и так далее. После того, как все проверки будут завершены, и если ваш счет будет> 100, вы можете отклонить почту. На самом деле вы можете получить такое поведение, но вам нужно будет написать свою собственную службу политик