1.1, Аноним (-), 14:46, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> Google, Yahoo, Comcast, Microsoft и LinkedIn.
собрались главные велосипедостроители и решили замутить очередной костыль
| |
|
2.5, Аноним (-), 15:50, 21/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нет, главные знатоки, как другим жить, с кем говорить и о чем
| |
|
3.6, Нимано (?), 16:10, 21/03/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Нет, главные знатоки, как другим жить, с кем говорить и о чем
А так же каким ДЕ, браузером, плагинами к нему, версией ядра и системой инициализации пользоваться. Только я не понял, к чему тут опеннетчиков упоминать? o_O
| |
|
|
1.2, Аноним (-), 15:04, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Непонятно нихрена. Если у меня постфикс работает только через starttls, накой эта хрень нужна?
| |
|
2.3, Moomintroll (ok), 15:15, 21/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
The STARTTLS extension to SMTP [@!RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. In its current form, however, it fails to provide (a) message confidentiality — because opportunistic STARTTLS is subject to downgrade attacks — and (b) server authenticity — because the trust relationship from email domain to MTA server identity is not cryptographically validated.
While such "opportunistic" encryption protocols provide a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform such a downgrade or interception attack.
Ну и далее по тексту: https://github.com/mrisher/smtp-sts/blob/master/spec.md
| |
|
3.8, Sw00p aka Jerom (?), 17:05, 21/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
>>any attacker who can delete parts of the SMTP session
ну пусть человек по середине удаляет 250 STARTTLS - постфикст не примет соединение если стоит smtpd_tls_security_level = encrypt
| |
|
4.14, None (??), 20:58, 21/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну решишь ты эту задачу одним параметром в конфиге и что?
А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...
| |
|
5.19, Sw00p aka Jerom (?), 17:49, 22/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
> А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...
Новый протокол ? да я только рад этому, и давно нуно списать смтп на покой. в место того чтобы толкать эту фигню - лучше бы дейн тлс продвигали бы. днссек поголовно имплементировали бы.
| |
|
6.21, . (?), 05:59, 23/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Му-ха-ха :-) Д***л, smtp никто не трогает. Они упорядочили танцы вокруг starttls и всио, мучайсо! :-р
| |
|
7.22, Sw00p aka Jerom (?), 15:30, 23/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Они упорядочили танцы вокруг starttls
а тут по подробонее, что это там упорядочили?
>>Д***л, smtp никто не трогает.
взаимно Д***б
| |
|
|
|
4.17, Аноним (-), 08:28, 22/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
никто не запретит быть шифрованному каналу от тебя до этого типа, а от типа до отправителя - не шифрованному.
| |
|
5.18, Sw00p aka Jerom (?), 17:47, 22/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
smtp_tls_security_level = verify
какая разница, суть в том, что отправитель должен верефицировать получателя
принимать и отправлять только по тлс - вырезай не вырезай start tls - без установки тлс ничего не приментся и не отправится.
| |
|
|
|
|
1.7, Sailfish (ok), 16:55, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Для веба, несомненно, актуальнее. Но почему бы и нет.
А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо -- даёт некую гарантию, что один и тот же стандарт будут использовать все вместо кучи вендорных расширений протокола.
| |
|
|
|
4.13, Аноним (-), 18:01, 21/03/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Ну, уж они-то хотя бы будут следовать, раз сами договорились? :-)
Микрософт будет следовать чему-то кроме того, что шепчут ему грибы?
| |
|
|
2.15, None (??), 21:04, 21/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Для веба, несомненно, актуальнее. Но почему бы и нет.
> А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо --
> даёт некую гарантию, что один и тот же стандарт будут использовать
> все вместо кучи вендорных расширений протокола.
Я так понимаю, всё идёт к тому, что без валидного сертификата отправить что либо на @gmail.com и т.п. нельзя будет.
| |
|
3.24, scorry (ok), 12:27, 24/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать, что получение валидного сертификата сейчас составляет какую-то трудность.
| |
|
2.16, Ан (??), 21:30, 21/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
То что тут пытаются что-то стандартизировать не даст ровным счётом ничего. В почтовых серверах полно своих особенностей у всех вендоров.
А как показала история на примере OpenGL даже 1 стандарт не гарантирует того что каждый вендор не будет тянуть одеяло на свою половину.
Хорошо конечно что эти гиганты договариваются, но остальным от этого ни холодно ни жарко.
| |
|
3.25, scorry (ok), 12:30, 24/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
> В почтовых серверах полно своих особенностей у всех вендоров.
> А как показала история на примере OpenGL даже 1 стандарт не гарантирует
> того что каждый вендор не будет тянуть одеяло на свою половину.
Как только с особенного сервера перестанет доходить почта до другого, не особенного, админы со скоростью, превышающей световую, понесутся исправлять неисправленное. Причём помогать им будет пистон полуметровой, как минимум, длины, вставленный в необходимое технологическое отверстие кем-то вроде CTO или CEO.
| |
|
|
|
2.26, Онаним (?), 20:18, 25/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
В принципе да (для клиент-серверного общения я бы вообще оставил только IMAP - пусть бы клиент просто клал исходящую почту в специальную Outbox-папку и никаких SMTP ему не надо), но учитывая уровень кривизны и разнообразие реализации того же IMAP в разных клиентах, на практике я до сих пор предпочитаю использовать POP3 там где это уместно.
| |
|
|