Pull to refresh

Comments 149

UFO just landed and posted this here
Мне кажется, что суть в том, что на картинке изображена призма (PRISM). А Пинк Флойд не при чем )
извините, но «НИ при чем»
Вот именно. Больше к сжатию подходит картинка, а не к шифрованию.
Да, письма Почты для доменов принимаются и отправляются с тех же серверов, что и письма простой Яндекс.Почты.
А какой в этом случае подключающемуся серверу предъявляется сертификат? Нужно ли мне, как владельцу домена, предоставлять SSL-сертификат в ПДД?
UFO just landed and posted this here
А проблем не может быть, если CN сертификата не совпадает с MX?
Например, настроен сбор почты с другого ящика. И там тоже сервер умеет шифрование.
Но при отправке через web интерфейс яндекса, письмо уходит с серверов яндекса, а не с сервера моего ящика.
UFO just landed and posted this here
Сертификат выдаётся в данном случае не на тот домен, который указан в email после собаки, а на доменное имя сервера, который принимает или отправляет письма. А также отправка (как минимум у Яндекса) производится не с MX-серверов, а с других.
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)
Mail.ru использует только в одну сторону, к сожалению. Исходящая почта от них может быть зашифрованной, а входящая — нет. Что несколько снижает смысл этого.
Проверил. Действительно :(

Кстати, а на кого расчитана вот эта реклама? :)
$ 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)
Хорошо расписали что к чему, и зачем сделано. Всегда приятно такое почитать. Спасибо.
Использование шифрования в своём сервисе не требует лицензии в ФСБ?
Яндекс — голландская компания!
О как меня замнусовали.

Минусующим советую сходить хотя бы на википедию и почитать.

Компания зарегистрирована в России как ООО «Яндекс», 100 % уставного капитала которого владеет зарегистрированное в Нидерландах акционерное общество Yandex N.V.


Это я о том что юридически российский офис Яндекса мало чем отличается от офиса Гугла.
И ФСБ прежде чем делать такие заявления не мешало бы четко пояснить о каких компаниях они говорили и как это предстоит оценивать чиновникам.
Чисто юридически Яндекс — полностью российская компания.
Это вы как определили?
67% акций торгуется на иностранных биржах, 100% уставного капитала юридически сосредоточено за пределами РФ.

Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
При всем уважении к этому замечательному человеку, как эти слова можно подкрепить юридически?
Да, эта компания была основана на российские деньги, русским людьми.
Но инвесторы иностранные. И деньги на развитие иностранные.
То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
UFO just landed and posted this here
На иностранных биржах торгуются акции Yandex NV. Ей принадлежит полностью российское ООО Яндекс. Которая и осуществляет всю деятельность.
О чем и речь.
Все принадлежит иностранной компании.
И большая часть ее акций не принадлежит ей самой, а торгуется свободно на иностранных биржах.

У меня не повернется язык назвать это российской компанией.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.

Зарегистрирована в России, налоги платит в России, подавляющее большинство имущества находится в России, подавляющее число работников тоже. Кто владеет компанией дело десятое — это лишь вопрос распределения прибылей.

И вы путаете ООО «Яндекс» и Yandex N.V. ООО «Яндекс» — российская компания, основной капитал которой находится в России (тут же был оплачен уставной). 67% акций торгуется у Yandex N.V., которая является владельцем российского ООО.
Вот, это уже лучше чем банальное сливание кармы.

То есть, серверами владеет российская ООО Яндекс и они не входят в уставной капитал, я правильно понял?
Серверами владеет российская компания, они, скорее всего, входят в её основные средства и вряд ли являются частью уставного капитала, который сам по себе вещь достаточно абстрактная.
Ок, тогда ООО Яндекс можно назвать российской компанией.
Нет, использование не требует.

Вот что говорят наши юристы по этому вопросу:
Яндекс не разрабатывает и не применяет собственные технические средства защиты информации, в том числе криптографические, и на него не возложена обязанность по сертификации таких средств или по лицензированию компании в качестве их разработчика. Техническое обслуживание таких средств для обеспечения собственных нужд компании и с учетом примененных в проекте технических решений, по указанию Постановления Правительства РФ от 16.04.2012 N 313 и смежных актов, также не является лицензируемой деятельностью.
Но у вас не собственные нужды, вы предоставляете сервис.

К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;

www.consultant.ru/document/cons_doc_LAW_128739/
© КонсультантПлюс, 1992-2013

Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
Вот всегда интересовал вопрос: поднимаю я на собственном сервере https для публичного доступа. Имхо, это уже не внутренние нужды, а предоставление сервиса с использованием криптографии. Как ваши юристы ответят на подобные претензии со стороны контролеров?
Мне тоже интересно это узнать.
На сегодня все решается выводом сервера с сайтом за пределы РФ.

При трансграничной передаче шифровать ГОСТом ФСБ не требует.
Сейчас вроде как ФСБ не должно требовать шифровать по ГОСТу (если не считать гостайну и т. п.), даже если деятельность лицензируемая. Другое дело, что по слухам получить сертификат на другие СКЗИ стоит значительно дороже, типа индивидуальная экспертиза.
Нет, ФСБ просто не лицензирует ничего кроме ГОСТа.
Сертификат на СКЗИ можно получить только с использованием ГОСТа, это прямое требование.
Можно ссылку на это прямое требование?
Это всё конечно круто, но если вам т.е Яндексу придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
Содержание писем мы можем раскрывать только по санкции суда.
Было бы великолепно если бы вы все обращения (кроме тех которые через суд) публиковали на отдельной странице — как это делает TPB, таким образом вы ничего не нарушаете а органы будут знать что к вам только с законными требованиями идти.

И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?

По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
Подчеркну, что я не юрист, и сейчас буду говорить исключительно от своего имени.

1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.

2. Яндекс юридически и фактически — российская компания.
2. — Весьма странно, помниться я читал, что компания юридически не в России зарегистрирована.

Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
На мой взгляд — потому, что мы из России и хотим жить и работать в России :)

Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
Жить и работать можно в России, а сервера (основные) и вообще всё декларировать как зарубежная фирма, в ООО же — ничего не держать
UFO just landed and posted this here
Не получите, и вы ничего не сделаете, потому, что вы боитесь потерять бизнес что вполне логично.

Если бы вы хотели что-то сделать, то вы могли вывести людей на улицу устроить движуху и правильно просвещать людей о том, что творит наше государство.

Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)

И получить блокировку на уровне магистральных провайдеров. Да даже без блокировки невыполнение российских законов означает лишение возможности вести бизнес в России. Поисковиком и почтой люди смогут продолжать пользоваться, если не будет блокировки, а вот деньги получать с российских рекламодателей будет затруднительно, даже если валютные переводы не будут отклоняться, а это, вроде как, основной источник доходов.
Содержание писем мы можем раскрывать только по санкции суда

Так значит все-таки можете? В опжу тогда такие криптографии!
Таких, кто может не раскрыть содержание письма даже по санкции суда, не бывает, увы. Это требование закона (не только в России).
Шифруйте свои письма открытым ключом получателя и только он сможет их раскрыть. SSL/TLS предназначены для защиты от негласной прослушки (и вторжения) каналов передачи, а не хранящихся данных.
Ок, понял, был неправ. Как верно ответили ниже, защита от ФСБ/АНБ/etc — «дело рук самих утопающих». И для полного «end-to-end» шифрования почты нужно использовать GnuPG.
GnuPG — лишь реализация PGP.

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

Кроме GnuPG есть и другие средства. Тут главное как ключи согласовывать с получателем.
> придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.

Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
Да это понятно всё, это конечно великолепно, но нет ничего хуже чем иллюзия безопасности.
Хмм, какая иллюзия? От хацкеров благодаря такому я, в какой-то степени, в большей безопасности. А государственным органам проще меня IRL достать, если вдруг понадоблюсь.

Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.

И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
Когда я говорю про иллюзию безопасности, то я имею ввиду такие продукты как Bittorrent Sync — теоретически он безопасен, а на практике? — никто исходников не видел.

Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.


Зачастую такой троллинг может дорого обойтись, вплоть до ареста.
Только по решению суда.

Проще ВНЕЗАПНО найти детский прон на серверах и заблокировать по IP.
Что значит «только»? Думаете это кого-то утешит, если состав ст. 310 УК РФ налицо даже для самого объективного суда?
Я выше писал, что следует не быть русской компанией
Не имеет значение, если находиться в России физически. Да и не находясь есть нюансы типа договоров о выдаче преступников.
Где-то читал, про передачу зашифрованных сообщений в комментариях на YouTube. Сообщения шифруются одноразовыми криптоблокнотами и просто выкладываются в общий доступ. Прелесть же!
А как они блокнотики получают?
Ага, и удаляются первым же модератором, увидевшим такое вот счастье…
https для соединения с абонентом — и так уже фактически стандарт, тут нечем хвастаться.
Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
Вы не очень внимательно прочитали пост. Речь не о https до пользователя, а о шифровании писем между почтовыми системами. И это пока, к сожалению, совсем не стандарт.

Например, только около 30% почтовых систем, с которыми ведут переписку наши пользователи, такое шифрование поддерживают.
Круто. А какие ещё сервисы (из популярных) кроме GMail поддерживают шифрование?
Причем тут https? Разговор идет же о шифровании между серверами, а не между пользователями и сервером.
Прошу прощения, значит я не понял сути вопроса.
Например, Facebook умеет отправлять уведомления на почту с поддержкой шифрования.
Автор, чтож ты ничего не рассказал про структуру 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

Фактически вопрос доверия в данном случае решается на уровне приложения, функции аутентификации TLS не используются.
А на токене можно ключ хранить?
Давно пора, тем более, что там работы совсем немного.
Ребят, ценность этого шифрования близка или равна нулю. Нарисуйте там чёрного человечка, между красным человечком и синим, и поймете почему.

1) Магистральному провайдеру достаточно встать MITM-ом и для отдавать smtp Яндекса фейковые пакетики что удалённый MX не умеет STARTTLS, и всё. Что вы почту доставлять не будете? Да нет, вы просто пойдёте по старинке, plain-text-ом.

2) Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI) или каким-нибудь маленьким доверенным CA. И тем более, SSL никоим образом не спасает в этом месте от всяких там PКISM и прочих америкосов, кто имеет доступ внутрь больших корневых CA.

Вобщем байки это всё, с человечками :)
UFO just landed and posted this here
Привет Вов. Очень внимательно слежу, скучаю ведь :)
Сertificate pinning(если он реализован конечно и вы действительно запоминаете issuer-ов для всех возможных MX) решает не все проблемы.
Действительно, с Intermediate CA проблем не будет, но это не решает проблемы с потенциальным доступом АНБ к корневым сертификатам, например.

Или с тем, что многие MX могут внезапно перевыпустить свой сертификат, уже через другого CA.
И кстати именно по этой причине, в современные браузеры certificate pinning не встроен, т.к. процент false positive у него неимоверно высок.

Крупные вендоры могут договориться, да, но что делать остальным?

И ты не ответил про блокировку STARTTLS ;) Что будет, если DPI у магистральщика будет «отменять TLS», провоцируя downgrade до plaintext? Не можете же вы не доставлять письма.
UFO just landed and posted this here
Ну так вопрос-то остался без ответа: да, вы заметите, что Google внезапно перестал предлагать STARTTLS (а раньше предлагал, сертификат был выдан вот этим CA). Ну или внезапно предъявил сертификат от Komodo (вместо Geotrust через свой промежуточный).

И что, откажетесь доставлять почту в этом случае?
UFO just landed and posted this here
Представляю себе, насколько усложнится smtp-клиент, передающий почту другим серверам. Ему придётся как минимум знать, что есть «другие каналы»…
А если добавить в стандарт DMARC политику шифрования. Типа наша почта только с DKIM и шифрованная, иначе реджект.
> Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI)

Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
Встать MITM-ом и пассивно прослушать стоит разных усилий.

Привет :)
UFO just landed and posted this here
Только смысл от всего этого, если вы банально игнорируете добавление двухэтапной аутентификации?
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
Facebook свободно показывает профиль, зарегистрированные на определённый email, если ввести этот email в поиск самого Facebook. Но запретить показывать свой портрет в Яндекс.Почте можно по инструкциям на странице help.yandex.ru/mail/abook.xml#social-profiles
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.


Но все-таки еще жалеете?
Когда даю свою почту каком-нибудь гику, то вижу явное пренебрежение на лице, например.
Привет Эдварду следовало бы заключить в тег , вы не находите? Он ведь показал, что АНБ не дураки и врезались на участке Гугл-Гугл, где трафик нешифрованный. Рассказали бы, если можно, как у вас с этим дело обстоит. Все сервера в Москве или есть региональные датацентры?
Черт, и я на это попался, хоть думал об этом прямо во время написания :)
«в тег sarcasm» — следует читать.
UFO just landed and posted this here
Ограничение связано с тем, что логин в Яндексе используется в очень различных сервисах и протоколах, каждый из которых в своё время накладывал на пароль свои ограничения как по длине, так и по содержанию. Когда мы убедимся, что ни одна часть за логином не пострадает от расширения набора символов и длины пароля, мы, скорее всего, изменим существующие ограничения.
Ещё одни распространенным протоколом, где регулярно используется STARTTLS, является LDAP.
Спасибо, интересно.
Немного не по теме вопрос, но всё-же: у меня есть проектик мелкий связанный с электронной почтой и там используется свой 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) всё проходит с первого раза.
Это нормальное поведение и просто нужно продолжать попытки или всё-же где то закрался баг?
Это банальный грейлистинг. Скорее всего вы просто недостаточно аутентифитировали свой релей. Стоит начать со следующих ключевых слов: PTR, SPF, DKIM, DMARC.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
А, в смысле «спамеры не будут делать много попыток отправить письмо, а легальным сервисам хочешь-не-хочешь а нужно». Что то такое читал…

SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
PTR как раз получится настроить. Никто же не требует, чтобы почта с user@domain.ru уходила обязательно с хоста в domain.ru.

Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
Грейлистинг — бессмысленная технология IMHO. Сделана в надежде, что «спаммеры так не умеют» и «у них машинки слабенькие». Оба тезиса неверны.
Не совсем так. Самое главное в грейлистинге это проверка засылающей стороны а) на реализацию корректной обработки ошибок и б) на корректную реализацию очереди с рекомендуемыми в RFC таймаутами. Т.е убеждение, как одна из ряда проверок, что перед нами какой-никакой MTA. Я не фанат данной технологии, но по информации оно срезает от 10% до 50% спама в зависимости от того в какие спам базы вы попали :)
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Оказалось, что всё намного проще. После экспериментов заметил, что у меня в EHLO подставлялся не реальный домен сервиса а локальный хостнейм из /etc/hostname
После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
UFO just landed and posted this here
Кстати, правильно я понимаю, что 465 порт сразу ssl соединение, а 587 Submission?
Вот лет 15 назад это было ново :)

Новость — отличная, что ни говори!
За что минусуете? Новость и правда отличная, а что вводят сейчас, а не 5, а то и 10 лет назад — да, не очень рано, но тоже понять можно, зашифровать такое число соединений и такой трафик тоже немало ресурсов кушает.
Вопрос на засыпку: а клиентское шифрование собираетесь поддерживать, чтобы даже вы не знали текста письма? Хотя, конечно, Директ…
Если Яндекс не будет знать о содержимом письма, то как он сможет его отдавать по IMAP/POP3, отсылать на другие сервера получателям?
Расшифровывать на стороне клиента, используя что-то вроде реализации PGP на Javascript.

Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
Там другие проблемы возникают.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.

т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
Как раз JS в браузере — отличное клиентское приложение. Например, все плагины в Fx и есть JS.

Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
То что плагины ФФ пишутся на JS(XUL) это понятно, но свои внутренние данные они хранят на диске в надёжном пользовательском профиле, а не в куках или некоем ненадёжном localstorage.

Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
А чем это отличается от, например, удаления профиля? Тоже же можно. А ещё винт может посыпаться.

Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
Отличается тем, что в случае с плагином ты можешь заставить пользователя сохранить свой ключик где-нибудь в надёжном месте, а в случае с JS и localstorage уже нет :)

И в случае с плагином никак не получится заставить. Он всегда, например, сможет «сохранить и потом стереть».

Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.

Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
UFO just landed and posted this here
UFO just landed and posted this here
Почему не подходит? Ключ вполне представим в виде строки. Реализовать RSA и AES на Javascript можно. Чего не хватает?
UFO just landed and posted this here
Технически это возможно. Да, Кэп, Идея глупая (с точки зрения безопасности), но точно реализуемая.

Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.

UFO just landed and posted this here
Я, конечно, прошу прощения, но браузеров, умеющих получать почту по POP3/IMAP и затем исполняющих полученный с сервера JS для обратоки писем, не бывает.
И я правильно понял, что вы не хотите доверять серверу яндекса открытый текст сообщения, но с радостью доверите его коду, который передается в браузер с сервера яндекса и может измениться в любой момент?
Это то же самое, что доверять, скажем, операционной системе Windows. Всё равно всё может измениться в произвольный момент — пришло обновление, которое ставится принудительно вне зависимости от настроек обновлений — и привет.
Какой-то витиеватый ответ на вопрос. :)
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
Если витьеватый ответ, то — я вообще-то не доверяю Windows и не использую её ;)

А если серьёзно, то нет, я не буду доверять. Я не буду вообще доверять это никому в «обычном» интернете.
UFO just landed and posted this here
в «отправленных» оно сохраняется уже в зашифрованном виде. Причём так, что я сам по идее не способен расшифровать: для этого нужен приватный ключ адресата, которого у меня естественно нет
UFO just landed and posted this here
Можно шифровать и на свой ключ тоже, как вариант.
А зачем для этого ему знать содержимое? Вот я сейчас отправляю шифрованные (шифрую в консоли и копипащу в веб-интерфейс) письма и нормально доходят.
И как он будет определять спам?
По содержимому — никак. Ему будет доступно некоторое количество метаданных (например, заголовки).

Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
Не понимаю почему это не было включено с самого начала? Не хватало серверных мощностей?
А ни у кого последние 3 дня проблем с отправкой через smtp не возникает?

Подключена Яндекс.Почта для домена. Больше года всё работало без проблем. С 7-ого появились задержки в получении почты адресатом, письма (на gmail) приходили с опозданием в 5-10 минут, потом вовсе перестало что либо приходить. 9-ого в обед вывалилось всё, что застряло с 7-ого. А сегодня частенько «Send AUTH command first» и «Sender address rejected: not owned by auth user» на пустом месте для приблизительно 1 письма из 10.

Кто виноват и что делать?
Авторизируюсь на smtp.yandex.ru на 465 порт с ssl. Пробовал 587, tls — не помогло.
UFO just landed and posted this here
Было сделано в первую очередь, однако ответ задерживается. Хотелось бы получить больше информации и не только от саппорта, поэтому и написал сюда.
а без SSL работать можно или для него порты принудительно убрали?
Если речь про POP, IMAP и SMTP, то работать без SSL больше нельзя. На MX и отправляющих серверах пока ещё некоторые письма принимаются и отправляются без SSL, потому что не все почтовые службы поддерживают работу по SSL в этом месте. Но вообще работа без шифрования — это снижение безопасности информации, поэтому Яндекс.Почта старается безальтернативно переходить на SSL.
Sign up to leave a comment.