Comments 149
Казалось бы, причем здесь Pink Floyd?
+8
UFO just landed and posted this here
Мне кажется, что суть в том, что на картинке изображена призма (PRISM). А Пинк Флойд не при чем )
+11
Вот именно. Больше к сжатию подходит картинка, а не к шифрованию.
-2
en.wikipedia.org/wiki/File:PRISM_logo_(PNG).png
0
SSL.no — это mail.ru?
И, кстати, на почте для доменов это тоже работает?
И, кстати, на почте для доменов это тоже работает?
0
Да, письма Почты для доменов принимаются и отправляются с тех же серверов, что и письма простой Яндекс.Почты.
+1
А какой в этом случае подключающемуся серверу предъявляется сертификат? Нужно ли мне, как владельцу домена, предоставлять SSL-сертификат в ПДД?
0
UFO just landed and posted this here
А проблем не может быть, если CN сертификата не совпадает с MX?
Например, настроен сбор почты с другого ящика. И там тоже сервер умеет шифрование.
Но при отправке через web интерфейс яндекса, письмо уходит с серверов яндекса, а не с сервера моего ящика.
Например, настроен сбор почты с другого ящика. И там тоже сервер умеет шифрование.
Но при отправке через web интерфейс яндекса, письмо уходит с серверов яндекса, а не с сервера моего ящика.
0
mail.ru, кстати, тоже использует шифрование. Причём очень давно.
Вот такие стоки я регулярно наблюдаю в логах моего сервера:
От яндекса тоже:
У обоих выбранный алгоритм шифрования всё же получше чем у гугла:
Вот такие стоки я регулярно наблюдаю в логах моего сервера:
Anonymous TLS connection established from abusef1.i.mail.ru[185.5.137.4]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
От яндекса тоже:
Anonymous TLS connection established from forward1m.mail.yandex.net[37.140.138.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
У обоих выбранный алгоритм шифрования всё же получше чем у гугла:
Anonymous TLS connection established from mail-ea0-f194.google.com[209.85.215.194]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
+2
Mail.ru использует только в одну сторону, к сожалению. Исходящая почта от них может быть зашифрованной, а входящая — нет. Что несколько снижает смысл этого.
+1
Проверил. Действительно :(
Кстати, а на кого расчитана вот эта реклама? :)
Кстати, а на кого расчитана вот эта реклама? :)
$ telnet mx.yandex.ru 25
Trying 77.88.21.89…
Connected to mx.yandex.ru.
Escape character is '^]'.
220 mxfront10o.mail.yandex.net (Want to use Yandex.Mail for your domain? Visit pdd.yandex.ru)
+2
Хорошо расписали что к чему, и зачем сделано. Всегда приятно такое почитать. Спасибо.
+11
Использование шифрования в своём сервисе не требует лицензии в ФСБ?
0
Яндекс — голландская компания!
-4
О как меня замнусовали.
Минусующим советую сходить хотя бы на википедию и почитать.
Это я о том что юридически российский офис Яндекса мало чем отличается от офиса Гугла.
И ФСБ прежде чем делать такие заявления не мешало бы четко пояснить о каких компаниях они говорили и как это предстоит оценивать чиновникам.
Минусующим советую сходить хотя бы на википедию и почитать.
Компания зарегистрирована в России как ООО «Яндекс», 100 % уставного капитала которого владеет зарегистрированное в Нидерландах акционерное общество Yandex N.V.
Это я о том что юридически российский офис Яндекса мало чем отличается от офиса Гугла.
И ФСБ прежде чем делать такие заявления не мешало бы четко пояснить о каких компаниях они говорили и как это предстоит оценивать чиновникам.
-2
Чисто юридически Яндекс — полностью российская компания.
0
Это вы как определили?
67% акций торгуется на иностранных биржах, 100% уставного капитала юридически сосредоточено за пределами РФ.
Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
67% акций торгуется на иностранных биржах, 100% уставного капитала юридически сосредоточено за пределами РФ.
Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
0
При всем уважении к этому замечательному человеку, как эти слова можно подкрепить юридически?
Да, эта компания была основана на российские деньги, русским людьми.
Но инвесторы иностранные. И деньги на развитие иностранные.
То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
Да, эта компания была основана на российские деньги, русским людьми.
Но инвесторы иностранные. И деньги на развитие иностранные.
То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
-2
На иностранных биржах торгуются акции Yandex NV. Ей принадлежит полностью российское ООО Яндекс. Которая и осуществляет всю деятельность.
+1
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
Зарегистрирована в России, налоги платит в России, подавляющее большинство имущества находится в России, подавляющее число работников тоже. Кто владеет компанией дело десятое — это лишь вопрос распределения прибылей.
И вы путаете ООО «Яндекс» и Yandex N.V. ООО «Яндекс» — российская компания, основной капитал которой находится в России (тут же был оплачен уставной). 67% акций торгуется у Yandex N.V., которая является владельцем российского ООО.
0
Нет, использование не требует.
Вот что говорят наши юристы по этому вопросу:
Вот что говорят наши юристы по этому вопросу:
Яндекс не разрабатывает и не применяет собственные технические средства защиты информации, в том числе криптографические, и на него не возложена обязанность по сертификации таких средств или по лицензированию компании в качестве их разработчика. Техническое обслуживание таких средств для обеспечения собственных нужд компании и с учетом примененных в проекте технических решений, по указанию Постановления Правительства РФ от 16.04.2012 N 313 и смежных актов, также не является лицензируемой деятельностью.
+1
Но у вас не собственные нужды, вы предоставляете сервис.
К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;
www.consultant.ru/document/cons_doc_LAW_128739/
© КонсультантПлюс, 1992-2013
Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;
www.consultant.ru/document/cons_doc_LAW_128739/
© КонсультантПлюс, 1992-2013
Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
0
Вот всегда интересовал вопрос: поднимаю я на собственном сервере https для публичного доступа. Имхо, это уже не внутренние нужды, а предоставление сервиса с использованием криптографии. Как ваши юристы ответят на подобные претензии со стороны контролеров?
0
Мне тоже интересно это узнать.
На сегодня все решается выводом сервера с сайтом за пределы РФ.
При трансграничной передаче шифровать ГОСТом ФСБ не требует.
На сегодня все решается выводом сервера с сайтом за пределы РФ.
При трансграничной передаче шифровать ГОСТом ФСБ не требует.
0
Это всё конечно круто, но если вам т.е Яндексу придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
+7
Содержание писем мы можем раскрывать только по санкции суда.
+5
Было бы великолепно если бы вы все обращения (кроме тех которые через суд) публиковали на отдельной странице — как это делает TPB, таким образом вы ничего не нарушаете а органы будут знать что к вам только с законными требованиями идти.
И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?
По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?
По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
+3
Подчеркну, что я не юрист, и сейчас буду говорить исключительно от своего имени.
1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.
2. Яндекс юридически и фактически — российская компания.
1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.
2. Яндекс юридически и фактически — российская компания.
+4
2. — Весьма странно, помниться я читал, что компания юридически не в России зарегистрирована.
Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
-1
На мой взгляд — потому, что мы из России и хотим жить и работать в России :)
Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
+4
UFO just landed and posted this here
Не получите, и вы ничего не сделаете, потому, что вы боитесь потерять бизнес что вполне логично.
Если бы вы хотели что-то сделать, то вы могливывести людей на улицу устроить движуху и правильно просвещать людей о том, что творит наше государство.
Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
Если бы вы хотели что-то сделать, то вы могли
Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
-8
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
И получить блокировку на уровне магистральных провайдеров. Да даже без блокировки невыполнение российских законов означает лишение возможности вести бизнес в России. Поисковиком и почтой люди смогут продолжать пользоваться, если не будет блокировки, а вот деньги получать с российских рекламодателей будет затруднительно, даже если валютные переводы не будут отклоняться, а это, вроде как, основной источник доходов.
0
Содержание писем мы можем раскрывать только по санкции суда
Так значит все-таки можете? В опжу тогда такие криптографии!
-11
Таких, кто может не раскрыть содержание письма даже по санкции суда, не бывает, увы. Это требование закона (не только в России).
+2
Шифруйте свои письма открытым ключом получателя и только он сможет их раскрыть. SSL/TLS предназначены для защиты от негласной прослушки (и вторжения) каналов передачи, а не хранящихся данных.
0
> придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
+6
Да это понятно всё, это конечно великолепно, но нет ничего хуже чем иллюзия безопасности.
-3
Хмм, какая иллюзия? От хацкеров благодаря такому я, в какой-то степени, в большей безопасности. А государственным органам проще меня IRL достать, если вдруг понадоблюсь.
Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.
И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.
И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
+2
Когда я говорю про иллюзию безопасности, то я имею ввиду такие продукты как Bittorrent Sync — теоретически он безопасен, а на практике? — никто исходников не видел.
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
0
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
Зачастую такой троллинг может дорого обойтись, вплоть до ареста.
0
Только по решению суда.
Проще ВНЕЗАПНО найти детский прон на серверах и заблокировать по IP.
Проще ВНЕЗАПНО найти детский прон на серверах и заблокировать по IP.
+1
Я выше писал, что следует не быть русской компанией
0
Где-то читал, про передачу зашифрованных сообщений в комментариях на YouTube. Сообщения шифруются одноразовыми криптоблокнотами и просто выкладываются в общий доступ. Прелесть же!
0
https для соединения с абонентом — и так уже фактически стандарт, тут нечем хвастаться.
Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
-8
Круто. А какие ещё сервисы (из популярных) кроме GMail поддерживают шифрование?
+2
Автор, чтож ты ничего не рассказал про структуру PKI? Публичная-то она — это хорошо, но PKI ущербна в самой своей сути из за наличия CA — «корней» дерева и тучи предустановленных «доверенных» сертификатов когда юзер доверяет непонятно кому. И вообще, это не хайтечно и напоминает допотопные времена, когда никакого DNS не было и все хосты прописывались в /etc/hosts, а службы — в /etc/services
Пока еще SMTP по автомату принимает самоподписанные сертификаты, но что-то мне подсказывает, что эта халява продлится недолго. Например, в CommunigatePro уже есть опция «Отключить прием самоподписанных». И привет.
$ openssl s_client -starttls smtp -crlf -host mx-corp.yandex.ru -port 25
…
depth=2 C = US, O = GTE Corporation, OU = «GTE CyberTrust Solutions, Inc.», CN = GTE CyberTrust Global Root
…
ФСБ негодуе, особенно от C=US
Пока еще SMTP по автомату принимает самоподписанные сертификаты, но что-то мне подсказывает, что эта халява продлится недолго. Например, в CommunigatePro уже есть опция «Отключить прием самоподписанных». И привет.
$ openssl s_client -starttls smtp -crlf -host mx-corp.yandex.ru -port 25
…
depth=2 C = US, O = GTE Corporation, OU = «GTE CyberTrust Solutions, Inc.», CN = GTE CyberTrust Global Root
…
ФСБ негодуе, особенно от C=US
+1
А на токене можно ключ хранить?
0
Давно пора, тем более, что там работы совсем немного.
+1
Ребят, ценность этого шифрования близка или равна нулю. Нарисуйте там чёрного человечка, между красным человечком и синим, и поймете почему.
1) Магистральному провайдеру достаточно встать MITM-ом и для отдавать smtp Яндекса фейковые пакетики что удалённый MX не умеет STARTTLS, и всё. Что вы почту доставлять не будете? Да нет, вы просто пойдёте по старинке, plain-text-ом.
2) Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI) или каким-нибудь маленьким доверенным CA. И тем более, SSL никоим образом не спасает в этом месте от всяких там PКISM и прочих америкосов, кто имеет доступ внутрь больших корневых CA.
Вобщем байки это всё, с человечками :)
1) Магистральному провайдеру достаточно встать MITM-ом и для отдавать smtp Яндекса фейковые пакетики что удалённый MX не умеет STARTTLS, и всё. Что вы почту доставлять не будете? Да нет, вы просто пойдёте по старинке, plain-text-ом.
2) Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI) или каким-нибудь маленьким доверенным CA. И тем более, SSL никоим образом не спасает в этом месте от всяких там PКISM и прочих америкосов, кто имеет доступ внутрь больших корневых CA.
Вобщем байки это всё, с человечками :)
+4
UFO just landed and posted this here
Привет Вов. Очень внимательно слежу, скучаю ведь :)
Сertificate pinning(если он реализован конечно и вы действительно запоминаете issuer-ов для всех возможных MX) решает не все проблемы.
Действительно, с Intermediate CA проблем не будет, но это не решает проблемы с потенциальным доступом АНБ к корневым сертификатам, например.
Или с тем, что многие MX могут внезапно перевыпустить свой сертификат, уже через другого CA.
И кстати именно по этой причине, в современные браузеры certificate pinning не встроен, т.к. процент false positive у него неимоверно высок.
Крупные вендоры могут договориться, да, но что делать остальным?
И ты не ответил про блокировку STARTTLS ;) Что будет, если DPI у магистральщика будет «отменять TLS», провоцируя downgrade до plaintext? Не можете же вы не доставлять письма.
Сertificate pinning(если он реализован конечно и вы действительно запоминаете issuer-ов для всех возможных MX) решает не все проблемы.
Действительно, с Intermediate CA проблем не будет, но это не решает проблемы с потенциальным доступом АНБ к корневым сертификатам, например.
Или с тем, что многие MX могут внезапно перевыпустить свой сертификат, уже через другого CA.
И кстати именно по этой причине, в современные браузеры certificate pinning не встроен, т.к. процент false positive у него неимоверно высок.
Крупные вендоры могут договориться, да, но что делать остальным?
И ты не ответил про блокировку STARTTLS ;) Что будет, если DPI у магистральщика будет «отменять TLS», провоцируя downgrade до plaintext? Не можете же вы не доставлять письма.
0
UFO just landed and posted this here
Ну так вопрос-то остался без ответа: да, вы заметите, что Google внезапно перестал предлагать STARTTLS (а раньше предлагал, сертификат был выдан вот этим CA). Ну или внезапно предъявил сертификат от Komodo (вместо Geotrust через свой промежуточный).
И что, откажетесь доставлять почту в этом случае?
И что, откажетесь доставлять почту в этом случае?
+1
А если добавить в стандарт DMARC политику шифрования. Типа наша почта только с DKIM и шифрованная, иначе реджект.
+1
> Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI)
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
+3
Встать MITM-ом и пассивно прослушать стоит разных усилий.
Привет :)
Привет :)
+3
в тему:
-1
UFO just landed and posted this here
Только смысл от всего этого, если вы банально игнорируете добавление двухэтапной аутентификации?
-3
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
+2
Facebook свободно показывает профиль, зарегистрированные на определённый email, если ввести этот email в поиск самого Facebook. Но запретить показывать свой портрет в Яндекс.Почте можно по инструкциям на странице help.yandex.ru/mail/abook.xml#social-profiles
0
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
Но все-таки еще жалеете?
0
Привет Эдварду следовало бы заключить в тег , вы не находите? Он ведь показал, что АНБ не дураки и врезались на участке Гугл-Гугл, где трафик нешифрованный. Рассказали бы, если можно, как у вас с этим дело обстоит. Все сервера в Москве или есть региональные датацентры?
0
UFO just landed and posted this here
Ограничение связано с тем, что логин в Яндексе используется в очень различных сервисах и протоколах, каждый из которых в своё время накладывал на пароль свои ограничения как по длине, так и по содержанию. Когда мы убедимся, что ни одна часть за логином не пострадает от расширения набора символов и длины пароля, мы, скорее всего, изменим существующие ограничения.
+1
Ещё одни распространенным протоколом, где регулярно используется STARTTLS, является LDAP.
+1
Спасибо, интересно.
Немного не по теме вопрос, но всё-же: у меня есть проектик мелкий связанный с электронной почтой и там используется свой SMTP релей. Проблема в том, что при попытке отправить почту на yandex ящики постоянно возникает ошибка
Если повторять попытку отправки много раз, то всё-же письмо проходит. С другими сервисами (mail.ru, gmail) всё проходит с первого раза.
Это нормальное поведение и просто нужно продолжать попытки или всё-же где то закрался баг?
Немного не по теме вопрос, но всё-же: у меня есть проектик мелкий связанный с электронной почтой и там используется свой SMTP релей. Проблема в том, что при попытке отправить почту на yandex ящики постоянно возникает ошибка
retries_exceeded {temporary_failure,"mx.yandex.ru",<<"451 4.7.1 Sorry, the service is currently unavailable. Please come back later. aybVX4avs9-66CaKdFk\r\n">>} retries_exceeded {temporary_failure,"mx.yandex.ru",<<"451 4.7.1 Sorry, the service is currently unavailable. Please come back later. boXDD0YAFa-6aC0CbEh\r\n">>}
Если повторять попытку отправки много раз, то всё-же письмо проходит. С другими сервисами (mail.ru, gmail) всё проходит с первого раза.
Это нормальное поведение и просто нужно продолжать попытки или всё-же где то закрался баг?
+2
Это банальный грейлистинг. Скорее всего вы просто недостаточно аутентифитировали свой релей. Стоит начать со следующих ключевых слов: PTR, SPF, DKIM, DMARC.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
+5
А, в смысле «спамеры не будут делать много попыток отправить письмо, а легальным сервисам хочешь-не-хочешь а нужно». Что то такое читал…
SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
0
PTR как раз получится настроить. Никто же не требует, чтобы почта с user@domain.ru уходила обязательно с хоста в domain.ru.
Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
+1
Грейлистинг — бессмысленная технология IMHO. Сделана в надежде, что «спаммеры так не умеют» и «у них машинки слабенькие». Оба тезиса неверны.
0
Не совсем так. Самое главное в грейлистинге это проверка засылающей стороны а) на реализацию корректной обработки ошибок и б) на корректную реализацию очереди с рекомендуемыми в RFC таймаутами. Т.е убеждение, как одна из ряда проверок, что перед нами какой-никакой MTA. Я не фанат данной технологии, но по информации оно срезает от 10% до 50% спама в зависимости от того в какие спам базы вы попали :)
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
0
Оказалось, что всё намного проще. После экспериментов заметил, что у меня в EHLO подставлялся не реальный домен сервиса а локальный хостнейм из /etc/hostname
После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
0
Кстати, правильно я понимаю, что 465 порт сразу ssl соединение, а 587 Submission?
0
Вот лет 15 назад это было ново :)
Новость — отличная, что ни говори!
Новость — отличная, что ни говори!
-3
За что минусуете? Новость и правда отличная, а что вводят сейчас, а не 5, а то и 10 лет назад — да, не очень рано, но тоже понять можно, зашифровать такое число соединений и такой трафик тоже немало ресурсов кушает.
0
news.cnet.com/8301-13578_3-57590389-38/how-web-mail-providers-leave-door-open-for-nsa-surveillance/
15 не 15, но статистика налицо.
15 не 15, но статистика налицо.
+1
Вопрос на засыпку: а клиентское шифрование собираетесь поддерживать, чтобы даже вы не знали текста письма? Хотя, конечно, Директ…
0
Если Яндекс не будет знать о содержимом письма, то как он сможет его отдавать по IMAP/POP3, отсылать на другие сервера получателям?
0
Расшифровывать на стороне клиента, используя что-то вроде реализации PGP на Javascript.
Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
0
Там другие проблемы возникают.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
-1
Как раз JS в браузере — отличное клиентское приложение. Например, все плагины в Fx и есть JS.
Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
0
То что плагины ФФ пишутся на JS(XUL) это понятно, но свои внутренние данные они хранят на диске в надёжном пользовательском профиле, а не в куках или некоем ненадёжном localstorage.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
0
А чем это отличается от, например, удаления профиля? Тоже же можно. А ещё винт может посыпаться.
Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
0
Отличается тем, что в случае с плагином ты можешь заставить пользователя сохранить свой ключик где-нибудь в надёжном месте, а в случае с JS и localstorage уже нет :)
0
И в случае с плагином никак не получится заставить. Он всегда, например, сможет «сохранить и потом стереть».
Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.
Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.
Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
0
UFO just landed and posted this here
например в Local Storage
0
UFO just landed and posted this here
Почему не подходит? Ключ вполне представим в виде строки. Реализовать RSA и AES на Javascript можно. Чего не хватает?
0
UFO just landed and posted this here
Технически это возможно. Да, Кэп, Идея глупая (с точки зрения безопасности), но точно реализуемая.
Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.
Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.
0
Я, конечно, прошу прощения, но браузеров, умеющих получать почту по POP3/IMAP и затем исполняющих полученный с сервера JS для обратоки писем, не бывает.
0
И я правильно понял, что вы не хотите доверять серверу яндекса открытый текст сообщения, но с радостью доверите его коду, который передается в браузер с сервера яндекса и может измениться в любой момент?
+2
Это то же самое, что доверять, скажем, операционной системе Windows. Всё равно всё может измениться в произвольный момент — пришло обновление, которое ставится принудительно вне зависимости от настроек обновлений — и привет.
-1
Какой-то витиеватый ответ на вопрос. :)
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
0
Если витьеватый ответ, то — я вообще-то не доверяю Windows и не использую её ;)
А если серьёзно, то нет, я не буду доверять. Я не буду вообще доверять это никому в «обычном» интернете.
А если серьёзно, то нет, я не буду доверять. Я не буду вообще доверять это никому в «обычном» интернете.
0
UFO just landed and posted this here
А зачем для этого ему знать содержимое? Вот я сейчас отправляю шифрованные (шифрую в консоли и копипащу в веб-интерфейс) письма и нормально доходят.
0
И как он будет определять спам?
0
По содержимому — никак. Ему будет доступно некоторое количество метаданных (например, заголовки).
Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
+1
А ему это нужно?
0
Не понимаю почему это не было включено с самого начала? Не хватало серверных мощностей?
0
А ни у кого последние 3 дня проблем с отправкой через smtp не возникает?
Подключена Яндекс.Почта для домена. Больше года всё работало без проблем. С 7-ого появились задержки в получении почты адресатом, письма (на gmail) приходили с опозданием в 5-10 минут, потом вовсе перестало что либо приходить. 9-ого в обед вывалилось всё, что застряло с 7-ого. А сегодня частенько «Send AUTH command first» и «Sender address rejected: not owned by auth user» на пустом месте для приблизительно 1 письма из 10.
Кто виноват и что делать?
Подключена Яндекс.Почта для домена. Больше года всё работало без проблем. С 7-ого появились задержки в получении почты адресатом, письма (на gmail) приходили с опозданием в 5-10 минут, потом вовсе перестало что либо приходить. 9-ого в обед вывалилось всё, что застряло с 7-ого. А сегодня частенько «Send AUTH command first» и «Sender address rejected: not owned by auth user» на пустом месте для приблизительно 1 письма из 10.
Кто виноват и что делать?
0
а без SSL работать можно или для него порты принудительно убрали?
0
Если речь про POP, IMAP и SMTP, то работать без SSL больше нельзя. На MX и отправляющих серверах пока ещё некоторые письма принимаются и отправляются без SSL, потому что не все почтовые службы поддерживают работу по SSL в этом месте. Но вообще работа без шифрования — это снижение безопасности информации, поэтому Яндекс.Почта старается безальтернативно переходить на SSL.
0
Sign up to leave a comment.
Яндекс теперь поддерживает шифрование исходящей и входящей почты