Всем привет еще раз
Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того что сказал клиент в helo/ehlo и его IP адреса?
Это возможно реализовать?
В main.conf сейчас есть следующее:smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
warn_if_reject reject_unknown_client,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
warn_if_reject reject_unverified_sender,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:10028,
reject_rbl_client dul.ru,
reject_rbl_client list.dsbl.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client dynablock.wirehub.net,
reject_rbl_client dialups.mail-abuse.org,
reject_rbl_client combined.njabl.org,
permitСудя по всему этого не достаточно?
smtpd_client_restrictions = reject_unknown_recipient_domain
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_non_fqdn_senderr
smtpd_helo_restrictions = reject_unknown_hostname
smtpd_helo_restrictions = reject_invalid_hostname
# Dont recieive email for unknown user
local_recipient_maps = $alias_maps unix:passwd.byname
>smtpd_client_restrictions = reject_unknown_recipient_domain
>smtpd_helo_required = yes
>smtpd_helo_restrictions = reject_non_fqdn_senderr
>smtpd_helo_restrictions = reject_unknown_hostname
>smtpd_helo_restrictions = reject_invalid_hostname
># Dont recieive email for unknown user
>local_recipient_maps = $alias_maps unix:passwd.bynameВчера сделал следующее, посмотрите, может чего и не надо было:
maps_rbl_reject_code = 554
disable_vrfy_command = yes
strict_rfc821_envelopes = yessmtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_unknown_hostname,
reject_non_fqdn_hostname,
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_sender_login_mismatch
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
warn_if_reject reject_unknown_client,
warn_if_reject reject_unknown_recipient_domain,
warn_if_reject reject_unverified_sender,
warn_if_reject reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:10028,
reject_rbl_client dul.ru,
reject_rbl_client list.dsbl.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client dynablock.wirehub.net,
reject_rbl_client dialups.mail-abuse.org,
reject_rbl_client combined.njabl.org,
permit
>Всем привет еще раз
>Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того
>что сказал клиент в helo/ehlo и его IP адреса?
Задолбали меня эти проверки, блин...
Кто сказал, что это _должно_ совпадать?
У меня прямой и честный адрес my.domain.com , а при резолве по ip идет
my-ip.static.provider.net ... и куча идиотов отшибает
>Задолбали меня эти проверки, блин...
>Кто сказал, что это _должно_ совпадать?
>У меня прямой и честный адрес my.domain.com , а при резолве по
>ip идет
>my-ip.static.provider.net ... и куча идиотов отшибает
Т.е. у Вас просто не совпадают DNS-записи в прямой и обратной зонах?
>Т.е. у Вас просто не совпадают DNS-записи в прямой и обратной зонах?
Угу. И нигде в стандартах не сказано, что они должны совпадать
>Угу. И нигде в стандартах не сказано, что они должны совпадать
Я кстати тоже не знаю, где это определено. Может кто кинет ссылку на RFC?
>>Всем привет еще раз
>>Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того
>>что сказал клиент в helo/ehlo и его IP адреса?
>Задолбали меня эти проверки, блин...
>Кто сказал, что это _должно_ совпадать?
>У меня прямой и честный адрес my.domain.com , а при резолве по
>ip идет
>my-ip.static.provider.net ... и куча идиотов отшибаетА что вам мешает настроить обратную зону нормально? Что бы "куча идиотов" могла нормально работать по стандартам?
>А что вам мешает настроить обратную зону нормально? Что бы "куча идиотов"
>могла нормально работать по стандартам?
1 - этого нигде в стандартах нет
2 - прямую зону веду я, а обратную - провайдер, и у него есть все резоны именовать именно так
>>А что вам мешает настроить обратную зону нормально? Что бы "куча идиотов"
>>могла нормально работать по стандартам?
>1 - этого нигде в стандартах нет
>2 - прямую зону веду я, а обратную - провайдер, и у
>него есть все резоны именовать именно так
Поскольку он предоставил вам IP адрес, вы имеете полное право попросить его и прописать для него обратку. Во всяком случае даже для своей домашней машины мне удалось это сделать
>Поскольку он предоставил вам IP адрес, вы имеете полное право попросить его
>и прописать для него обратку. Во всяком случае даже для своей
>домашней машины мне удалось это сделать
К сожалению, не все провайдеры соглашаются это делать.
>>Поскольку он предоставил вам IP адрес, вы имеете полное право попросить его
>>и прописать для него обратку. Во всяком случае даже для своей
>>домашней машины мне удалось это сделать
>К сожалению, не все провайдеры соглашаются это делать.Если есть договор с провайдером, то надо посмотреть его - возможно в нем есть пункты которые можно притянуть к этому делу
>>>А что вам мешает настроить обратную зону нормально? Что бы "куча идиотов"
>>>могла нормально работать по стандартам?
>>1 - этого нигде в стандартах нет
>>2 - прямую зону веду я, а обратную - провайдер, и у
>>него есть все резоны именовать именно так
>
>
>Поскольку он предоставил вам IP адрес, вы имеете полное право попросить его
>и прописать для него обратку. Во всяком случае даже для своей
>домашней машины мне удалось это сделать
По пунктам....
1 - "Попросить" я его имею право. А он имеет право не выполнить просьбу
2 - Я с этим провайдером хорошо знаком и, в принципе, могу договориться. А вот если на мой ip зарегистрировано несколько доменов? Менять обратку в такт работе почтовика? Поэтому в rfc и нет требований соответствия обратной.
3 - Провайдер имеет свои веские основания для именования обратки по своему. Я же приводил пример не зря- my-ip.static.provider.net, т.е. обратка содержит мой ip, пул, имя провайдера, что не дает запутаться в сетях поовайдеру, работающему в десятке крупных городов и почти сотне мелких.
>>>>А что вам мешает настроить обратную зону нормально? Что бы "куча идиотов"
>>>>могла нормально работать по стандартам?
>>>1 - этого нигде в стандартах нет
>>>2 - прямую зону веду я, а обратную - провайдер, и у
>>>него есть все резоны именовать именно так
>>
>>
>>Поскольку он предоставил вам IP адрес, вы имеете полное право попросить его
>>и прописать для него обратку. Во всяком случае даже для своей
>>домашней машины мне удалось это сделать
>По пунктам....
>1 - "Попросить" я его имею право. А он имеет право не
>выполнить просьбу>2 - Я с этим провайдером хорошо знаком и, в принципе, могу
>договориться. А вот если на мой ip зарегистрировано несколько доменов? Менять
>обратку в такт работе почтовика? Поэтому в rfc и нет требований
>соответствия обратной.Зачем? Почтовый сервер в helo говорит всегда только одно имя, вы же не меняете под каждое письмо helo сервера?
>3 - Провайдер имеет свои веские основания для именования обратки по своему.
>Я же приводил пример не зря- my-ip.static.provider.net, т.е. обратка содержит мой
>ip, пул, имя провайдера, что не дает запутаться в сетях поовайдеру,
>работающему в десятке крупных городов и почти сотне мелких.
>>2 - Я с этим провайдером хорошо знаком и, в принципе, могу
>>договориться. А вот если на мой ip зарегистрировано несколько доменов? Менять
>>обратку в такт работе почтовика? Поэтому в rfc и нет требований
>>соответствия обратной.
>
>Зачем? Почтовый сервер в helo говорит всегда только одно имя, вы же
>не меняете под каждое письмо helo сервера?
Но может быть несколько почтовиков...
Еще раз - В RFC НЕ УКАЗАНО ТРЕБОВАНИЯ ОБЯЗАТЕЛЬНОГО СООТВЕТСТВИЯ!!!
И, кстати, to DEN, который считает, что это проблема принимающей стороны... ra правильно указал, что некоторым хоть кол на голове теши - автору вопроса уже сколько раз сказано, а он все равно по своему... увы...
>>>2 - Я с этим провайдером хорошо знаком и, в принципе, могу
>>>договориться. А вот если на мой ip зарегистрировано несколько доменов? Менять
>>>обратку в такт работе почтовика? Поэтому в rfc и нет требований
>>>соответствия обратной.
>>
>>Зачем? Почтовый сервер в helo говорит всегда только одно имя, вы же
>>не меняете под каждое письмо helo сервера?
>Но может быть несколько почтовиков...
>Еще раз - В RFC НЕ УКАЗАНО ТРЕБОВАНИЯ ОБЯЗАТЕЛЬНОГО СООТВЕТСТВИЯ!!!
>И, кстати, to DEN, который считает, что это проблема принимающей стороны... ra
>правильно указал, что некоторым хоть кол на голове теши - автору
>вопроса уже сколько раз сказано, а он все равно по своему...
>увы...Если "автор" это я, то мое "увы" в 25000 писем спама в день
>Если "автор" это я, то мое "увы" в 25000 писем спама в
>день
Для начала в режекты main.conf добавить что-то типа sleep 30, как в свое время посоветовал unk (жаль, но он что-то здесь давно не виден) - зело помогает и систему не грузит. SpamAssassin на прорвавшееся.
А вот проверок, не соответствующих RFC, делать не стоит...
>>Всем привет еще раз
>>Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того
>>что сказал клиент в helo/ehlo и его IP адреса?
>Задолбали меня эти проверки, блин...
>Кто сказал, что это _должно_ совпадать?
>У меня прямой и честный адрес my.domain.com , а при резолве по
>ip идет
>my-ip.static.provider.net ... и куча идиотов отшибаетМлин, согласен. Меня это тоже просто уже зае..ло! Ладно бы с мелкими конторами были проблемы, так нет, крупняки пошли дурью маяться. И говорить с ними бесполезно.
Народ, админы! Учитывайте что далеко не все могут нормально прописать обратный адрес (провайдеры они такие).
>>>Всем привет еще раз
>>>Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того
>>>что сказал клиент в helo/ehlo и его IP адреса?
>>Задолбали меня эти проверки, блин...
>>Кто сказал, что это _должно_ совпадать?
>>У меня прямой и честный адрес my.domain.com , а при резолве по
>>ip идет
>>my-ip.static.provider.net ... и куча идиотов отшибает
>
>Млин, согласен. Меня это тоже просто уже зае..ло! Ладно бы с мелкими
>конторами были проблемы, так нет, крупняки пошли дурью маяться. И говорить
>с ними бесполезно.
>Народ, админы! Учитывайте что далеко не все могут нормально прописать обратный адрес
>(провайдеры они такие).Тут не надо много обьяснять: если в RFC не сказано что прямая и реверс зоны должны совпадать то значит почтовик почту принять должен и это проблема тех админов которые ее реджектят. И все, точка.
RFC 1912 Секция 1.2
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).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also,
PTR records must point back to a valid A record, not a alias defined
by a CNAME. It is highly recommended that you use some software
which automates this checking, or generate your DNS data from a
database which automatically creates consistent data.
Каждый хост в инет сети должен иметь записи в прямой и обратной зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите официальное письмо на имя директора провайдера и требуйте обратную зону, мотивируюя этим RFC и
тем что имеет проблемы из-за ее отстуствия
>RFC 1912 Секция 1.2
О, спасибо, а то я забыл где я это видел
>Каждый хост в инет сети должен иметь записи в прямой и обратной
>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>официальное письмо на имя директора провайдера и требуйте обратную зону, мотивируюя
>этим RFC и
>тем что имеет проблемы из-за ее отстуствия
Между существовать и быть равными отличия понятны?
запись должна существовать, но не обязана совпадать с именем
>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>>официальное письмо на имя директора провайдера и требуйте обратную зону, мотивируюя
>>этим RFC и
>>тем что имеет проблемы из-за ее отстуствия
>Между существовать и быть равными отличия понятны?
>запись должна существовать, но не обязана совпадать с именемЕсли я конечно не совсем забыл английский, то For every IP address, there
should be a matching PTR record in the in-addr.arpa domain
^^^^^^^^
matching переводится как совпадающий
>>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>should be a matching PTR record in the in-addr.arpa domain
>
>^^^^^^^^
>matching переводится как совпадающий
Как совпадающий никогда не переводится (специально с филологом поконсультировался). Соответствующий или валидный (в техническом контексте). Самый точный перевод - "подходящий", по мнению переводчика, по словарю- "соответствующий". Но никогда не совпадающий!
>>>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>>should be a matching PTR record in the in-addr.arpa domain
>>
>>^^^^^^^^
>>matching переводится как совпадающий
>Как совпадающий никогда не переводится (специально с филологом поконсультировался). Соответствующий или валидный
>(в техническом контексте). Самый точный перевод - "подходящий", по мнению переводчика,
>по словарю- "соответствующий". Но никогда не совпадающий!интересно, значит нижеследующее значит "я типа что то нашел, но конечно же не совпадающее... так, просто"
grep postmaster *
Binary file __db.002 matches
Binary file log.0000000001 matches
Binary file postgrey.db matches
>интересно, значит нижеследующее значит "я типа что то нашел, но конечно же
>не совпадающее... так, просто"
>
>grep postmaster *
>Binary file __db.002 matches
>Binary file log.0000000001 matches
>Binary file postgrey.db matchesА если ты скажешь "найдено что-то подходящее", или "что-то соответствующее запросу", то, думаю, юмор исчезнет.
Недаром в грамотных переводах документации говорят о "соответствии", а не о совпадении, которое трактуется как "точное соответствие", которое по английски чаще всего identical.
>>>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>>should be a matching PTR record in the in-addr.arpa domain
>>
>>^^^^^^^^
>>matching переводится как совпадающий
>Как совпадающий никогда не переводится (специально с филологом поконсультировался). Соответствующий или валидный
>(в техническом контексте). Самый точный перевод - "подходящий", по мнению переводчика,
>по словарю- "соответствующий". Но никогда не совпадающий!Простите, коллега, вы в своем уме?
Match (существительное)
б) пара, ровня ( человек, подходящий кому-л., составляющий с ним пару ) She's a perfect match for him. — Она ему идеально подходит.
They are no good match. — Они совсем не подходят друг другу.
в) вещь или предмет, подходящие к другой или составляющие с ней пару ( по виду, форме, цвету и т. п. )
a perfect match of shape and sound — гармонично подобраны форма и звук This carpet and this sofa are/make a perfect match. — Эти ковер и софа удачно сочетаются.
two pictures which are a match — парные картины
I am looking for a match for my new shoes. — Я ищу что-нибудь подходящее к своим новым туфлям.
The horses are a good match. — Эти лошади хорошо подобраны.Возможно, ваш филолог не учел контекста. А возможно, вы ему об этом контексте не сказали.
>Простите, коллега, вы в своем уме?
>Match (существительное)
[skip]
>в) вещь или предмет, подходящие к другой или составляющие с ней пару
>( по виду, форме, цвету и т. п. )
>a perfect match of shape and sound — гармонично подобраны форма и
>звук This carpet and this sofa are/make a perfect match. —
>Эти ковер и софа удачно сочетаются
Вот и я о том же... подходящий, сочетающийся не есть одинаковый, равно как ковер != софе
[skip]
>
>Возможно, ваш филолог не учел контекста. А возможно, вы ему об этом
>контексте не сказали.
Наша контора имеет возможность держать хорошего филолога, и во избежание недоразумений я показал ему текст.
Дополнительно - на эту тему был как-то разговор в кафушке с несколькими провайдерами... Ну не трактуют ни у нас, ни на западе этот кусок RFC как обязательную идентичность прямого и обратного резолва
Скажите, как Вы тогда понимаете (переводите) следующее предложение из того же RFC?
Also, PTR records must point back to a valid A record, not a alias defined by a CNAME.
>>>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>>should be a matching PTR record in the in-addr.arpa domain
>>
>>^^^^^^^^
>>matching переводится как совпадающий
>Как совпадающий никогда не переводится (специально с филологом поконсультировался). Соответствующий или валидный
>(в техническом контексте). Самый точный перевод - "подходящий", по мнению переводчика,
>по словарю- "соответствующий". Но никогда не совпадающий!Всё правильно - имеется ввиду именно "подходящий", "соответствующий"
На своих серверах проверяю обратную зону на предмет отсутствия dsl, dial(-up), dhcp и т.д.
Обязательного совпадение требовать совсем не нужно
>Обязательного совпадение требовать совсем не нужно
Вам аналогичный вопрос. Переведите
Also, PTR records must point back to a valid A record, not a alias defined by a CNAME.
>>>Каждый хост в инет сети должен иметь записи в прямой и обратной
>>>зоне ! Любой провайдер обязан соблюдать требования RFC ! Пишите
>>>официальное письмо на имя директора провайдера и требуйте обратную зону, мотивируюя
>>>этим RFC и
>>>тем что имеет проблемы из-за ее отстуствия
>>Между существовать и быть равными отличия понятны?
>>запись должна существовать, но не обязана совпадать с именем
>
>Если я конечно не совсем забыл английский, то For every IP address,
>there
>should be a matching PTR record in the in-addr.arpa domain
>
>^^^^^^^^
>matching переводится как совпадающийвот только там should be а не must be, те о должествовании речи не идет
>вот только там should be а не must be, те о должествовании
>речи не идет
А здесь?
Also, PTR records must point back to a valid A record, not a alias defined by a CNAME.
>>>Всем привет еще раз
>>>Пытаюсь бороться со спамом, и как один из вариантов рассматриваю проверку того
>>>что сказал клиент в helo/ehlo и его IP адреса?
>>Задолбали меня эти проверки, блин...
>>Кто сказал, что это _должно_ совпадать?
>>У меня прямой и честный адрес my.domain.com , а при резолве по
>>ip идет
>>my-ip.static.provider.net ... и куча идиотов отшибает
>
>Млин, согласен. Меня это тоже просто уже зае..ло! Ладно бы с мелкими
>конторами были проблемы, так нет, крупняки пошли дурью маяться. И говорить
>с ними бесполезно.
>Народ, админы! Учитывайте что далеко не все могут нормально прописать обратный адрес
>(провайдеры они такие).Многие могут, но не хотят возиться... И кстати, а как быть с неправильными helo - тоже не отбрасывать? А то например даже rol не удосуживается настроить все свои сервера нормально... :)
А никто не заставляет держать почтовик на шлюзе. Поставь отдельный почтовик с реальным IP-адресом. И DNS тоже вынести было бы не лишне...Если связался с собственным доменом, то тогда уж будь добр сделай нормальный почтовик, на отдельном IP. Лень брать дополнительную сетку у прова, твои проблемы.
Мы все ленивы и скаредны. Мне лично тоже нехочется получать по десятку мег в день спама и соответственно оплачивать его.
>А никто не заставляет держать почтовик на шлюзе. Поставь отдельный почтовик с
>реальным IP-адресом. И DNS тоже вынести было бы не лишне...
>
>Если связался с собственным доменом, то тогда уж будь добр сделай нормальный
>почтовик, на отдельном IP. Лень брать дополнительную сетку у прова, твои
>проблемы.
>
>Мы все ленивы и скаредны. Мне лично тоже нехочется получать по десятку
>мег в день спама и соответственно оплачивать его.
У меня несколько филиалов в разных местах (за границей тоже). Они бэкапы друг для друга, контора одна. В каждом месте заказывать сетку? А разговаривать с провайдером на Кипре - вообще удовольствие редкое, там такое творят, что у наших домашних сетей не случается...
>У меня несколько филиалов в разных местах (за границей тоже). Они бэкапы
>друг для друга, контора одна. В каждом месте заказывать сетку? А
>разговаривать с провайдером на Кипре - вообще удовольствие редкое, там такое
>творят, что у наших домашних сетей не случается...Ну и забей на кипрских идиотов. Есть реальный IP это уже половина решения, если в других местах можно сделать нормально.
Если везде каналы нормальные, то достаточно двух HUB'ов backup'ирующих друг друга. Для них и брать реальные адреса. Остальные пусть только на них почту шлют и забирают.
Если еще на оба этих хаба поставить антивирусы, то внутренние сети будут защищены на 60% точно.Сетку вообще можно одну взять на все филиалы и по VPN ее раскидать по филиалам где требуются реальные адреса. У такого решения есть существенные плюсы, как впрочем и минусы.
Я не знаю вашей конкретной ситуации, какие приложения и сервисы используются, поэтому не смогу оценить.
Да, блин, мужики. Прочитайте внимательно: Речь идет о соответствии helо/ehlo реальному IP peer'а.
Если у вас все так туго, ну дайте почтовику то имя хоста, которое прописано у провайдера и вопрос снимется автоматически.
Единственно, что нужно будет еще почтовику объяснить, что ваш домен является локалхостом для этого почтовика и все.И будет вам любовь и ласка.
RFC1123Requirements for Internet Hosts -- Application and Support
Status of This Memo
This RFC is an official specification for the Internet community. It
incorporates by reference, amends, corrects, and supplements the
primary protocol standards documents relating to hosts.5.2.5 HELO Command: RFC-821 Section 3.5
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.Примерный перевод последнего абзаца:
Получатель МОЖЕТ проверять соответствие параметра HELO
IP-адресу отправителя. Но получатель НЕ ДОЛЖЕН отказываться
принимать письмо, даже если параметр HELO не соответствует
IP-адресу отправителя.
Пошумели и затихли :) Буря в стакане, блин :))
По итогам нескольких месяцев экспериментов, хочу попробовать обобщить результаты, поправьте и добавьте, если есть что...1. IP адрес отправителя должен резолвится в какое-либо имя
2. HELO сервера должно резолвится в некий IP
3. Домен отправителя должен существовать
4. Отправитель должен быть указан в "полной" форме и соответствовать rfc 821
5. Получатель должен быть указан в "полной" форме
>1. IP адрес отправителя должен резолвится в какое-либо имя
>2. HELO сервера должно резолвится в некий IP
>3. Домен отправителя должен существовать
>4. Отправитель должен быть указан в "полной" форме и соответствовать rfc 821
>
>5. Получатель должен быть указан в "полной" формеА можете вот эти пункты в виде параметров smtpd_***_restriction написать?
Огромная просьба!