Что нового придумали для борьбы со спамом в 2014 году?

Спама больше не на почте, а в реале. Ждём встроенный в мозг адблок.

Где вы его находите? 2 года почте спама 0.

На почтовом сервере организации

rspamd, но придумали думаю раньше

Что то по нему инструкций мало...

Как минимум одна точно есть, которую я писал сам

Нашел 2 статьи. Руководство поставило задачу бороться со спамом. А с этим spamassassin в связке с postfix+ ms exchange .... какое то...

Вот может пригодится https://syslinux.ru/node/1434

Жесткая проверка PTR, hello, чтобы ptr=mx=helo и разворачивать все, что не настроено нормально. Спам будет приходить только от спамеров с реальных почтовых серверов с предложением их услуг. А эти 10 писем в неделю можно и заблеклистить, ну и абьюзами их по наглой рыжей морде.
Но предупреждаю, удивишься сколькоудаков в инете не умеют настраивать почтовые сервера, например mos.ru и рамблер. Сейчас они и сюда набегут и будут докузывать что у них DKIM и им пох на остальное, даже когда в helo у них .local, вместо того чтобы поправить одну строку в конфиге.

ptr=mx=helo

Гениально!!!

А можете подсказать, в каком RFC указано такое требование?

Во-первых, исходящая почта домена может уходить с хоста(-ов) отличных от MX (вот тут удобно разруливать SPF'ом). См. RFC5321 п. 2.3.10:

This specification makes a distinction among four types of SMTP systems, based on the role those systems play in transmitting electronic mail.

Во-вторых, RFC так и не нашёл, но где-то встречалось, что да, отправляющий хост ОБЯЗАН иметь PTR и… это всё. Т.е. PTR ОБЯЗАН быть, но НЕ обязан ни с чем совпадать.

И вот ещё что нашлось в пункте 5.2.5 RFC1123:

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 у них .local» — это можно смело отвергать, т.к. все RFC про SMTP: устаревшие 821, 2821 и новый 5321, а так же отменённый в части MAIL RFC1123, требуют что HELO/EHLO должен содержать FQDN хоста, причём (RFC5321 пункт 2.3.5):

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.

RFC так и не нашёл, но где-то встречалось, что да, отправляющий хост ОБЯЗАН иметь PTR

Всё, что нашёл, это RFC1912 «Common DNS Operational and Configuration Errors», который напрямую не относится к SMTP:

For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

«should»! Не «must»!

Есть домен. У него есть mx . Сервер MX имеет ip с которого отправляет и принимает почту и это должно быть корректно отражено.
Внимание вопросы, что должно быть прописано в:
1. MX DNS домена
2. PTR IP MX
3. helo mx
Обясните наличие:
1. dynamic-adsl.skylink.ru в PTR, если мы купили у провайдера ip и можем вписать в PTR все что хотим
2. EHLO iamsdupid.loc в логах

Видимо мы уперлись в национальную особенность - есть сплошная линия, ее нельзя пересекать, и двойная сплошная ее нельзя пересекать категорически.
Тебе обязательно дорогу танком перекрывать, чтобы не ездил ? :)
RFC вежливые люди писали. Если не хочешь делать нормально - твое дело, не все твои письма уйдут, делов-то. Принимать их тоже никто не must.

Во-первых, исходящая почта домена может уходить с хоста(-ов) отличных от MX (вот тут удобно разруливать SPF'ом). См. RFC5321 п. 2.3.10:

И кто мешает во все эти PTR прописать MX ?

какой красный сайт! мне нравки :3

Во-первых, исходящая почта домена может уходить с хоста(-ов) отличных от MX (вот тут удобно разруливать SPF'ом). См. RFC5321 п. 2.3.10:

отредактировать предыдущее не успел.
Что значит «отличных от MX» ? Письма отправляешь ? - значит MTA, а раз назвался MTA, полезай в MX. Понимаю, тут самодельных отправляльщиков из скриптов методом прямой работы с 25 удаленным портом ждет открытие и поток нелестных слов и 451 в свой адрес. И поделом. Ибо нефиг, или отправляй через нормальный MTA или будь добр - соответствуй.

greylist уже не кошерный? Он отсечет не весь мутный и тошнотный спам, но львиную долю.

чтобы ptr=mx=helo и разворачивать все, что не настроено нормально

Т.е., если, гипотетически, мои 1000 серверов отправляют письма через 10 выделенных SMTP релеев и принимают почту через 5 отдельных MX, то ни одного письма с моих 10 000 доменов ты не получишь, так?

И даже чисто практически, с хостингами и гуглами проблем нет. В пролете ботнеты и криворучки, более того, значительная доля вирусов изображает из себя MTA старательнее, чем многие таковые, отчего грейслистинг и тарпит в пролете. Вирусам и в ehlo ptr бота подставить не жалко, а у криворучек там мусор.

Он никогда им не был. Он больше проблем может создать - во первых ботоводам пох, интернет и машинное время не их и боты не только делают ретрай, но еще и вчитываются в предлагаемое время и оптимизируют отправку, это несложно, во вторых грейслист обламывает встречный тест, в третьих забивает очередь отправителя, в четвертых плодит лишний трафик, в последних он неэффективен потомучто вопервых. Лет 7 назад от него небольшой эффект был.

opendkim, postgrey, spamassassin. sieve перекладывает сомнительный спам в отдельный mailbox.

Делал по инструкции https://syslinux.ru/node/1434 , а он цуко, почту жрет.

Ну блинн, где бы найти вменяемый пример обвязки антиспам+postfix+ms exchange

На почтовом сервере организации

вы еще живете в 90х видимо, вот и проблемы, у нас спама 0, гуглопочта корпоративная.

Большой Брат подмигивает тебе

Реджектит почту? Настраивай действия и веса

Большой брат в любом случае читает письма пока они к вам идут, зачем им усложнять работу? =)

Они хотя бы не хранятся у ББ

имап с хранилищем в тойже сети (скорость работы как у im) что и пользователь + отсутствие спама и возможность разрулить ситуации когда отправитель жестко влетел в SBL но очень надо + гарантированная доставка + возможность сделать все что нужно под себя + логи на случай конфликтов + какой угодно бэкап + контроль переписки + возможность принудительно срезать хранилище на определенный момент по решению руководства и вынести этот архив в отдельное место на всякий случай + понятная ситуация с конфиденциальностью + прогнозируемые даунтаймы (вот только не надо что у гугла их небыло, они и данные теряли) + вебморда.
Ага, гуглопочта, какже, у нее из списка только вебморда и антиспам, довольно неплохой антиспам, но если в спаме писем нет, то у вас оборот почты небольшой и, пардон, ваши ящики непопулярны.
Один раз в одном месте вынесли почтовый сервер за пределы сети, пользователи взвыли так, что за неделю решили все проблемы с провайдерами, нашли любое количество денег и вернули все обратно. Каждый раз когда почта действительно серьезно была важна для работы чтобы письма ГАРАНТИРОВАННО и ДОКАЗУЕМО доходили, внешние сервисы в пролете, но для стартаперов и ИП, да, подойдет, хотя первые и последние с удивлением для себя могут узнать что некоторых писем они не видели - гугл может резать по своим внутренним соображениям и это не лечится, и перлюстрация, хотя кому-то да, пох.

Да. Оно самое?

/etc/rspamd/metrics.conf

metric {
    name = "default";
        actions {
                reject = 10;
                add_header = 3;
                greylist = 6;

Оно. Посмотри логи и выясни почему письмо реджектит. Бывает и так, что отправитель нормальный, а MTA настраивал урод и письмо получает 10+ баллов и реджектится. Или у тебя вообще любую почту отбивает даже с яндексов и гуглей?

Я вам привёл выдержки из СТАНДАРТОВ! А Вы мне втираете понятия.

Внимание вопросы, что должно быть прописано в:

См. RFC5321.

И кто мешает во все эти PTR прописать MX ?

Вот для этого и нужно читать RFC. А там написано SHOULD. И при этом я специально процитировал требование, отдельно упомянутое в СТАНДАРТЕ, что не следует отвергать письма, не прошедшие проверку соответствия имени и IP.

Письма отправляешь ? - значит MTA, а раз назвался MTA, полезай в MX

Простите, модераторы, но этому господину нужны ВЕСОМЫЕ аргументы (которые, впрочем, он всё равно не воспринимает):

2.3.10.  Originator, Delivery, Relay, and Gateway Systems

   This specification makes a distinction among four types of SMTP
   systems, based on the role those systems play in transmitting
   electronic mail.  An "originating" system (sometimes called an SMTP
   originator) introduces mail into the Internet or, more generally,
   into a transport service environment.  A "delivery" SMTP system is
   one that receives mail from a transport service environment and
   passes it to a mail user agent or deposits it in a message store that
   a mail user agent is expected to subsequently access.  A "relay" SMTP
   system (usually referred to just as a "relay") receives mail from an
   SMTP client and transmits it, without modification to the message
   data other than adding trace information, to another SMTP server for
   further relaying or for delivery.

   A "gateway" SMTP system (usually referred to just as a "gateway")
   receives mail from a client system in one transport environment and
   transmits it to a server system in another transport environment.
   Differences in protocols or message semantics between the transport
   environments on either side of a gateway may require that the gateway
   system perform transformations to the message that are not permitted
   to SMTP relay systems.  For the purposes of this specification,
   firewalls that rewrite addresses should be considered as gateways,
   even if SMTP is used on both sides of them (see RFC 2979 [27]).

«originating», «delivery», «relay» и «gateway» — 4 (четыре) сущности! И нигде не сказано, что они ДОЛЖНЫ совмещаться на одном хосте.

Релей является MTA ?

Релей является MTA ?

Вы тоже будете меня по понятиям разводить?

Цитируйте стандарты!

Я то согласен, что в этом есть необходимость в 0.1% фирм. Я просто предлагаю массовое решение которое подойдет 99.9%.

На релее стоит тотже постфикс, у него свой ip, fqdn и ничто не мешает. А вообще переписка напоминает разговор врачей в курилке когда один другому говорит - в книжке написано врачу следует проверить количесиво тампонов после операции там не написано что я должен был это сделать...

в книжке написано врачу следует проверить количесиво тампонов после операции там не написано что я должен был это сделать...

Я в поддержку своих аргументов привожу цитаты, а Вы?

Rfc как основание забить на настройку, лол. Даешь раскол на конфессии с разной трактовкой, приходите к нам, у нас можно вообще без mx шлите на домен ибо rfc !

без mx шлите на домен ибо rfc !

Хоть одна здравая мысль (если домен имеет A-запись)!

Я и говорю у любая трактовка только в сторону лишь бы работу не делать. Молодец, чо.

Есть большая разница между «работу не делать» и «делать правильно».

Я знаю, что Вы хотите мне сказать, только вот с аргументацией у Ваc не очень… Есть множество способов отсечь спам не нарушая стандартов.

Когда-то я тоже был молодым и горячим и придумывал классные правила для фильтрации почты. Потом пару раз получил пилюлю за то, что до директора не дошло важное письмо. Мои аргументы типа «Я же лучше сделал, чем в стандарте!» или тот же самый «Пусть PTR пропишут!» никак не помогли избежать вливания. Ну и кроме того, сам неоднократно сталкивался с проблемными провайдерами в плане PTR — то долго не могут его прописать, то вовсе по ошибке удалят. Но ведь у меня-то сервер настроен корректно, а почта не ходит из-за косячного провайдера.

Теперь я не проверяю не то, что обратное преобразование IP в имя, но и прямое — чтобы HELO/EHLO резолвилось в тот IP, с которого пришло соединение. Дело в том, что однажды мне попался какой-то сервер, где админ явно ошибся в настройках. И всё у него было: и PTR и MX, но вот в имени хоста, кажется, дважды было «mail.mail.…».

Что же касается проверок HELO/EHLO, то я установил аксиому, что у меня два типа удалённых клиентов: МОИ ПОЛЬЗОВАТЕЛИ и ЧУЖИЕ СЕРВЕРЫ. У меня нет ЧУЖИХ ПОЛЬЗОВАТЕЛЕЙ. Дальше, RFC требует, чтобы в HELO/EHLO originator предоставил СВОЙ FQDN и допускает, чтобы там был его IP. Вот из этих условий у меня сложились проверки:

• не должно быть МОИХ IP-адресов, имён МОИХ хостов и МОИХ доменов;
• не должно быть localhost'а;
• не должно быть IP-адреса, не совпадающего с реальным IP хоста;

Иначе соединение закрывается. И заметьте, ничего сверх RFC!

Это то, что касается и моих пользователей, и чужих серверов, т.к. хоть как-нибудь настроенный MTA и любой современный почтовый клиент нормально сформируют HELO/EHLO.

Дальше несколько более заморочено. Мои пользователи обязаны авторизоваться. Нормально настроенный MTA должен отдавать свой FQDN. Из этого я трактую RFC по-своему (да-да! Я тоже не безгрешен): у авторизованного пользователя в HELO/EHLO может быть что угодно, но сервер должен предоставить имя, похожее на FQDN. Для этого я помечаю соединение если HELO/EHLO не выполняет условия из следующего списка, и если originator не авторизуется, я отвергну письмо.

• должна быть точка;
• не должно быть IP-адресом или IP-literal (корректно настроенному серверу это не к лицу. Да, не по RFC.);
• не должно содержать 4 группы цифр, разделённых символами «x», «.» или «-» (Да, я требую, чтобы в имени сервера никаким образом не упоминался IP);
• не должно содержать 12 цифр подряд (разновидность предыдущего правила);
• не должно содержать 8 16-ричных знаков подряд (см. два предыдущих правила);
• не должно содержать подстроки вида «broadband|cable|a?dsl|cpe|atm|cdma|customer|ppp|pppoe|vpn|dynamic|static|pool|dhcp|users?|nat|subnet|your|microsof» (Т.е. сервер не должен использовать имя, сгенерированное автоматически);
• домен первого уровня должен быть одним из http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Т.е. я всего лишь требую, чтобы админ в конфигурацию сервера вписал любое имя, похожее на FQDN. Правда ведь, что я совсем не много требую сверх RFC? На этом этапе здорово отсеиваются по первому списку:

H=(77.75.2.218) [118.161.77.229]
H=(localhost) [213.165.176.26]
H=([192.168.2.33]) [23.31.156.245]

По второму:

H=(maniaco) [5.9.110.242]
H=([113.163.115.59]) [113.163.115.59]
H=(bzq-109-66-167-239.red.bezeqint.net) [109.66.167.239]
H=(ip-address-pool-xxx.fpt.vn) [118.71.56.202]
H=(user-pc.domain) [58.186.16.123]

Ну и кроме проверки HELO/EHLO есть ещё куча проверок, включая SPF, DKIM, rate limit, greylisting, даже callout и последнее — spamassassin.

P.S. Поверьте, клиент согласен получать некоторое количество спама, но при этом он хочет быть уверенным, что нужное письмо он получит.

P.P.S. Вот нарыл в почте письмо от чё-то-там@direct.yandex.ru пришедшее с «[95.108.253.156] (helo=outback1g.mail.yandex.net)» при том что MX для direct.yandex.ru:

> dig direct.yandex.ru mx
…
;; ANSWER SECTION:
direct.yandex.ru.       3600    IN      MX      0 mx-corp.yandex.ru.
…

> dig mx-corp.yandex.ru
…
;; ANSWER SECTION:
mx-corp.yandex.ru.      3254    IN      A       213.180.204.113

По вашей логике, я это письмо не должен был принимать, ибо «ptr=mx=helo и разворачивать все, что не настроено нормально»?

Фильтрую header_checks'ами, но для этого вставляю во все входящие письма свой резюмирующий заголовок. Вот такой например (это, кстати, мой любимый спамер):

X-Headers-Digest:
        _HELO:     static.isp.belgacom.be
        _MAILFROM: discoursetqj@gmail.com
        _SPF:      Softfail (mailfrom)
        _ORIGIN:   US (unknown. [208.70.31.50]) TOREXIT
        _RELAY:    BE (150.215-183-91.adsl-static.isp.belgacom.be. [91.183.215.150]) GENERIC
        _FROM:     discoursetqj@gmail.com

Тут тебе и «Softfail» на gmail, и «US», и «TOREXIT», и «BE» с «GENERIC»'ом. Все собрал, ничего не пропустил.

Никому «Fwd:Замечательный презент=Samsung s5 за 659О руб» не надо? Их есть у него ;)

Вот мой наркоманский домен через Dyndns не может отправить почту на GMail. Тот банит как спам, так как нет PTR record (и не будет) для Reverse DNS