- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
День добрый всему комьюнити,
Задался недавно изучения концепции SMTP :D В мировом масштабе естественно :D И зашел в каком-то роде в тупик размышлений, возможно кто-то подскажет мне или натолкнет на правильные мысли, ситуация вот в чем:
Наверняка известная проблема для всех "bounce back spam", я рассмотрел это понятие с разных сторон, выходит, что с одной стороны если я отправитель этого самого "bounce back" сообщения(то есть ко мне на MTA поступило сообщение и я на него отвечаю), я как бы по хорошему должен в первую очередь удостовериться сам в валидности например From: поля в письме которое пришло ко мне (перед тем как слать баунс), на сколько я понимаю, мягких мер в этом случае существовать не может, я могу включить проверку SPF и DomainKeys (в этом случае я думаю сразу начну дропать большую часть писем, но решает ли это проблему баунса? какая разница что в теле баунсбека будет ?) либо я должен пропускать к себе всю почту и мочить её в /dev/null какими-то методами локальными что бы не создавать bounce в случае например неверного user в вирт. домене - как бы не хочется... согласитесь, а вот с другой стороны, если прикинуть что я клиент и отправил письмо, а мне в ответ ничего не пришло, я как бы считаю, что письмо доставлено, т.е не получить bounce обратный тоже не верно.....
Натолкнулся на статейку http://cbl.abuseat.org/qmailhelp.html применимую к моему MTA, там явно описаны недостатки системы работы qmail И даже рекомендуется переход на postfix / exim / sendmail. Но как говорится одна голова хорошо, а с телом лучше :D Кто что может сказать на эту тему? Я подумываю ковырнуть код qmail что бы в случае badrcptto не слать bounce back, так как 99% этих сообщений входящий спам на публичный адрес, который вот непонятно как оберегать от таких бед. Либо таки пришло время когда письмо без SPF и DomanKeys считать достоверным нет смысла вовсе? А баунс беки слать не имеет никакого смысла, пара-тройка MX и дело в шляпе?
С Уважением,
Что-то не вполне понимаю сей доморощенный термин (bounce back spam). Вот это в виду имеется:
http://en.wikipedia.org/wiki/Backscatter_(e-mail)
?
У тебя есть два варианта, с точки зрения RFC: нету такого ящика - значит либо reject, либо bounce. Для qmail (насколько я помню) есть патчи, которые ему позволяют делать reject на этапе приема письма. Как нормальным людям.
PS: Ты перебрал с тегами. qmail, spam, ненависть - хватит за глаза.
Что-то не вполне понимаю сей доморощенный термин (bounce back spam). Вот это в виду имеется:
http://en.wikipedia.org/wiki/Backscatter_(e-mail)
?
У тебя есть два варианта, с точки зрения RFC: нету такого ящика - значит либо reject, либо bounce. Для qmail (насколько я помню) есть патчи, которые ему позволяют делать reject на этапе приема письма. Как нормальным людям.
PS: Ты перебрал с тегами. qmail, spam, ненависть - хватит за глаза.
Ни кто и не говорил что будет легко, немного оптимизма и разберемся что к чему :D
У меня стоит патч на qmail , завется badrcptto, но он делает bounce а не reject, то есть я в ответ получаю:
SMTP error from remote mail server after RCPT TO:<noexist@mydomain.com>:
host mx1.mydomain.com [x.x.x.x]: 553 sorry, this recipient is in my badrecipientto list (#5.7.1)
Что получается в итоге, идет распределенный спам, видимо какие-то openrelay или поломанные хосты (уже заблокировал около 3-4k IP), подставляется левый FROM и мне фигачат "очень много писем" на ящики random-names@mydomain.com, и естественно, каждому в ответ отправляется описанное выше. Я назвал бы это bounce back spam :) пусть термин и не верны, но по факту я спамлю баунсбеками :D
Вы правильно подвели, мне надо на стадии коннекта проверять и обрывать, что бы до очереди вообще дело не доходило, если вы знаете название патча, был бы благодарен за ссылочку.
Вы правильно подвели, мне надо на стадии коннекта проверять и обрывать, что бы до очереди вообще дело не доходило, если вы знаете название патча, был бы благодарен за ссылочку.
Название, увы, не помню - но есть подозрение что такая штука была в plesk'е.
UPD: Есть в дебиановском qmail. Называется 0002-qmail-verify.diff
Название, увы, не помню - но есть подозрение что такая штука была в plesk'е.
UPD: Есть в дебиановском qmail. Называется 0002-qmail-verify.diff
TNX.
А как сие реализовано в exim / postfix ?
В двух словах - смотрит в базу данных получателей и определяет брать/послать.
http://www.postfix.org/smtpd.8.html
KNOWN VERSUS UNKNOWN RECIPIENT CONTROLS
В двух словах - смотрит в базу данных получателей и определяет брать/послать.
http://www.postfix.org/smtpd.8.html
KNOWN VERSUS UNKNOWN RECIPIENT CONTROLS
Я по моему чуток перенервничал, изучив патчик, я понял что сообщения типа badrcptto: bla bla это как раз происходит на стадии общения SMTP , то есть MTA не дает возможности слать почту если badrcptto, просто в логи сыпет что мол пытаются...... Но в таком случае откуда же мать его этот спам берется :D :D :D
Пошел изучать теорию :D
Блин, как в qmail все запущено оказывается... ;)
видимо какие-то openrelay или поломанные хосты (уже заблокировал около 3-4k IP)
Собственно для этих целей есть спамхаус и спамкоп - отличные блеклисты. Самому надолго блокировать ip нет смысла - спам очень редко долго шлется с одного ip, а если шлется, то однозначно будет в блеклисте.
SPF надо проверять обязательно и отфутболивать нарушителей. А DomainKeys в данном случае смотреть бессмысленно.
Блин, как в qmail все запущено оказывается... ;)
Собственно для этих целей есть спамхаус и спамкоп - отличные блеклисты. Самому надолго блокировать ip нет смысла - спам очень редко долго шлется с одного ip, а если шлется, то однозначно будет в блеклисте.
SPF надо проверять обязательно и отфутболивать нарушителей. А DomainKeys в данном случае смотреть бессмысленно.
Да, у меня просто истерика, надо все это в qmail засунуть , ну или придется переходить на что-то другое, а я так его люблю..... :P
Аддиктивность к отдельному софту приводит к конфузам
Если это сервер на Plesk и версия старше 9.x, переходите на postfix, там достаточно просто переключить. Если это не Plesk, тем более пора уже с qmail переходить куда-то )
Для exim можно bounce_return_message = false