Потеряешь половину нормальных писем...

Потеряю почти весь спам и письма от серверов, где живут ленивые и тупоголовые админы, для которых RFC-1123 & RFC-2821 не указ :) Ну не хочу я от них почту ;)

Уточняю вопрос: в заголовке письма вижу - ... Received: from colima.com ([xxx.xxx.xxx.xxx]); ...

Это стопудово спам. colima.com - не резолвится. Обратной зоны для адреса xxx.xxx.xxx.xxx нет.

Т.е. задача: если сендер не резолвится, проверить Хело, если не резолвится или резолвится в другой ИП адрес, то килять. З.Ы. По статистике легитимных систем единицы процентов, которые так хреново настроены. Я готов не вступать с ними в контакт. Пусть исправляются :) Есть решение на этот счет? Я знаю, что это можно легко реализовать через милтеры, но хотелось бы решение на встроенном языке сендмыла. Спасибо :)

В sendmail.mc убрать строчку

FEATURE(`accept_unresolvable_domains`)

тогда при сборке в sendmail.cf появится строчка типа

Kresolve host -a ...

Для полной понятности смотри m4/proto.mc, там есть ifdef по этому поводу

Проверить так:

telnet yourhost 25

mail from: user@blabla

Error

Работает это в составе правила check_mail и никакие мильтеру не нужны

Этой строчки и так нет :))) Письма идут с существующих доменов и даже существующих (подставных) ящиков. Задача сводится к разбору HELO и хоста сендера. Я полагаю необходимо написать правила, которые оперируют с макросами $s (это HELO), ${client_addr} и ${client_resolve} Поместить эту ботву куда-нить в local_check_relay.

Т.е. если $&{client_resolve} not equal OK, то проверить $&s - если не резолвится - в сад, если резолвится, то сравнить с $&{client_addr} Не равно - в сад.

Ау, есть профессионально владеющие Сендмылом? :)

Вообще HELO клиент может выставить любым. А насчет check_mail - это и есть то, что проверяет команду MAIL FROM: smtp пртокола, где и сидит адрес sender'а

выключение accept_unresolvable_domains добавит все это к check_mail в sendamil

Если у Вас этой строчки нет, проверьте sendmail.cf на предмет строки Kresolve

Конечно все зависит от версии sendmail'а. Поэтому и рекомендовал посотреть m4/proto.mc

У меня работает, только что проверил ...

Kresolve есть и свою работу выполняет :))) Почту от несуществующих доменов отправляет лесом. адрес сендера - имелось ввиду не обратный почтовый адрес, а IP адрес хоста, который подделать низзя, в отличие от обратного адреса. Задача не совсем обычная, она требует написания своих правил... И знания rewriting rules =) Это независимо от версии Сендмыла не реализуется простыми Feature & Define :))) RFC-1123: Client MUST do HELO with exist valid host. А тем кому покласть на это я говорю реджект. Это мое право :) Такая фигня у админов, которые делают системы через одно место. Из-за них нет возможности выключить спам на 100%. Самое забавное - через одно место настраивают системы именно админы контор, которые сами имеют отношение к ИТ... Поскольку стандарты на SMTP писались в лохматых годах, когда спама не было, приходится быть жестким. И это дает свои плоды. Я лучше не пропущу одно письмо от кривой системы и заодно 1000 спам писем. Строгое требование соблюдения стандартов RFC-1123 & RFC-2821 сведет проблему спама к нулю.

Это что еще за толкование стандарта взялось??? Откуда такая фраза (номер раздела RFC-1123).

>Client MUST do HELO with exist valid host

Вот выдержки из раздела 3.5 RFC-1123. The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

IMPLEMENTATION: When HELO parameter validation fails, a suggested procedure is to insert a note about the unknown authenticity of the sender into the message header (e.g., in the "Received:" line).

Вроде все четко написано.

>Обратной зоны для адреса xxx.xxx.xxx.xxx нет. А для кучи адресов обратной зоны нет. И это идет не от админа системы, а от админов вышестоящих провайдеров... Похоже все дружно забили на PTR записи.

А если уж сопоставлять поле From, то нужно резолвить MX записи, а не A записи DNS.

P.S. Лично мне spam приходит с абсолютно реальных почтовых ящиков :((

По пункту первому - это было вольное толкование. RFC читали, знаем. Там что написано? The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. ОН ДОЛЖЕН, ПРОСТО ОБЯЗАН. Он отступает от стандарта 70-х годов, когда спама не было вообще. Я тоже могу отступить от выполнения этого стандарта. Разве не так? Или у нас полное доверие к "Васям Пупкиным" из Интернет?

По пункту второму - чушь это. Любой нормальный пров делает реверсную зону и прямую. Чтобы и там и там записи не конфликтовали. Любой админ почтовой системы вправе требовать, чтобы его забили в реверсную зону прова и завели там такую запись, которую он пожелает. Пров не вправе отказать. Если у Вас 256 адресов реверс Вам вообще делегируют. Так что здесь обычная лень и профнепригодность админов.

По поводу реальных почтовых ящиков - банить в эксесс листах и абузить владельцам серверов на кот ящики процветают.

Все это IMHO.

Про реверс

Ну вот 3 адреса:
194.226.227.111
194.226.224.254
195.64.206.254 (195.64.194.110)

Все они пренадлежат одному серваку, более того все они из сетей класса C и все эти 3 сети выделены той же организации, которой пренадлежит сервак.

Первый нормально реверсится.
Второй кончается на 226.194.in-addr.arpa , но можно попинать ripn или кого там еще, а 195.64. уже кончается на 195.in-addr.arpa...

И вот так, Интернет есть, а реверса нет. И не от ближайшего прова это зависит.

Я не против рубки писем с некорректным HELO --- твой сервер, делай что хочешь, НО не нужно прикрыватся стандартом. Так и говори, что хочу отойти от RFC в определенных пунктах.

Такой изврат очень редко в природе, большая часть систем все-таки сделана по уму. Кстати, любой бесплатный сервис типа рамблера, мэйлру сделаны по уму :)) От них письма будут приходить 8) Я готов потерять 5% писем от таких через задницу деланных систем, у которых полный беспорядок в forward & reverse зонах :) И не надо говорить про системы фильтрации после полного приема письма... Мне 20-30 Гиг спама проще прибить на этапе соединения, чем потом с ним маяться ) Стандарты есть - выполняй, не хошь - иди лесом.

вопрос снят. не дождался, написал сам. стало легко и свободно :) правила чуть менее агрессивны, если нет реверса у сервера или есть, но в прямой зоне другой IP, либо вообще нет в прямой зоне (обратная проверка), то проверяем HELO. Не резолвится - в сад, резолвится в другой IP - в сад. Ложных срабатываний - мизер, фиксится админами на том конце за небольшое кол-во времени. Спама почти не осталось ))) всем спасибо :) всем удачи :)