Вы будете смеяться, но у сильно рекламируемого в последнее время NordVPN корпоративная почта хостится на Gmail. Доверять такому провайдеру я бы поостерёгся.
Я лично и многие знакомые уже много лет пользуемся PureVPN, который себя отлично зарекомендовал и пользуется популярностью.
Но, я забыл добавить, что для злонамеренных отправителей, которые, обычно, используют специальные скрипты и особым образом сконфигурированные SMTP-серверы это не поможет.
Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.
Соглашусь.
На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.
На самом деле НСНРП точно такая же левая партия, как и ВКП(б). Но в советской политической науке и историографии её искусственно и по понятным причинам причислили к правому спектру.
Они хотят быть уверенными, что в случае необходимости смогут получить доступ к шифрованной информации. Например, если устройство имеет реализацию своего протокола шифрования, то оно должно предоставить бэкдор, ключи доступа или согласиться сотрудничать с органами. Те, кто отказывается, нотификацию не получают. К примеру, как это было в своё время с Blackberry OS 10.
Вы так пишете, будто бы речь идёт не о России, а о демократическом государстве…
Но в одном вы правы — нужны не поиски обходов системы, а изменение самой системы с тем, чтобы обходить её не было нужды.
Типовая норма прибыли в автомобильной промышленности в районе 7%, так что 70-80% себестоимости (надеюсь, речь и идёт о полной) это просто фантастически хорошо.
На DNS весь интернет завязан, так что это данность. Главная же проблема с ним на сегодня это то, что весь DNS-трафик передаётся в открытом виде что на общем фоне выглядит как неприемлемый анахронизм. Несмотря на наличие стандарта DNS-over-TLS и наличие его поддержки в основном серверном софте активности во внедрении шифрования DNS-трафика как-то не наблюдается.
dnscrypt как и стандартизированный DNS-over-TLS шифрует сам трафик, что не заменяет механизма цифровых подписей DNSSEC. И если последний в последнее время стал получать активное распространение, то первые два ещё крайне далеки от этого.
CAA не решает вопрос доверия вообще ни разу, однако существенно ограничивает возможность выпуска сертификата неавторизованным через неё CA.
Решение на сегодня это DANE. Однако, производители прикладного софта её внедрять не спешат.
По поводу блокчейн. Я вижу, что большинство вообще не понимает что это, для чего её целесообразно использовать и, тем более, как он работает. В большинстве случаев, в частности и этом, блокчейн не нужен, поскольку вполне достаточно куда менее сложных и затратных способов реализации. Это, к примеру, цифровые подписи которые с успехов функционируют в рамках даже такой не слишком складно спроектированной системы, как DNSSEC.
Все эти CA "черти" могут выпустить другой сертификат не отозвав оригинальный, по умыслу или случайно. И это уже было, в том числе и с "хорошими" CA. Иными словами, вся система имеет фундаментальную уязвимость, поскольку построена на доверии к сторонней организации.
Вы будете смеяться, но у сильно рекламируемого в последнее время NordVPN корпоративная почта хостится на Gmail. Доверять такому провайдеру я бы поостерёгся.
Я лично и многие знакомые уже много лет пользуемся PureVPN, который себя отлично зарекомендовал и пользуется популярностью.
Напишите, конечно. И про открытие фирмы через электронное гражданство со всеми вытекающими вопросами.
Но, я забыл добавить, что для злонамеренных отправителей, которые, обычно, используют специальные скрипты и особым образом сконфигурированные SMTP-серверы это не поможет.
Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.
Соглашусь.
На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.
+1
Но требует квалификации.
На самом деле НСНРП точно такая же левая партия, как и ВКП(б). Но в советской политической науке и историографии её искусственно и по понятным причинам причислили к правому спектру.
none
Они хотят быть уверенными, что в случае необходимости смогут получить доступ к шифрованной информации. Например, если устройство имеет реализацию своего протокола шифрования, то оно должно предоставить бэкдор, ключи доступа или согласиться сотрудничать с органами. Те, кто отказывается, нотификацию не получают. К примеру, как это было в своё время с Blackberry OS 10.
Вы так пишете, будто бы речь идёт не о России, а о демократическом государстве…
Но в одном вы правы — нужны не поиски обходов системы, а изменение самой системы с тем, чтобы обходить её не было нужды.
Давно. Наличие слов "шифрование", "криптография" и "wi-fi" в спецификации может (и часто возбуждает) подобный интерес у таможенников.
Ну а я на Model S и Leaf. Действительно, разница колоссальная :-)
Электро-калина уже давно есть. Она называется Nissan Leaf
Разумеется.
И это верно, однако тут есть DANE, что замыкает проблему на саму же DNS.
Типовая норма прибыли в автомобильной промышленности в районе 7%, так что 70-80% себестоимости (надеюсь, речь и идёт о полной) это просто фантастически хорошо.
На DNS весь интернет завязан, так что это данность. Главная же проблема с ним на сегодня это то, что весь DNS-трафик передаётся в открытом виде что на общем фоне выглядит как неприемлемый анахронизм. Несмотря на наличие стандарта DNS-over-TLS и наличие его поддержки в основном серверном софте активности во внедрении шифрования DNS-трафика как-то не наблюдается.
dnscrypt как и стандартизированный DNS-over-TLS шифрует сам трафик, что не заменяет механизма цифровых подписей DNSSEC. И если последний в последнее время стал получать активное распространение, то первые два ещё крайне далеки от этого.
Ну я бы не был так категоричен. Например, DNSSEС имеет таковую, однако используя DANE вопрос с доверием к сертификату вполне себе решается.
CAA не решает вопрос доверия вообще ни разу, однако существенно ограничивает возможность выпуска сертификата неавторизованным через неё CA.
Решение на сегодня это DANE. Однако, производители прикладного софта её внедрять не спешат.
По поводу блокчейн. Я вижу, что большинство вообще не понимает что это, для чего её целесообразно использовать и, тем более, как он работает. В большинстве случаев, в частности и этом, блокчейн не нужен, поскольку вполне достаточно куда менее сложных и затратных способов реализации. Это, к примеру, цифровые подписи которые с успехов функционируют в рамках даже такой не слишком складно спроектированной системы, как DNSSEC.
Все эти CA "черти" могут выпустить другой сертификат не отозвав оригинальный, по умыслу или случайно. И это уже было, в том числе и с "хорошими" CA. Иными словами, вся система имеет фундаментальную уязвимость, поскольку построена на доверии к сторонней организации.