Поправить лимит недолго; но до сих пор хватало. Я исходил из предположения, что картинки пересылать не будем 🙂
On Tue, 22 Jun 2021 at 17:33 Vladimir Sharun <vladimir.sha...@ukr.net> wrote: > Привет, > > Офигеть, предыдущее письмо не пролезло по лимиту в 40к ) > > > Vladimir Sharun wrote on 22.06.2021 09:44: > > > > > Вы хостите почту самых разных пользователей и в огромных > масштабах. На > > > фоне этого, чья-то скромная статистика будет совершенно не > > > показательной. Смысл тут, скорее всего, в том, каким образом, > > > конкретные адреса попали в их спам листы. Это может быть и > > > определённая целевая аудитория. > > > > > > > > > Представь, что я хочу для улучшения своей статистики дать возможность > > > фильтрации сквозь себя какому-то ограниченному списку доменов. > > > > речь о смене MX'ов сторонних по отношению к ukr.net доменов на > > mxs.ukr.net с последующей маршрутизацией почты на реальный MX или об > > обмене информацией (владельцы сторонних доменов отдают данные о входящих > > письмах, а получают данные о репутации отравителей)? > > > > Оба варианта рассматриваются. По первому варианту работает с десяток > доменов где-то лет 15 ЕМНИП. Там правда какой-то другой MX технический, не > mxs.ukr.net > > > > Или дать инструменты репутационных запросов (а их например есть: по ip, > > > отправителю в случае фримейлов и приравнянных к ним и домену), но это > > > API, в котором будет собираться информация о mailfrom (см ниже). > > > Я хочу понять, насколько это будет приемлемо для сторонней организации: > > > > > > 1. организационно (мою почту будут читать или иметь возможность > читать! > > > - нет, это профильная статья и это высекается на раз-два > > > техническими средствами, что твою почту читают, а договора о > > > правовой взаипомощи и экстрадиции достанут из любой нормальной > > > юрисдискции) > > > > гм... т. е. таки предполагается заворачивать почту на такой сервис > целиком. > > > > Я хочу понять как этот сервис виден со стороны админа потенциального > кастомера: он может лишиться какого-то куска работы, а может и вообще > остаться без нее: может весь сервис зааутсориться. По этой причине (чтобы > не лишать работы) есть и второй вариант: обмен телеметрией. Вы: > отправитель-получатель-ip, мы - предлагаемую реакцию и вероятность, что > спам (может быть 100% и в спам, когда на взлёте рассылка, а через 300мс уже > может быть 99% и рекомендация - блок). > > Вопрос хэширования отправителя и получателя - это хороший вопрос. И он оч > сложный этически. Сейчас покажу на пальцах: передать эту пару - это спалить > кто с кем переписывается, что проблема бизнес и этическая (соблазн со > стороны исполнителя начать торговать). Не передавать - смысла со стороны > исполнителя заниматься благотворительностью нет. > > Я думал над хэшированием, вот такие мысли: > учитывая 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 (и > > другим "специфическим" получателям) относится немного по-другому? > > Одинаково они ко всем относятся, мне интересно было вот домен, вот вам с > него пришло (или не пришло) и я могу спроецировать вас до меня, после, во > время - как ? Другое дело что с 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. Вот такие системы сейчас - это острие: Майкрософт с эндпоинтом, > Краудстрайк - это облачные коррелляторы событий безопасности, которые > технически бесполезны в он премисес варианте: нехватка даты и соотв > неточные результаты риалтайм. > > > > PS: есть кейс AmazonSES и бесплатной части Sendgrid'а, где надо > > > связывать mail from & from после DATA - это как оказалось те еще > > > сервисы, 40% почты с Амазон-а оказалась спамом, но и это решаемо. > > > > т. е. в этом случае сабмита данных, полученных на этапе RCPT To > > включительно, будет недостаточно. нужны ещё как минимум и заголовки. > > мало того, ответ сервиса будет справедлив именно для этого письма (в > > следующем письме с этого же IP с этого же адреса отправителя адрес из > > заголовка From может уже и совпадать с ним, а в предыдущем мог и не > > совпадать). > > Да. Ответ риалтайм: на конкретную пару с конкретного ip. В 90+% случаев > это будет ОК кстати :) > Но может быть первый запрос ОК, а второй - СПАМ, третий - рекомендация - > БЛОК на одного и того же отправителя - это норма. Надо набить скоринг > вначале. > > > > Где-то такая идея. > > > > не знаю, на сколько ощутимо выиграет от этого ukr.net (всё же перекос в > > количестве входящих писем грандиозный), но почтовым системам помельче > > такая идея может быть весьма полезной. > > > > у меня стопоров только два: > > > > 1. нет желания заворачивать всю почту через такой сервис путём смены > > основного MX'а. > > > > Кто-то захочет полностью заатусорсить почту/МХ, ему такой вариант ок. > Можно сделать доставку вплоть до LMTP. > > > 2. в случае, если MX переписывать не нужно, нет желания сабмитить письмо > > целиком (а без этого получить статистику об аттачам и файлах внутри > > архивов из этих аттачей будет невозможно). > > > > Это не нужно - это вы сами. Здесь только репутационная модель. Что > касается кейса Амазона - это канеш труба, там вот так: > сначала сейвятся все пары mailfrom - rcpt: их может быть больше одной и > сюрприз! - вам могут передать очень полезную пару несуществующего > экаунта-засвеченного_спамтрапа, который вы или блокнете на rcpt - (нельзя!) > или дискарднете - (тоже нельзя!). Имеет смысл аксептнуть и редиректнуть в > дискард в роутере при доставке - тогда вам будут доступны заголовки (но > придётся принять письмо, но каналы сейчас толстые) > потом делается перевставка этих пар с заменой mailfrom на headerfrom и > удаление пар mailfrom. > > Проблема общего характера: exim распространён у нас слабо, много > постфикса, куда это я не уверен что легко заинтегрируется (но там он как > правило от безысходности: поставили хоть что-то и owner'ы бизнеса будут > счастливы сдать на аутсорс весь сервис). > > > но, на сколько я понимаю, даже от получения и анализа данных, доступных > > до DATA, уже будет польза и для ukr.net и для других участников > мероприятия. > > > > Да. > > > > _______________________________________________ > Exim-users mailing list > Exim-users@mailground.net > http://mailground.net/mailman/listinfo/exim-users > > -- -- What do you get when you play country music backwards? You get your girl back, your dog back, your pick-up back, and you stop drinking. Louis Saaberdra
_______________________________________________ Exim-users mailing list Exim-users@mailground.net http://mailground.net/mailman/listinfo/exim-users
