Знаю, что плохо, но нужно!
Объясняю почему.Есть mail сервер с клиентами которого мы переписываемся. (mail.kamchatka.ru)
У него стоит фильтр на отфутболивание клиентов отправивших корреспонденцию с ADSL/XSDL/DSL и т.д.Наша система работает так:
Thunderbird (adsl.primorye.ru) => exim4 (mail.host.ru) = > user@mail.kamchatka.ru
Соответственно в заголовок попадает информация о первом хосте Recevied (adsl.primorye.ru)...
И все письма возвращаются обратно.Как лечить exim от таких мега-эффективных-защит от спама.
Спасибо!
>Как лечить exim от таких мега-эффективных-защит от спама.
>
>Спасибо!лечить надо не экзим а вот таких идиотов, как вы привели.
надо просто написать докладную записку вышестоящему начальнику о сложившейся ситуации, и после недохождения писем болеть жопа будет уже у "товарища" с той стороны кабеля.
+1
>>Как лечить exim от таких мега-эффективных-защит от спама.
>>
>>Спасибо!
>
>лечить надо не экзим а вот таких идиотов, как вы привели.
>надо просто написать докладную записку вышестоящему начальнику о сложившейся ситуации, и после
>недохождения писем болеть жопа будет уже у "товарища" с той стороны
>кабеля.Возложить на плечи другого человека(организации) это слишком простое решение.
ИМХО: докладную записку писать гораздо дольше...
>Возложить на плечи другого человека(организации) это слишком простое решение.
>ИМХО: докладную записку писать гораздо дольше...таких людей (с того конца кабеля) надо отстреливать за вредительство. чем раньше это сделают, тем проще будет жить другим.
>[оверквотинг удален]
>Наша система работает так:
>
>Thunderbird (adsl.primorye.ru) => exim4 (mail.host.ru) = > user@mail.kamchatka.ru
>
>Соответственно в заголовок попадает информация о первом хосте Recevied (adsl.primorye.ru)...
>И все письма возвращаются обратно.
>
>Как лечить exim от таких мега-эффективных-защит от спама.
>
>Спасибо!В транспотре
headers_remove = Received
>[оверквотинг удален]
>>
>>Соответственно в заголовок попадает информация о первом хосте Recevied (adsl.primorye.ru)...
>>И все письма возвращаются обратно.
>>
>>Как лечить exim от таких мега-эффективных-защит от спама.
>>
>>Спасибо!
>
>В транспотре
>headers_remove = ReceivedСпасибо! В exim как всегда все оказалось проще некуда.
Я так понял по документации для headers_remove & headers_add регульярные выражения и подстановки там не работают...
>[оверквотинг удален]
>>>Как лечить exim от таких мега-эффективных-защит от спама.
>>>
>>>Спасибо!
>>
>>В транспотре
>>headers_remove = Received
>
>Спасибо! В exim как всегда все оказалось проще некуда.
>Я так понял по документации для headers_remove & headers_add регульярные выражения и
>подстановки там не работают...а вообще по правилам положенно отбрасывать письма с не полноценных хостов
ppp/dsl/dialup и тех у которых нет обратной зоны - я считаю, что это очень даже правильно и справедливо.
Гораздо проще искать решение проблемы - создать отдельное исключение для Вас ...
>а вообще по правилам положенно отбрасывать письма с не полноценных хостов
>ppp/dsl/dialup и тех у которых нет обратной зоны - я считаю, что
>это очень даже правильно и справедливо.
>Гораздо проще искать решение проблемы - создать отдельное исключение для Вас ...
>по правилам и понятиям живут на зоне. для почты существует стандарт. и называется он RFC. вы не затруднитесь процитировать где эта фраза (то что вы сказали) в RFC?
>>а вообще по правилам положенно отбрасывать письма с не полноценных хостов
>>ppp/dsl/dialup и тех у которых нет обратной зоны - я считаю, что
>>это очень даже правильно и справедливо.
>>Гораздо проще искать решение проблемы - создать отдельное исключение для Вас ...
>>
>
>по правилам и понятиям живут на зоне. для почты существует стандарт. и
>называется он RFC. вы не затруднитесь процитировать где эта фраза (то
>что вы сказали) в RFC?Ни один нормальный хост без обратной зоны не будет слать почту напрямую. Ни одному пользователю ADSL не понадобится держать почтовый север -- для них есть релей провайдера. Потому что даже если на 100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в день от таких хостов -- просто глупо нагружать сервер.
>[оверквотинг удален]
>>по правилам и понятиям живут на зоне. для почты существует стандарт. и
>>называется он RFC. вы не затруднитесь процитировать где эта фраза (то
>>что вы сказали) в RFC?
>
>Ни один нормальный хост без обратной зоны не будет слать почту напрямую.
> Ни одному пользователю ADSL не понадобится держать почтовый север --
>для них есть релей провайдера. Потому что даже если на
>100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он
>попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в
>день от таких хостов -- просто глупо нагружать сервер.а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>[оверквотинг удален]
>>>что вы сказали) в RFC?
>>
>>Ни один нормальный хост без обратной зоны не будет слать почту напрямую.
>> Ни одному пользователю ADSL не понадобится держать почтовый север --
>>для них есть релей провайдера. Потому что даже если на
>>100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он
>>попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в
>>день от таких хостов -- просто глупо нагружать сервер.
>
>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?Может меня поправят более опытные коллеги и такой RFC действительно существует. Но лично я процитировал RFC под названием "здравый смысл". Объясню почему.
Ситуация: хостинговый сервер, около 200 аккаунтов и 1000 доменов -- по сути, не так уж и много. Дефолтный RFC-совместимый конфиг с мелкими правками. Сначала спам сыпался горами на кучу несуществующих адресов (просто спамеры слали спам на что-угодно@мой-домен). В результате в очереди почты за пару часов скапливается около 10000 сообщений, на которые сгенерирован bounce, который не может быть доставлен. За сутки -- больше 200 тысяч. Включил проверку на существование пользователя и выдачу ошибки если пользователя нет. Уже сломал RFC (нужно генерировать bounce). Зато очередь почты стала вменяемой: стабильно в любой момент времени около 10000 сообщений. Следующий шаг -- забанил всех DSL, PPPoE, dialup и т. д. (не регекспом, а по pbl.spamhaus.org). Очередь почты около 200 сообщений!
А теперь сделаем вывод: зачем нагружать сервер этим всем спамом, если проще его не принимать?
>>>для них есть релей провайдера. Потому что даже если на
>>>100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он
>>>попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в
>>>день от таких хостов -- просто глупо нагружать сервер.
>>
>>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>
>Может меня поправят более опытные коллеги и такой RFC действительно существует.
>Но лично я процитировал RFC под названием "здравый смысл". Объясню
>почему.RFC эти базовые по DNS и очень старые.
RFC 1033
There should be one A record for each address of a host.
PTR's should use official names and not aliases.
To add a new host to your zone files:
Edit the appropriate zone file for the domain the host is in.
Add an entry for each address of the host.
Optionally add CNAME, HINFO, WKS, and MX records.
Add the reverse IN-ADDR entry for each host address in the appropriate
zone files for each network the host in on.RFC1035:
3.5. IN-ADDR.ARPA domain
The Internet uses a special domain to support gateway location and
Internet address to host mapping.
The intent of this domain is to provide a guaranteed method to perform
host address to host name mapping,
and to facilitate queries to locate all gateways on a particular network
in the Internet.
...Более свежее.
RFC2821:
4.3.1
[..]
Note: all the greeting-type replies have the official name (the
fully-qualified primary domain name) of the server host as the first
word following the reply code. Sometimes the host will have no
meaningful name. See 4.1.3 for a discussion of alternatives in these
situations.
[...]RFC 2181
10.2. PTR records
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
Note that while the value of a PTR record must not be an alias, there
is no requirement that the process of resolving a PTR record not
encounter any aliases. The label that is being looked up for a PTR
value might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, which it should not be,
will give the location where the PTR record is found. That record
gives the result of the PTR type lookup. This final result, the
value of the PTR RR, is the label which must not be an alias.
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias.
Ну, всем рекомендую RFC 2505.
>[оверквотинг удален]
>>>>день от таких хостов -- просто глупо нагружать сервер.
>>>
>>>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>>
>>Может меня поправят более опытные коллеги и такой RFC действительно существует.
>>Но лично я процитировал RFC под названием "здравый смысл". Объясню
>>почему.
>
>RFC эти базовые по DNS и очень старые.
>отлично. разницу между should и must надо объяснять?
>[оверквотинг удален]
>>>>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>>>
>>>Может меня поправят более опытные коллеги и такой RFC действительно существует.
>>>Но лично я процитировал RFC под названием "здравый смысл". Объясню
>>>почему.
>>
>>RFC эти базовые по DNS и очень старые.
>>
>
>отлично. разницу между should и must надо объяснять?Это не надо.
Но как известно, Internet почта работает на основе DNS имен.
RFC 1033
There should be one A record for each address of a host.
PTR's should use official names and not aliases.Вы можете не иметь А и PTR записи для вашего хоста,
но должны иметь A запись для вашего MX хоста.RFC 1033
MX (Mail Exchanger) (See RFC-974 for more details.)
<name> [<ttl>] [<class>] MX <preference> <host>То есть, должны иметь "имя" для MX хоста. Запись A в зоне .
Если же сказали A , то говорите и PTR .
To add a new host to your zone files:
Edit the appropriate zone file for the domain the host is in.
Add an entry for each address of the host.
Optionally add CNAME, HINFO, WKS, and MX records.
Add the reverse IN-ADDR entry for each host address in the appropriate
zone files for each network the host in on.Не вводите в заблуждение. То ли ваш MX хост "вася" - A, то ли он "петя" - PTR,
то ли у него нет совсем имени в PTR, то ли на него ссылаются тысяча левых
доменных имен в записях A, для которых он якобы должен принять почту, в
соответствии с MX этих левых прямых зонах.Может я и не прав в своих рассуждениях.
>Не вводите в заблуждение. То ли ваш MX хост "вася" - A,
>то ли он "петя" - PTR,
>то ли у него нет совсем имени в PTR, то ли на
>него ссылаются тысяча левых
>доменных имен в записях A, для которых он якобы должен принять почту,
>в
>соответствии с MX этих левых прямых зонах.
>
>Может я и не прав в своих рассуждениях.1) везде should а не must, следовательно никто делать это не обязан.
2) в первоначальном сообщениие речь шла вообще о вхождении dsl в A или PTR. и степени адекватности человека реджектящего такие вещи.
>
>1) везде should а не must, следовательно никто делать это не обязан.Это так. Но если Вы ВСЕ ЖЕ сделали A запись , то должны сделать и PTR.
В том же RFC1033:
To add a new host to your zone files:
Edit the appropriate zone file for the domain the host is in.
Add an entry for each address of the host.
Optionally add CNAME, HINFO, WKS, and MX records.
Add the reverse IN-ADDR entry for each host address in the appropriate
zone files for each network the host in on.Либо Вы не делайте вовсе A записей .
>2) в первоначальном сообщениие речь шла вообще о вхождении dsl в A
>или PTR. и степени адекватности человека реджектящего такие вещи.Косвенно RFC1033 касается обсуждаемой темы.
>[оверквотинг удален]
>>
>>Ни один нормальный хост без обратной зоны не будет слать почту напрямую.
>> Ни одному пользователю ADSL не понадобится держать почтовый север --
>>для них есть релей провайдера. Потому что даже если на
>>100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он
>>попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в
>>день от таких хостов -- просто глупо нагружать сервер.
>
>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>Человека просто не затрудняет прописать пару строк в конфиге, чем плакаться в жилетку начальству от того, что не хватает ресурсов сервера на обработку спама. Если вы уж такой приверженец RFC - то флаг вам в руки. А служебки/докладные на меня (у меня аналогичные настройки) можете писать до посинения, пока не обзаведетесь нормальной обраткой и человеческим именем хоста и домена доступа к моему почтовику вам не видать.
Это поменьшей мере смешно каждый раз прикрываться RFС. Если вы не знали, то многие кто шлет спам их читали. Кроме RFC, открою вам тайну, существуют кормпоративные стандарты внутренней и внешней безопасности компании. И они куда важнее всех ваших RFC.
Я не совсем понял о чем спор который разгорелся выше?Если у нас в городе(Владивосток), самый большой провайдер(дальсвязь) раздает интернет преимущественно с динамическими ip и этому ip уже присвоена обратная зона в виде dsl0001.primorye.ru, и ты хоть жопой снег ешь у тебя в Received одним из хостов будет dsl0001.primorye.ru.
И о каких стандартах может идти речь? Тогда 80% приморской почты если придерживаться правил RFC будет идти лесом.
Может быть оно и написано где-то, и даже оно может быть правильно, но совершенно не жизнеспособно особенно в тех случаях когда за потерянную корреспонденцию начальство тр..ет так, что мало не покажется. У нас даже планируется в штат человека взять который будет в ручную в спаме(то что по правилам сервера попало в спам) полезные письма искать! (реально не 1 апреля)
ндаа
>[оверквотинг удален]
>
>И о каких стандартах может идти речь? Тогда 80% приморской почты если
>придерживаться правил RFC будет идти лесом.
>
>Может быть оно и написано где-то, и даже оно может быть правильно,
>но совершенно не жизнеспособно особенно в тех случаях когда за потерянную
>корреспонденцию начальство тр..ет так, что мало не покажется. У нас даже
>планируется в штат человека взять который будет в ручную в спаме(то
>что по правилам сервера попало в спам) полезные письма искать! (реально
>не 1 апреля)Для решения такой проблемы существуют :
а) статические IP
б) правильная пропись зон в DNS
в) содержание почтовика на площадке прова
г) договора об обслуживании с поддержкой статики
д) с любым провом(руководством/админами) можно договориться не только на бумагах, но и словах/личной заинтересованностиНу и в конце-концов - это ненормально - держать почтовик на динамике. И хотите кричите, хотите нет - но дело здесь не в RFC, а в не желании построить нормально рабочий процесс. А вот за это тр...ть руководство должно и обязано
>[оверквотинг удален]
>б) правильная пропись зон в DNS
>в) содержание почтовика на площадке прова
>г) договора об обслуживании с поддержкой статики
>д) с любым провом(руководством/админами) можно договориться не только на бумагах, но и
>словах/личной заинтересованности
>
>Ну и в конце-концов - это ненормально - держать почтовик на динамике.
>И хотите кричите, хотите нет - но дело здесь не в
>RFC, а в не желании построить нормально рабочий процесс. А вот
>за это тр...ть руководство должно и обязанополностью согласен, ибо особых сложностей я не вижу.
Так что не нужно из мухи делать слона, а Вы знаете, в чем основная проблема у нашего общества в целом, что многие видит очевидные проблемы понимают, осуждают и просто посядят покурят и все разайдутся вот так вот.
>[оверквотинг удален]
>>Ну и в конце-концов - это ненормально - держать почтовик на динамике.
>>И хотите кричите, хотите нет - но дело здесь не в
>>RFC, а в не желании построить нормально рабочий процесс. А вот
>>за это тр...ть руководство должно и обязано
>
>полностью согласен, ибо особых сложностей я не вижу.
>Так что не нужно из мухи делать слона, а Вы знаете, в
>чем основная проблема у нашего общества в целом, что многие видит
>очевидные проблемы понимают, осуждают и просто посядят покурят и все разайдутся
>вот так вот.Вам тоже читать с верху в них или просто прочитать последнее сообщение!
>[оверквотинг удален]
>б) правильная пропись зон в DNS
>в) содержание почтовика на площадке прова
>г) договора об обслуживании с поддержкой статики
>д) с любым провом(руководством/админами) можно договориться не только на бумагах, но и
>словах/личной заинтересованности
>
>Ну и в конце-концов - это ненормально - держать почтовик на динамике.
>И хотите кричите, хотите нет - но дело здесь не в
>RFC, а в не желании построить нормально рабочий процесс. А вот
>за это тр...ть руководство должно и обязаноДа ё маё
Вы, что посты совсем не читаете и не видите откуда берется "adsl"ЕЩЕ РАЗ!
1 ===> 2 ===> 3
КЛИЕНТ ВЫХОДЯЩИЙ ===> СЕРВЕР НА ПЛОЩАДКЕ ===> ПОЛУЧАТЕЛЬ С ФИЛЬТРОМ
В ИНТЕРНЕТ ===> В МОСКВЕ СО СТАТИЧЕСКИМ IP ===> ПОЧТЫ ПО DSL В ЗАГОЛОВКАХ
ЧЕРЕЗ DSL ПРОВАЙДЕРА ===> И ПРОПИСАННОЙ ОБРАТНОЙ ЗОНОЙ ===> ПИСЕМТак вот при переходе от 1 к 2 происходит пересылка письма от клиента ThunderBird к серверу SMTP. Соответсвенно вставляется Received: ip+зона хоста!
Так, что еще раз прошу читайте внимательно прежде чем давать такие "ценные" советы.
p.s. проблема решена(спасибо Golub Mikhail), но если кому интересно продолжим рассуждения на счет правильности действий в этой ситуации.
Нервничать не надо. Первый мой постинг был вообще не вам адресован, а dawnshade, второй вам только на половину, так как я терпеть не могу людей которые прикрываются всегда стандартоми и RFC, но в 90% случаев и шапки этих стандартов не прочитали. Ваш пост первый и все последующие(не только ваши) я прочитал внимательно и могу с десяток вариантов предложить без правки настроек почтовика, что бы у вас все работало. Но вы уже решили свой вопрос, потому я их и не оглашаю. Смысл? Пиписьками меряться? Не серьезно, мне не уже давно не 18-20 лет. Я выразил свое мнение по поводу "тр...ет" начальство и организации процесса.
итак по порядку>Но лично я процитировал RFC под названием "здравый смысл".
т.е. это исключительно ваши выдумки и самодеятельность. вопросов больше нет.
>Включил проверку на существование пользователя и выдачу ошибки если пользователя нет. >Уже сломал RFC (нужно генерировать bounce).
гон. нет такого в RFC. дабы не быть голословным
"If the
SMTP-receiver can accept mail for that recipient it responds with an
OK reply; if not, it responds with a reply rejecting that recipient
(but not the whole mail transaction). "
не надо выдавать неумение настроить MTA за RFC.>Следующий шаг -- забанил всех DSL, PPPoE, dialup и т. д. (не регекспом, а по >pbl.spamhaus.org).
>Человека просто не затрудняет прописать пару строк в конфиге, чем плакаться в жилетку >начальству от того, что не хватает ресурсов сервера на обработку спама. Если вы уж такой >приверженец RFC - то флаг вам в рукия на это не жаловался, не надо приписывать мне чужие высказывания.
> так как я терпеть не могу людей которые прикрываются всегда стандартоми и RFC, но в 90% >случаев и шапки этих стандартов не прочитали.
аналогично, не вам судить прочитал я их или нет. не надо априори выдавать желаемое за действительное.
>Не серьезно, мне не уже давно не 18-20 лет.
ни разу непохоже, ибо вы не только не читали первоначальное сообщение, так еще и заочно обвиняете собеседников непойми в чем.
для примера в разнице методов приведу простую аналогию.
вы идете по пешеходному переходу на зеленый свет (ака соблюдая RFC), вас сбивает машина, потомучто кто-то решил ездить как ему захочется без правил (ака RFC). вы предлагаете метод решения проблемы - а давайте я тоже буду переходить дорогу без правил, создавая тем самым аварийные ситуации для тех кто ездит по правилам.
>Нервничать не надо. Первый мой постинг был вообще не вам адресован, а
>dawnshade, второй вам только на половину, так как я терпеть не
>могу людей которые прикрываются всегда стандартоми и RFC, но в 90%
>случаев и шапки этих стандартов не прочитали. Ваш пост первый и
>все последующие(не только ваши) я прочитал внимательно и могу с десяток
>вариантов предложить без правки настроек почтовика, что бы у вас все
>работало. Но вы уже решили свой вопрос, потому я их и
>не оглашаю. Смысл? Пиписьками меряться? Не серьезно, мне не уже давно
>не 18-20 лет. Я выразил свое мнение по поводу "тр...ет" начальство
>и организации процесса.Я ничего не имею против вашего первого постинга, я в своем сообщении от 20-Окт-07, 06:28 только спросил о чем идет спор, причем заметьте спросил у всех а не лично у вас.
На счет второго вашего поста, ИЗВИНИТЕ я не телепат! В вашем втором посте была полная цитата моего сообщения, так что догадаться, что мне было адресовано 1/2 этого сообщения было очень сложно.
Если вы "терпеть не можете...", значит нервничаете именно вы!
Если прочитали все посты внимательно и рекомендуете:
>а) статические IP
>б) правильная пропись зон в DNS
>в) содержание почтовика на площадке прова
>г) договора об обслуживании с поддержкой статики
>д) с любым провом(руководством/админами) можно договориться не только на бумагах, но и >словах/личной заинтересованностиЗначит прочитали невнимательно!
>могу с десяток вариантов предложить без правки настроек почтовика, что бы у вас все
>работало. Но вы уже решили свой вопрос, потому я их и
>не оглашаю. Смысл?Смысл есть. С удовольствием послушаем и в дальнейшем возможно решим проблему как предложили именно вы. Это же форум, тут обсуждают проблему и все ее решения.
Лишних решений не бывает!>...могу с десяток вариантов... Пиписьками меряться?
Тут вы как раз пиписьками и мериетесь, только с застегнутой ширинкой
>[оверквотинг удален]
>б) правильная пропись зон в DNS
>в) содержание почтовика на площадке прова
>г) договора об обслуживании с поддержкой статики
>д) с любым провом(руководством/админами) можно договориться не только на бумагах, но и
>словах/личной заинтересованности
>
>Ну и в конце-концов - это ненормально - держать почтовик на динамике.
>И хотите кричите, хотите нет - но дело здесь не в
>RFC, а в не желании построить нормально рабочий процесс. А вот
>за это тр...ть руководство должно и обязаноСовершенно верно. Ярым приверженцев FRC в тупом виде рекомендую посмотреть, как борется со спамом один из лучших киевских почтовых сервисов:
http://www.ukr.net/mta/err.html
Всё стабильно доходит и спама у них практически нет.
>Может быть оно и написано где-то, и даже оно может быть правильно,
>но совершенно не жизнеспособно особенно в тех случаях когда за потерянную
>корреспонденцию начальство тр..ет так, что мало не покажется. У нас даже
>планируется в штат человека взять который будет в ручную в спаме(то
>что по правилам сервера попало в спам) полезные письма искать! (реально
>не 1 апреля)Человек - это не решение вопроса.
Адрес не сообщите? ;-)
Я вам бот сеть сосватаю, чтобы человек был всегда при работе.