Comments 149
Казалось бы, причем здесь Pink Floyd?
Мне кажется, что суть в том, что на картинке изображена призма (PRISM). А Пинк Флойд не при чем )
Вот именно. Больше к сжатию подходит картинка, а не к шифрованию.
en.wikipedia.org/wiki/File:PRISM_logo_(PNG).png
SSL.no — это mail.ru?
И, кстати, на почте для доменов это тоже работает?
И, кстати, на почте для доменов это тоже работает?
Да, письма Почты для доменов принимаются и отправляются с тех же серверов, что и письма простой Яндекс.Почты.
А какой в этом случае подключающемуся серверу предъявляется сертификат? Нужно ли мне, как владельцу домена, предоставлять SSL-сертификат в ПДД?
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% уставного капитала юридически сосредоточено за пределами РФ.
Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
67% акций торгуется на иностранных биржах, 100% уставного капитала юридически сосредоточено за пределами РФ.
Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
При всем уважении к этому замечательному человеку, как эти слова можно подкрепить юридически?
Да, эта компания была основана на российские деньги, русским людьми.
Но инвесторы иностранные. И деньги на развитие иностранные.
То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
Да, эта компания была основана на российские деньги, русским людьми.
Но инвесторы иностранные. И деньги на развитие иностранные.
То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
На иностранных биржах торгуются акции Yandex NV. Ей принадлежит полностью российское ООО Яндекс. Которая и осуществляет всю деятельность.
Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
Зарегистрирована в России, налоги платит в России, подавляющее большинство имущества находится в России, подавляющее число работников тоже. Кто владеет компанией дело десятое — это лишь вопрос распределения прибылей.
И вы путаете ООО «Яндекс» и Yandex N.V. ООО «Яндекс» — российская компания, основной капитал которой находится в России (тут же был оплачен уставной). 67% акций торгуется у Yandex N.V., которая является владельцем российского ООО.
Нет, использование не требует.
Вот что говорят наши юристы по этому вопросу:
Вот что говорят наши юристы по этому вопросу:
Яндекс не разрабатывает и не применяет собственные технические средства защиты информации, в том числе криптографические, и на него не возложена обязанность по сертификации таких средств или по лицензированию компании в качестве их разработчика. Техническое обслуживание таких средств для обеспечения собственных нужд компании и с учетом примененных в проекте технических решений, по указанию Постановления Правительства РФ от 16.04.2012 N 313 и смежных актов, также не является лицензируемой деятельностью.
Но у вас не собственные нужды, вы предоставляете сервис.
К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;
www.consultant.ru/document/cons_doc_LAW_128739/
© КонсультантПлюс, 1992-2013
Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;
www.consultant.ru/document/cons_doc_LAW_128739/
© КонсультантПлюс, 1992-2013
Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
Вот всегда интересовал вопрос: поднимаю я на собственном сервере https для публичного доступа. Имхо, это уже не внутренние нужды, а предоставление сервиса с использованием криптографии. Как ваши юристы ответят на подобные претензии со стороны контролеров?
Мне тоже интересно это узнать.
На сегодня все решается выводом сервера с сайтом за пределы РФ.
При трансграничной передаче шифровать ГОСТом ФСБ не требует.
На сегодня все решается выводом сервера с сайтом за пределы РФ.
При трансграничной передаче шифровать ГОСТом ФСБ не требует.
Это всё конечно круто, но если вам т.е Яндексу придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
Содержание писем мы можем раскрывать только по санкции суда.
Было бы великолепно если бы вы все обращения (кроме тех которые через суд) публиковали на отдельной странице — как это делает TPB, таким образом вы ничего не нарушаете а органы будут знать что к вам только с законными требованиями идти.
И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?
По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?
По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
Подчеркну, что я не юрист, и сейчас буду говорить исключительно от своего имени.
1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.
2. Яндекс юридически и фактически — российская компания.
1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.
2. Яндекс юридически и фактически — российская компания.
2. — Весьма странно, помниться я читал, что компания юридически не в России зарегистрирована.
Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
На мой взгляд — потому, что мы из России и хотим жить и работать в России :)
Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
Не получите, и вы ничего не сделаете, потому, что вы боитесь потерять бизнес что вполне логично.
Если бы вы хотели что-то сделать, то вы могливывести людей на улицу устроить движуху и правильно просвещать людей о том, что творит наше государство.
Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
Если бы вы хотели что-то сделать, то вы могли
Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
(Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
И получить блокировку на уровне магистральных провайдеров. Да даже без блокировки невыполнение российских законов означает лишение возможности вести бизнес в России. Поисковиком и почтой люди смогут продолжать пользоваться, если не будет блокировки, а вот деньги получать с российских рекламодателей будет затруднительно, даже если валютные переводы не будут отклоняться, а это, вроде как, основной источник доходов.
Содержание писем мы можем раскрывать только по санкции суда
Так значит все-таки можете? В опжу тогда такие криптографии!
Таких, кто может не раскрыть содержание письма даже по санкции суда, не бывает, увы. Это требование закона (не только в России).
Шифруйте свои письма открытым ключом получателя и только он сможет их раскрыть. SSL/TLS предназначены для защиты от негласной прослушки (и вторжения) каналов передачи, а не хранящихся данных.
> придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
Да это понятно всё, это конечно великолепно, но нет ничего хуже чем иллюзия безопасности.
Хмм, какая иллюзия? От хацкеров благодаря такому я, в какой-то степени, в большей безопасности. А государственным органам проще меня IRL достать, если вдруг понадоблюсь.
Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.
И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.
И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
Когда я говорю про иллюзию безопасности, то я имею ввиду такие продукты как Bittorrent Sync — теоретически он безопасен, а на практике? — никто исходников не видел.
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
Где-то читал, про передачу зашифрованных сообщений в комментариях на YouTube. Сообщения шифруются одноразовыми криптоблокнотами и просто выкладываются в общий доступ. Прелесть же!
https для соединения с абонентом — и так уже фактически стандарт, тут нечем хвастаться.
Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
Круто. А какие ещё сервисы (из популярных) кроме GMail поддерживают шифрование?
Автор, чтож ты ничего не рассказал про структуру 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) Магистральному провайдеру достаточно встать 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.
Вобщем байки это всё, с человечками :)
Привет Вов. Очень внимательно слежу, скучаю ведь :)
С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? Не можете же вы не доставлять письма.
А если добавить в стандарт DMARC политику шифрования. Типа наша почта только с DKIM и шифрованная, иначе реджект.
> Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI)
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
Встать MITM-ом и пассивно прослушать стоит разных усилий.
Привет :)
Привет :)
в тему:
Только смысл от всего этого, если вы банально игнорируете добавление двухэтапной аутентификации?
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
Facebook свободно показывает профиль, зарегистрированные на определённый email, если ввести этот email в поиск самого Facebook. Но запретить показывать свой портрет в Яндекс.Почте можно по инструкциям на странице help.yandex.ru/mail/abook.xml#social-profiles
Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
Но все-таки еще жалеете?
Привет Эдварду следовало бы заключить в тег , вы не находите? Он ведь показал, что АНБ не дураки и врезались на участке Гугл-Гугл, где трафик нешифрованный. Рассказали бы, если можно, как у вас с этим дело обстоит. Все сервера в Москве или есть региональные датацентры?
Ограничение связано с тем, что логин в Яндексе используется в очень различных сервисах и протоколах, каждый из которых в своё время накладывал на пароль свои ограничения как по длине, так и по содержанию. Когда мы убедимся, что ни одна часть за логином не пострадает от расширения набора символов и длины пароля, мы, скорее всего, изменим существующие ограничения.
Ещё одни распространенным протоколом, где регулярно используется STARTTLS, является LDAP.
Спасибо, интересно.
Немного не по теме вопрос, но всё-же: у меня есть проектик мелкий связанный с электронной почтой и там используется свой 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) всё проходит с первого раза.
Это нормальное поведение и просто нужно продолжать попытки или всё-же где то закрался баг?
Это банальный грейлистинг. Скорее всего вы просто недостаточно аутентифитировали свой релей. Стоит начать со следующих ключевых слов: PTR, SPF, DKIM, DMARC.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
А, в смысле «спамеры не будут делать много попыток отправить письмо, а легальным сервисам хочешь-не-хочешь а нужно». Что то такое читал…
SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
PTR как раз получится настроить. Никто же не требует, чтобы почта с user@domain.ru уходила обязательно с хоста в domain.ru.
Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
Грейлистинг — бессмысленная технология IMHO. Сделана в надежде, что «спаммеры так не умеют» и «у них машинки слабенькие». Оба тезиса неверны.
Не совсем так. Самое главное в грейлистинге это проверка засылающей стороны а) на реализацию корректной обработки ошибок и б) на корректную реализацию очереди с рекомендуемыми в RFC таймаутами. Т.е убеждение, как одна из ряда проверок, что перед нами какой-никакой MTA. Я не фанат данной технологии, но по информации оно срезает от 10% до 50% спама в зависимости от того в какие спам базы вы попали :)
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
Оказалось, что всё намного проще. После экспериментов заметил, что у меня в EHLO подставлялся не реальный домен сервиса а локальный хостнейм из /etc/hostname
После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
Кстати, правильно я понимаю, что 465 порт сразу ssl соединение, а 587 Submission?
Вот лет 15 назад это было ново :)
Новость — отличная, что ни говори!
Новость — отличная, что ни говори!
За что минусуете? Новость и правда отличная, а что вводят сейчас, а не 5, а то и 10 лет назад — да, не очень рано, но тоже понять можно, зашифровать такое число соединений и такой трафик тоже немало ресурсов кушает.
news.cnet.com/8301-13578_3-57590389-38/how-web-mail-providers-leave-door-open-for-nsa-surveillance/
15 не 15, но статистика налицо.
15 не 15, но статистика налицо.
Вопрос на засыпку: а клиентское шифрование собираетесь поддерживать, чтобы даже вы не знали текста письма? Хотя, конечно, Директ…
Если Яндекс не будет знать о содержимом письма, то как он сможет его отдавать по IMAP/POP3, отсылать на другие сервера получателям?
Расшифровывать на стороне клиента, используя что-то вроде реализации PGP на Javascript.
Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
Там другие проблемы возникают.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
1) Где хранить приватный ключик юзера для расшифровки письма
2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.
т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
Как раз JS в браузере — отличное клиентское приложение. Например, все плагины в Fx и есть JS.
Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
То что плагины ФФ пишутся на JS(XUL) это понятно, но свои внутренние данные они хранят на диске в надёжном пользовательском профиле, а не в куках или некоем ненадёжном localstorage.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
А чем это отличается от, например, удаления профиля? Тоже же можно. А ещё винт может посыпаться.
Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
Отличается тем, что в случае с плагином ты можешь заставить пользователя сохранить свой ключик где-нибудь в надёжном месте, а в случае с JS и localstorage уже нет :)
И в случае с плагином никак не получится заставить. Он всегда, например, сможет «сохранить и потом стереть».
Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.
Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.
Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
например в Local Storage
Почему не подходит? Ключ вполне представим в виде строки. Реализовать RSA и AES на Javascript можно. Чего не хватает?
Технически это возможно. Да, Кэп, Идея глупая (с точки зрения безопасности), но точно реализуемая.
Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.
Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.
Я, конечно, прошу прощения, но браузеров, умеющих получать почту по POP3/IMAP и затем исполняющих полученный с сервера JS для обратоки писем, не бывает.
И я правильно понял, что вы не хотите доверять серверу яндекса открытый текст сообщения, но с радостью доверите его коду, который передается в браузер с сервера яндекса и может измениться в любой момент?
Это то же самое, что доверять, скажем, операционной системе Windows. Всё равно всё может измениться в произвольный момент — пришло обновление, которое ставится принудительно вне зависимости от настроек обновлений — и привет.
Какой-то витиеватый ответ на вопрос. :)
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
А зачем для этого ему знать содержимое? Вот я сейчас отправляю шифрованные (шифрую в консоли и копипащу в веб-интерфейс) письма и нормально доходят.
И как он будет определять спам?
По содержимому — никак. Ему будет доступно некоторое количество метаданных (например, заголовки).
Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
А ему это нужно?
Не понимаю почему это не было включено с самого начала? Не хватало серверных мощностей?
А ни у кого последние 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.
Кто виноват и что делать?
а без SSL работать можно или для него порты принудительно убрали?
Если речь про POP, IMAP и SMTP, то работать без SSL больше нельзя. На MX и отправляющих серверах пока ещё некоторые письма принимаются и отправляются без SSL, потому что не все почтовые службы поддерживают работу по SSL в этом месте. Но вообще работа без шифрования — это снижение безопасности информации, поэтому Яндекс.Почта старается безальтернативно переходить на SSL.
Sign up to leave a comment.
Яндекс теперь поддерживает шифрование исходящей и входящей почты