Vladimir Sharun wrote on 22.06.2021 17:32: > Офигеть, предыдущее письмо не пролезло по лимиту в 40к )
у нас тут уже 40k текста? ну... это могло быть только из-за text/html вместо text/plain >>> Вы хостите почту самых разных пользователей и в огромных масштабах. На >>> фоне этого, чья-то скромная статистика будет совершенно не >>> показательной. Смысл тут, скорее всего, в том, каким образом, >>> конкретные адреса попали в их спам листы. Это может быть и >>> определённая целевая аудитория. >>> >>> Представь, что я хочу для улучшения своей статистики дать возможность >>> фильтрации сквозь себя какому-то ограниченному списку доменов. >> >> речь о смене MX'ов сторонних по отношению к ukr.net доменов на >> mxs.ukr.net с последующей маршрутизацией почты на реальный MX или об >> обмене информацией (владельцы сторонних доменов отдают данные о входящих >> письмах, а получают данные о репутации отравителей)? >> > > Оба варианта рассматриваются. По первому варианту работает с десяток доменов > где-то лет 15 ЕМНИП. Там правда какой-то другой MX технический, не mxs.ukr.net ну... то, какой именно из серверов ukr.net там будет в MX'ах, особой роли не играет. >>> Или дать инструменты репутационных запросов (а их например есть: по ip, >>> отправителю в случае фримейлов и приравнянных к ним и домену), но это >>> API, в котором будет собираться информация о mailfrom (см ниже). >>> Я хочу понять, насколько это будет приемлемо для сторонней организации: >>> >>> 1. организационно (мою почту будут читать или иметь возможность читать! >>> - нет, это профильная статья и это высекается на раз-два >>> техническими средствами, что твою почту читают, а договора о >>> правовой взаипомощи и экстрадиции достанут из любой нормальной >>> юрисдискции) >> >> гм... т. е. таки предполагается заворачивать почту на такой сервис целиком. >> > > Я хочу понять как этот сервис виден со стороны админа потенциального > кастомера: он может лишиться какого-то куска работы, а может и вообще > остаться без нее: может весь сервис зааутсориться. если речь о смене основного MX'а, то кто его знает... даже если кастомер как компания пойдёт на это (добровольно отдавать кому-то свою почту мало кто захочет, хотя целыми толпами отдают тому же cloudflare весь свой http трафик, хотя там летает много чего, в том числе данные авторизации, при этом cloudflare - официальный поставщик решения "наш MITM у вашим услугам"), то не все postmaster'а захотят практически полностью терять контроль над ситуацией. вот смотрю я на тех, кто отдал свою почту в рабство к G Suite, Office 365 (а до недавнего времени к Яндекс.ПДД и не помню как у mail.ru этот сервис называется), так они ж не в курсе, что к ним не доходит, из-за чего не доходит, что с этим делать и т. д. а если MX не менять, то с моей точки зрения в работе postmaster'а в худшую сторону ничего не поменяется. такой сервис для почтовой системы кастомера будет поставщиком оперативной информации, а не полностью заменит всю систему фильтрации. что-то эта сервис не покроет (какую-то специфику кастомера). что-то нужно будет оградить от сервиса. у меня наверняка каждый из клиентов захочет не давать никому данные о письмах от определённых внешних отправителей и/или для определённых локальных получателей. а может исключать придется письма по комбинациям адресов отправителей и получателей). плюс для торговых компаний нужно будет исключить письма с прайлистами поставщиков, которые обычно шлются роботами разной степени кривизны. в любом случае при наличии данных, даже основанных на статистике огромного по меркам почтовой система кастомера количества входящей почты сервиса, я бы не принимал решение об отказе в доставке письма исключительно на основании этих данных. вес у такого критерия может быть большим, может даже огромным, но я бы 100% не ставил бы. так что работы меньше не станет. но результат должен быть лучше. > По этой причине (чтобы не лишать работы) есть и второй вариант: обмен > телеметрией. Вы: отправитель-получатель-ip, мы - предлагаемую реакцию и > вероятность, что спам (может быть 100% и в спам, когда на взлёте рассылка, а > через 300мс уже может быть 99% и рекомендация - блок). как по мне - такой вариант лучше. только телеметрии должно быть чуть больше (как минимум helo я бы учитывал, да и версию TLS и cipher). и, если можно, предусмотреть вариант "IP, helo, адрес отправителя" без адреса получателя. на случай, если кто-то из клиентов не захочет, чтобы наружу утекали данные о взаимных контактах конкретно взятых респондентов. > Вопрос хэширования отправителя и получателя - это хороший вопрос. И он оч > сложный этически. Сейчас покажу на пальцах: передать эту пару - это спалить > кто с кем переписывается, во-во > что проблема бизнес и этическая (соблазн со стороны исполнителя начать > торговать). Не передавать - смысла со стороны исполнителя заниматься > благотворительностью нет. а в чём тут благотворительность? > Я думал над хэшированием, вот такие мысли: > учитывая 26 символов + 10 цифр + десяток спецсимволов получить хэш-коллизию > пары на видеокарте можно весьма быстро (перебрав сначала словарь из млрд > имейлов и неск млн доменов в порядке уменьшения вероятности). Даже при > использовании sha3 с перебором в асике или видеокарте - это млрд хэшей/с, > т.е. пара будет при желании восстановлена за секунды. Энергоёмкие алгоритмы > могут привести к ДОСу, по-этому всякие b/s crypt не рассматриваются > если передавать кусок хэша - см п.1 > но -> > если сторона-запрашиватель будет хэшировать параметрическим salt'ом так, что > всегда будет один и тот же алгоритм для одного и того же получателя и/или > отправителя, то и ок. Но мне всё равно нужен отправитель в открытом виде, однозначно. иначе сервис потеряет ощутимую часть полезности > чтобы на него дать ответ, получатель не важен, пусть это будет какой-то > деперсонифицированный код: он нужен для статистики, для бигдаты. по идее, хешировать его должна сторона кастомера. и по идее никакой разницы нет, какой алгоритм хеширования будет применён. >>> 2. технически - это и было самое интересное: >>> 1. например маркетингер меня уже давно не спамит, потому что это >>> пустая трата времени, где-то внутри секунды домен блокируется, а >>> в течении часов - ip. И тут вот еще одно есть интересное:если ты >>> хочешь, чтобы тебя mail.ru или gmail (именно эти двое) не >>> забанили, тебе нельзя спамить внутрь, а фидбеклупы они нг >>> читают. Именно по этой причине есть всякие baza_ta...@mail.ru c >>> десятками тыс получателей, спамящий в блок сутками. Такие же >>> группировки есть и на gmail'е. По-этому -> >>> 2. если меня уже не спамят (домен ? mx ?), то кого-то могут >>> продолжать спамить. У меня нет сомнений, что "там" сидят >>> ленивые, но высокоинтеллектуальные люди: списки они врядли будут >>> чистить, а если и да, то почему бы и нет :). >> >> т. е. речь о том, что статистика, собранная на базе входящих писем >> ukr.net становится не репрезентативной не потому, что писем мало (как у >> остальных), а потому, что спамеры в ряде случаев начинают к ukr.net (и >> другим "специфическим" получателям) относится немного по-другому? > > Одинаково они ко всем относятся, да я уже понял по фразе ниже, что речь не о повышении эффективности фильтрации на ukr.net за счёт расширения статистики. > мне интересно было вот домен, вот вам с него пришло (или не пришло) и я могу > спроецировать вас до меня, после, во время - как ? Другое дело что с gmail на > gmail не спамят: блок будет оч быстро. > >>> 3. теперь представьте, что у вас есть засвеченные адреса, которые >>> спамят постоянно. И на них всех приходит одинаковая почта внутри >>> минуты. С каждым новым совпадением, включая нерабочие годами >>> адреса, помноженное на ловушки - уже не может быть вопросов. >> >> такие есть почти у всех. а на admin@, office@, sales@, market@, >> marketing@ и подобные могут присылать спам, даже если они нигде не >> засвечены и даже если их не существует. > > Представь что тебе на admin@ пришло, мне на пару сотен ловушек, еще кому-то > на sales@ > Какие тут могут быть выводы ? IBM зарабатывает на поведенческом софте уже > давно. да что тут представлять? я писал о том, что в каждом почтовом домене есть потенциальные спамтрапы, даже если о таковых речь вообще не шла. >>> 4. Цель - объединённые усилия, естественно с соблюдением норм GDPR >> >> вариант менять MX и получать потом сухой остаток не так интересен, как >> по API заливать данные о письме (IP отправителя, helo, адрес >> отправителя, возможно IP получателя, адрес получателя, может ещё версию >> TLS, cipher или что-то подобное) и по тому же API получать репутацию >> данного IP отправителя, домена отправителя, полного адреса отправителя. >> > > По-этому и два варианта. > >> при этом надо бы предусмотреть ещё какие-то атрибуты запроса, в которых >> можно было бы передать информацию о том, что данный адрес получателя - >> вообще спамтрап. можно передать информацию об отсылке инфицированных >> аттачей. >> > > Что это что-то оч сладкое, у меня сразу алгоритмы коррелляции подскажут :) если письмо прилетело на пару спамтрапов, то тут не нужны тонны писем, по которым корреляцию надо будет прослеживать. т. е. скорость реакции будет не секунды, а в общем-то сразу же с первых сабмитов. >> и, кстати, можно было бы предусмотреть сабмит данных не только в >> риалтайме. если в ходе ручных разборок оказалось, что в письме прилетела >> ссылка на заражённый сайт или что pdf в письме оказался с трояном, на >> который никто не среагировал, кроме локального антивируса у получателя в >> момент сохранения аттача на диске, чтобы можно было засабмитить данные о >> таком письме вручную с указанием причины сабмита. > > Кейс, когда кто-то отспамился по своей адресбуке как спам не считается, пусть > это даже будет троян, тут уж сами как-то. > Мало того, это и распознано как спам не будет. Статистическое отсечение: > недостаточно "цвета" в рассылке, очень она с белым шумом. > Я такое наблюдаю регулярно btw. тут больше речь не о серых письмах (не то спам, не то не спам), а о письмах, в которых могло прилететь что-то инфицированное, что сразу не было распознано как инфицированное. хотя... инфицированные письма прилетают и с публичных почтовых ситем. так что с этим действительно надо на месте разбираться. >>> 5. Чем больше доменов участвуют "в игре", тем выше качество >>> фильтрации, тем ниже шансы эту группу отспамить. Реакция весьма >>> быстрая (реалтайм), шансов "отвертеться" очень мало: надо >>> перестать спамить, надо откуда-то взять адреса, которые не были >>> засвечены, надо знать, какие адреса засвечены и избавиться от >>> них: цель достигнута, спам остановлен :) >> >> а на сколько эта идея гипотетическая? > > Мне надо понять интерес к этой теме, чтобы подумать каким образом сделать > интерфейс к этой системе (или не делать). > Конечная цель - это подписка по каким-то совершенно нечувствительным ценам с > отсечением доса (например вас спамом заваливает ботнет и мы очевидно это не > считаем). мне чтобы получить ответ от клиента, нужно понимание соотношение повышения эффективности работы его почтовой системы и цены. ну и с учётом того, что какая-то часть данных о письмах будет уходить сервису. и тогда нужен какой-то пробный период. чтобы подключиться и посмотреть, на сколько что-то в лучшую сторону изменится в работе почтовой системы кастомера (банально отдельно сложить копии писем, которые сама система кастомера не распознала как спам, а сервис распознал). >> данные о репутации смогут получать только те, кто предоставляет данные >> для анализа? > > Квид про кво. да я уже понял по фраз о совершенно нечувствительных ценах. >> можно будет получать данные о репутации произвольных IP или адреса >> отправителя? или только тех, которые соответствуют письму, данные о >> котором (или само письмо) нужно залить сервису? > > Только по конкретной паре. Технически дату можно и выкачать, обманывая, но > смысла нет, т.к. смысл бигдаты он риалтаймовый: база сейчас уже через день > другая совсем - это не грубо говоря набор там сигнатур эксплоитов для > IDS/DPI. Вот такие системы сейчас - это острие: Майкрософт с эндпоинтом, > Краудстрайк - это облачные коррелляторы событий безопасности, которые > технически бесполезны в он премисес варианте: нехватка даты и соотв неточные > результаты риалтайм. ok, понятно. т. е. в общем случае я получаю данные по тому письму, данные о котором заливаю. но если очень сильно надо, то можно ручками смастерить запрос и получить то, что нужно. >>> PS: есть кейс AmazonSES и бесплатной части Sendgrid'а, где надо >>> связывать mail from & from после DATA - это как оказалось те еще >>> сервисы, 40% почты с Амазон-а оказалась спамом, но и это решаемо. >> >> т. е. в этом случае сабмита данных, полученных на этапе RCPT To >> включительно, будет недостаточно. нужны ещё как минимум и заголовки. >> мало того, ответ сервиса будет справедлив именно для этого письма (в >> следующем письме с этого же IP с этого же адреса отправителя адрес из >> заголовка From может уже и совпадать с ним, а в предыдущем мог и не >> совпадать). > > Да. Ответ риалтайм: на конкретную пару с конкретного ip. В 90+% случаев это > будет ОК кстати :) > Но может быть первый запрос ОК, а второй - СПАМ, третий - рекомендация - БЛОК > на одного и того же отправителя - это норма. Надо набить скоринг вначале. так такое будет в начале каждой крупной рассылки, когда будут спамить с "чистых" айпишников, с корректными PTR/SPF/DKIM/DMARC, письма будут без косяков в заголовках, а содержимое будет не на столько откровенно спамовым. вот тогда первые, кто получат такие письма (в первые секунды, о которых тут речь уже шла) и получат OK. >>> Где-то такая идея. >> >> не знаю, на сколько ощутимо выиграет от этого ukr.net (всё же перекос в >> количестве входящих писем грандиозный), но почтовым системам помельче >> такая идея может быть весьма полезной. >> >> у меня стопоров только два: >> >> 1. нет желания заворачивать всю почту через такой сервис путём смены >> основного MX'а. >> > > Кто-то захочет полностью заатусорсить почту/МХ, ему такой вариант ок. Можно > сделать доставку вплоть до LMTP. >> 2. в случае, если MX переписывать не нужно, нет желания сабмитить письмо >> целиком (а без этого получить статистику об аттачам и файлах внутри >> архивов из этих аттачей будет невозможно). > > Это не нужно - это вы сами. Здесь только репутационная модель. Что касается > кейса Амазона - это канеш труба, там вот так: > сначала сейвятся все пары mailfrom - rcpt: их может быть больше одной и > сюрприз! - вам могут передать очень полезную пару несуществующего > экаунта-засвеченного_спамтрапа, который вы или блокнете на rcpt - (нельзя!) > или дискарднете - (тоже нельзя!). Имеет смысл аксептнуть и редиректнуть в > дискард в роутере при доставке - тогда вам будут доступны заголовки (но > придётся принять письмо, но каналы сейчас толстые) я возвращаю 550 после DATA (вернее, после последней точки, как правильно замечено выше, каналы нынче толстые) и имею доступ к заголовкам. и письмо доставляется в персональный карантин получателя. fakereject рулит. особенно это хорошо в случае ложных срабатываний. например, айпишник у почтовой системы поменялся, а SPF запись не пофиксили, а там дефолтная политика "-all". и тогда отправителя получает свой баунс (т. е. знает, что с доставкой что-то не то), получатель - письмо в карантине, плюс возможность в вебмейле завайтлистить отправителя, маякнуть о проблеме мне, а самому реагировать на письмо, выковырянное из карантина. > потом делается перевставка этих пар с заменой mailfrom на headerfrom и > удаление пар mailfrom. > > Проблема общего характера: exim распространён у нас слабо, много постфикса, > куда это я не уверен что легко заинтегрируется (но там он как правило от > безысходности: поставили хоть что-то и owner'ы бизнеса будут счастливы сдать > на аутсорс весь сервис). я уже молчу о всяких MDaemon ;-) >> но, на сколько я понимаю, даже от получения и анализа данных, доступных >> до DATA, уже будет польза и для ukr.net и для других участников мероприятия. > > Да. -- Best wishes Victor Ustugov mailto:vic...@corvax.kiev.ua JID: vic...@corvax.kiev.ua GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc _______________________________________________ Exim-users mailing list Exim-users@mailground.net http://mailground.net/mailman/listinfo/exim-users
