Comments 31

Почитайте RFC 5737, 3849. Не очень удобно читать howto, когда ip-адреса имеют вид xx.xx.xx.xx
Зря вы добавили openvpn в статью. К почте он отношения не имеет. В итоге получалась какая-то каша из настройки маршрутизации, vpn-а и почты. Хотя бы пометьте какие настройки не нужны, если не нужен vpn.

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

Почему я решил включить openvpn? Потому что в РФ нет возможности получить IPv6 без проблем на конечную машину. А как тестировать IPv6 без openvpn в такой ситуации? Никак. Потому и включил его в статью.

Спасибо за ссылки на RFC.

Просто писать про vpn в статье про почту это жуткий оверкилл.
В РФ нативно даёт Эртелеком и МТС (на мобильной сети), т.е. получить нативный ipv6 не так уж и сложно.
Ну ладно, допустим у вашего isp его нет. Но есть же туннельные брокеры https://en.m.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers (для тестов это более чем достаточно)
Допустим, по какой-то причине и это не вариант. Тогда берёте самую дешёвую vps под это дело (рекомендую использовать lowendbox/lowendtalk для поиска) и тестирует с неё, а то у вас даже тест не совсем честный, по сути внутри хоста тестируете часть вещей.

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

Собственный почтовый сервер имеет смысл ставить в корпоративных целях. Или когда вам катастрофически важна гарантия доставки писем и/или максимальный антиспам рейтинг.

Это всё до первого ддос и прочих атак, а потом вы начинаете прятаться за антиддос сервис (что вносит огромные коррективы ко всей схеме) или уходите на публичные провайдеры типа Microsoft (office365)

Вот меня удивляет, что люди в 2019 году, по-прежнему, запускают сервисы не в docker/kuberntes
Все люди разные. Некоторым нужны безопасность, стабильность, надёжность и производительность, которых Docker с его тысячами открытых issues предоставить не может. А ещё некторые понимают, что Docker — средство доставки приложений. Если ваш стартап выкатывает новую версию сервиса 2 раза в неделю, Docker незаменим. Если вы поднимаете почтовый сервак, который будет работать годами Docker вообще ни к чему.

Помимо всего, что уже написали, работать с Docker банально менее удобно. И непонятно зачем добавлять лишние сущности и уровни абстракции в данном конкретном случае. Кроме лишней возни это ничего не добавит.


Ну и бонусом идет, например, невозможность безопасной настройки LetsEncrypt в докере. Все решения, которые я видел, реализованы с открытием лазейки позволяющей выходить за пределы контейнера.

А это самое интересное. Это возможность отправлять письма для конкретного домена с конкретного IPv4/IPv6 адреса.

Если helo не соответствует домену почты, от имени кого отправили письмо — начисляются спам очки.

Сколько можно распространять по интернету эту глупость?
Кто-то один раз где-то это написал, и теперь каждый натыкающийся на эту "кладезь мудрости" старается внедрить её у себя и рассказать миру об этом достижении.


HELO не обязано соответствовать домену адреса отправителя, и никакие известные мне почтовые антиспамы за это штрафные баллы не начисляют.


Соответственно для каждого домена должен быть свой IP адрес.

Такого требования также нет.

Почтовые сервера на outlook.com всегда делают bounce письмам отправленным с сервера, у которого неправильный HELO.
spamassassin, который установлен у многих почтовых серверов, по умолчанию даёт 1.6 очков спама на неправильный HELO.

Так-то да, если вам не важно попадёт письмо в спам или нет — то на HELO можно не обращать внимание.
Вы путаете «неправильный» адрес в HELO (который не соответствует прямому и обратному DNS) и то, что у автора статьи — «helo не соответствует домену почты, от имени кого отправили письмо». Последнее — выдумка, потому что тот же outlook.com шлёт почту от имени тысяч доменов, нет и не может быть такого ограничения. Соответствие записям SPF/DMARC домена-отправителя могут проверяться, а сравнивать домен одного из почтовых серверов в цепочке почему-то с адресом FROM в письме, я не знаю, кому в голову может прийти такая идея, видимо это urban legend.
UFO landed and left these words here
Вместо связки OpenDKIM + SpamAssasin не смотрели в сторону Rspamd? Шустрый, работает «из коробки» с минимальными настройками.
Также хотелось бы получить отзывы на тему идеи про почтовые сертификаты. Если идея понравится — постараюсь найти силы написать черновик для rfc.

Его уже написали, одобрили и чёрт знает сколько лет успешно используют: tools.ietf.org/html/rfc4880
Я в курсе про PGP. Но пользоваться им неудобно, уж простите.

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

Это кроме параноиков или людей занимающихся не совсем законной деятельностью нафиг никому не надо. А кому надо тот и PGP освоит.

image

PGP за почти 3 десятка лет существования не получил распространения среди всех существующих почтовых клиентов ( хотя на мой взгляд в Evolution или Thunderbird пользоваться им достаточно легко ), а вы надеетесь вот так просто взять и договориться с Microsoft, Google, IBM, Apple и кучей компаний поменьше? Да вам сказки надо писать, а не RFC.
> Только спустя 8 лет после начала моей карьеры я стал понимать как работает SSL.
>…
> Веб сервер отдаёт публичный ключ. Браузер используя публичный ключ зашифровывает
> http-request и отправляет его.

8 лет оказалось недостаточно.
Всё не так. Эта ваша желтая секция про HTTPS содержит набор ереси. Там просто через сстрочку можно писать ответ «это не так, читайте вики.»

> Браузер используя публичный ключ зашифровывает http-request и отправляет его.
Это не так, читайте вики: TLS.

> если в стране пытаются ограничить доступ не ко всему сайту,
> а к конкретной странице — то для https сайтов это сделать невозможно.
Очень даже возможно. Для этого государству надо либо вступить в сговор с CA (wiki: StartCom), либо самому стать CA ( habr.com/ru/post/272207 ), либо заюзать что-то типа Carnivore или NarusInsight (но это не точно, агентство которого нет всё отрицает а вики врет). Хотя, если вы король какой-нибудь банановой республики или царек в Рога и Копыта Интернешнл, то вы можете так не заморачиваться а просто связаться с Symantec Solutions и они вам помогут с перехватом HTTPS трафика всех этих ваших холопов.

> браузер у себя локально формирует такую-же пару приватный-публичный ключ
> для каждого https сайта
Не фомирует браузер никакую такую пару ключей.

> И вместе с запросом публичного ключа сайта отправляет свой локальный публичный ключ.
wiki: TLS. Ну или вы неправильно поняли аутентификацию по сертификатам, которая к тому же на публичных сайтах всё равно не применяется.

> http-response шифрует этим вот публичным ключём конкретного клиента.
wiki: TLS, сеансовый ключ там используется на самом деле а не публичный.

Вместо ожидаемого упоминания Диффи-Хеллмана написана какая-то ерунда.

> Само создание такого безопасного канала связи происходит со скоростью ping*2
Два пинга будет только если не учитывать TCP handshake (+1 пинг), не смотреть в CRL (много пингов), не дергать никого по OSCP (много-много пингов). Ну то есть если тупо не проверять совсем ничего и всегда слепо доверять всем без разбору — тогда да, парой-тройкой пингов можно обойтись. Хотя OCSP stapling устраняет эти вот многочисленные лишние пинги. Но его используют только 30% хостов примерно, а у вас он так и вообще не упомянут.

> Для борьбы с такими злоумышленниками придумали публичную БД
> с публичными ключами для каждого https сайта.
Вы, наверное, CA имели в виду. Там у них нет никакой публичной базы публичных ключей. Если CRL — публичные списки отозванных сертификатов — то есть таких, которые раньше можно было использовать а теперь нельзя. Есть OSCP, но это запрос-ответ а не скачивание базы чего-либо.

> Ещё добавлю про ssh соединения. Там никаких публичных ключей нет.
Да ну?

> При первом соединении ssh-клиент должен предупредить, что тут у нас новый публичный ключ.
Вы же только что написали, что никаких публичных ключей нет.

> Через пару часов мы получаем от этой сторонней компании наш «публичный» ключ и ещё набор нескольких публичных ключей.
Сертификат вы оттуда получаете подписанный а вовсе не ключ. Это разные вещи.

> chained — обозначение, что тут цепочка публичных ключей
Цепочка сертификатов. Не бывает никаких цепочек ключей в природе.

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

Ваша статья требует полной переработки, с учетом вышеизложенных в комментариях замечаний. Несмотря на наличие этих замечаний, никаких изменений в содержимое статьи Вами не внесено, и она продолжает нести в массы дезинформацию и неверные тезисы.


Я бы попросил Вас скрыть её в черновики до момента переработки содержимого.
Вы уже получили много отзывов и Вам есть над чем подумать.

А где ansible-плейбук? Или вы руками предлагаете все это натыкивать во второй раз. Сейчас 2k19 на минуточку, без плейбука зачет не приму!

Если уж включать spam паранойю, то я бы добавил еще:


  • поддержку DMARC и ARC
  • дополнительные и/или свои блеклисты (это отсылка к строке reject_rbl_client sbl.spamhaus.org,)
  • например fail2ban с реакцией на логи postfix о несовпадении hostname<->rDNS, невалидные сертификаты, оборванные входящие TLS/SSL сессии

Ну и плюсую за OpenPGP aka RFC4880

UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.