Теперь становится понятно, почему их сервера в Эстонии внезапно отключили под вечер 24 мая... Мне по запросу потом активировали бесплатно VPS в другой локации (не ЕС), хотя и небыстро - видимо, поддержка была завалена обращениями. И никакого письма о санкциях мне от них, к слову, не приходило - ни до отключения, ни после. А пока я жду от них подробного разбора инцидента, желательно с описанием мер, которые они планируют предпринять, чтобы избежать аналогичных ситуаций в будущем, они, оказывается, ребрендингом занимаются - о как!
К сожалению, чек не могу найти (на сайте магазина в ЛК они почему-то только до 2021 года, но, наверное, можно сделать запрос в поддержку), да и ехать в сервис лень, к тому же я уже заменил карту на новую. Если бы не нужно было менять срочно, может, и попробовал бы. Но вообще сам факт того, что они могут вот так внезапно сломаться, напрягает. Там же нет механических деталей, как в жёстком диске, которые могут отказать... хотя это мог быть какой-нибудь статический разряд, например.
Кстати, самый быстрый способ проверки конкретно Samsung'ов (надеюсь, ничего с той поры не поменялось) -- надо посмотреть на торец карты. На Samsung'ах он белого цвета. Это не даёт 100% гарантию, но так можно быстро оценить надо ли подозревать карту.
Спасибо, не знал об этом раньше. Проверил только что — торец белый.
Обычно подделывает не только бренд, но и ёмкость. Самая простая проверка -- это через h2testw.
Ёмкость я специально не тестировал, но проблем с нечитаемостью или перезатиранием данных не было, при этом использовалась более половины доступного объёма (порядка 130 ГБ, если не ошибаюсь). Сейчас по понятным причинам проверить её уже не представляется возможным, но я думаю, что с ней всё было в порядке.
К сожалению, это касается не только карт с AliExpress. Недавно у меня испортилась карточка Samsung на 256 ГБ, которую я использовал в музыкальном плеере. ЕМНИП, заказывал её на Ozon (из-за быстрой доставки) — возможно, она была поддельной, но не знаю, как это можно проверить, тем более стоила она не так дёшево, чтобы возникли подозрения по этому поводу.
Карта проработала меньше двух лет, при этом в последнее время я практически не записывал на неё никакой новой музыки, только слушал. В один прекрасный день она просто перестала отображаться в проводнике, а при попытке просмотра разделов на ней с помощью diskpart он намертво зависал. На машине с UNIX-системой лучше не стало: в лог ядра стали сыпаться ошибки «Unretryable error», любые попытки что-то прочитать вызывали сообщение «Input/output error». Сделал вывод, что восстановлению карта не подлежит.
К сожалению, примерно неделю назад снова возникла такая же проблема. Возможно, это связано с обновлением моего телефона до Android 12 (обновление официальное), но не могу быть уверен на 100%, т.к. появилось это не сразу, а через несколько дней после обновления.
Пробовал чистить кэш и данные Google Play, перезагружаться, но доходит только до того, что скачивает, но установить не может (раньше вообще не мог скачать). Хотя, судя по тому, что размер обновления — 91 КБ, это скорее всего тоже глюк, а не санкции. Интересно только, что уже прошло довольно много времени с тех пор, как он начался, но в новостях ничего по этому поводу не проскакивало, как будто это и вправду только у меня.
Можно поднять на VPN-шлюзе DNS-резолвер и использовать его с основного сервера в качестве резервного. Я так и сделал, но мне эта идея пришла в голову уже после написания статьи, и поскольку она и так получилась довольно длинной, решил не добавлять об этом упоминание. В целом, с этим всё довольно тривиально, когда туннель уже поднят. Я ставил в качестве резолвера Unbound, по нему хорошая документация на официальном сайте.
А не осилите заодно рассказать про собственный postfix и настройки? Вот сколько искал, более-менее современных и продуманных гайдов про свою почту на хабре вроде как нет. А это очень актуально, учитывая, например, принудительное закрытие гуглом Google Suite для старых пользователей.
К сожалению, у меня редко находится время и желание (особенно именно в такой комбинации) на то, чтобы что-то писать, а в ближайший месяц точно не получится. На создание этой и предыдущей статьи меня, можно сказать, вдохновили последние события, так что это скорее исключение, чем правило. Вообще, я не очень люблю этим заниматься.
Я вижу, что у вас очень много опыта (я бы например про bounce вообще не додумался, что его нужно отключать, так как сам почту никогда не поднимал), о котором я, и, думаю, многие, очень хотели бы узнать.
На самом деле не так много. Мой почтовый сервер работает чуть более полугода, и первые два месяца я практически каждый день что-то подкручивал в настройках, чтобы добиться того, чтобы всё работало именно так, как мне надо, а не как-то ещё.
Какая связка сейчас считается надежной?
Я использую Postfix + Dovecot, потому что лично мне показалось, что по этим двум программным продуктам больше всего документации. Ещё вроде бы часто используют Exim в качестве MTA и Cyrus в качестве IMAP-сервера. Но я не проводил сравнения используемого мной ПО с аналогами. Просто взял их потому, что в интерете именно по ним очень много руководств, от которых можно отталкиваться, если вообще ничего не понимаешь (а я, когда начинал настраивать, действительно мало что понимал).
Какой антиспам юзать?
Очень часто в туториалах упоминается SpamAssassin, но лично я использовал Rspamd, так как слышал, что у SpamAssassin'а могут быть проблемы с анализом писем в кодировке UTF-8. Но не могу сказать на 100%, актуальна ли данная проблема на сегодняшний день. Возможно, придётся потанцевать с бубном, чтобы её обойти. У Rspamd, с другой стороны, таких проблем нет, но и документации по нему явно меньше, как мне показалось.
Какие настройки критичны для первоначальной работоспособности, чтобы все подряд не слали твои письма в спам и чтоб самому не стать случайно спамером, как с тем же bounce; обращались ли в конторы типа Spamhaus, чтобы восстановить справедливость, или у вас теплый ламповый прогретый мейл из тех времен, когда трава была зеленее, а сервера не требовали повально DMARC и т.д.
Ранше я использовал почту для домена от Яндекса, так что домен остался. IP-адрес новый. По поводу попадания в спам лично у меня сложилось такое мнение, что даже если настроить всё абсолютно на 100% корректно, первое время всё равно такое возможно, если речь идёт об отправке почты крупным провайдерам (Gmail, Outlook etc). Складывается впечатление, что их антиспам-системы требуют какого-то минимального объёма отправляемой почты (суммарного или в единицу времени), чтобы этого избежать, но в случае с персональным сервером такие объёмы вряд ли достижимы. Однако со временем, скорее всего, ситуация наладится, особенно если просить получателей помечать ваши письма как не спам.
Самому стать спамером, если только не намеренно, возможно, если кто-то подберёт пароль к вашему аккаунту на сервере. Насколько я знаю, по умолчанию все современные почтовые сервера настроены так, чтобы не допускать пересылку писем на сторонние домены без авторизации. Также есть сервисы вроде MxToolbox, которые позволяют выявить многие потенциальные проблемы с почтой, включая и открытый релей (т.е. возможность неавторизованной пересылки).
обращались ли в конторы типа Spamhaus, чтобы восстановить справедливость
В чёрных списках моего IP не было изначально, но Spamhaus (и многие другие провайдеры) позволяют удалять IP из чёрных списков в автоматическом или ручном режиме (с подтверждением), особенно если написать им что-то вроде "IP был не мой, возможно с него раньше рассылали спам" и указать, что сейчас всё настроено корректно (в первую очередь PTR-запись и обратный её резолвинг по A/AAAA-записям).
сервера не требовали повально DMARC и т.д.
И сейчас не требуют - многие письма, которые я получаю (а получаю я в основном всякие уведомления, чеки и пр.) не авторизуются по DMARC из-за отсутствия DMARC-записи. По умолчанию Rspamd не добавляет за это штраф к спам-рейтингу письма. Это, конечно, не означает, что DMARC не стоит включать.
И еще один оффтопный вопрос не толко к автору, а ко всем: если у меня сейчас почта на домене, например, example.com, но гугловская, а я создам еще один поддомен, например, test.example.com, почту на нем, пропишу все записи для поддомена и начну его причесывать (добиваться, чтоб не попадало в спам), это зачтется, если я перенесу потом основную почту на домен второго уровня? Что вообще «самое важное» с точки зрения антиспама, домен, айпишник, может, записи какие?
Не уверен здесь на 100%, но, насколько мне известно, в первую очередь играют роль IP-адреса отправителя, а не домены. Но для доменов есть свои спам-листы. Ну и стоит не забывать про все эти SPF, DKIM, DMARC, чтобы не допускать возможности отправлять письма от имени вашего домена без авторизации.
Ну забанить могут не только как российского пользователя, но и из-за какого-нибудь абьюза по причине того же спама (у меня пользователей мало и осознанно они точно спам рассылать не будут, но такие вещи иногда прилетают и совершенно на ровном месте).
Разве что если кого-то взломают, и опять же, вряд ли будут банить сразу же, по крайней мере, если это нормальный провайдер. Ещё в Postfix на такой случай есть различные ограничения, например, на количество отправляемых писем в единицу времени с одного IP, так что как минимум масштабы проблемы можно попытаться таким образом сдержать.
Даунтайм, опять же, может случиться (и случался-таки, пока я всё это изначально настраивал) из-за моих собственных косяков с настройкой софта или проблем с этим софтом, а не из-за проблем в дата-центре
Вот что я люблю в Linux — один раз можно долго провозиться с настройкой, зато когда всё уже настроено, то работает как часы.
А вот настройки повторной отправки, повторюсь, по опыту бывают у людей очень странные. Знаю, что сервер был недоступен максимум пару часов. А письмо, отправленное в этот промежуток времени, приходит реально через 3 дня. Что особенно приятно, если это запрос клиента по договору, в котором электронка - официальный канал связи и срок ответа на такой запрос - 2 дня...
Вообще это действительно странно, потому что очень многие провайдеры (тот же Яндекс) используют грейлистинг, из-за которого сервер получателя вначале выдаёт 400-ю ошибку, которая считается временным сбоем — ровно таким же, каковым должно считаться для отправителя и отсутствие соединения с сервером. Я слышал, что проблемы с грейлистингом бывают (например, когда отправитель использует несколько серверов), но чтобы из-за него письма доходили через 3 дня — ни разу. Скорее всего, опять же, дело в криво написанном SMTP-клиенте, который по-разному воспринимает отсутствие связи и 400-е коды ответа SMTP.
Теоретически, провайдер имеет полный доступ к серверу, так что если захочет... особенно, если это российский провайдер, думаю, в теории это вполне возможно.
Но в целом, конечно, не могу с вами не согласиться, что способ со статическим ключом проще. Добавил упоминание о нём в статью.
Реальных отличий я не заметил (скорее всего, в моём случае они если и есть, то несущественны), а вот то, что тут надо лишний раз прописывать внешний IP, мне не очень понравилось. С одной стороны, вряд ли он может измениться, с другой — если это всё-таки по каким-то причинам случилось, то можно забыть, что прописал его там, и потом удивляться, почему всё сломалось.
За ссылку спасибо, полезный материал, т.к. с iptables я знаком лишь на базовом уровне.
Именно backup MX всё-таки очень нужен, т.к. шанс потерять связь с зарубежным сервером сильно ненулевой (VPN отвалился, на зарубежном хостинге меня забанили, сервер тот упал и т.п.), время на устранение этой досадной неприятности может исчисляться часами, - а рассчитывать на то, что вся входящая почта за это время будет потом доставлена серверами отправителей при повторных попытках, не приходится, некоторые в этом плане ведут себя весьма странно (или не предпринимают повторных попыток вообще, или предпринимают дня через 3, когда письмо уже неактуально).
Всё-таки, если провайдер решит забанить российских пользователей, скорее всего, он сообщит об этом заранее, и будет достаточно времени на перенос сервера в другое место. Уж сколько я новостей прочитал о прекращении обслуживания зарубежными компаниями клиентов из РФ, но не помню такого, чтобы отрубали мгновенно и без предупреждения (как минимум, если речь идёт о хостинг-провайдерах).
Насчёт даунтайма — лично у меня пока не было с этим проблем, видимо, повезло с провайдером. По идее, в дата-центре уровня TIER III и выше простой не может быть более пары часов в год (по моему опыту это пока что подтверждается). За такое время письма не должны теряться, даже если сервер не соблюдает RFC (которое, на минуточку, предусматривает максимальный период доставки аж до 5 дней — конечно, наверняка не все так делают, но повторные попытки доставки предприниматься обязаны). Если сервер недоступен несколько дней, то, вероятно, случилась какая-то катастрофическая ситуация (например, нас отключили от мирового интернета) и об этом будет известно почти сразу или даже заранее, так что будет время подготовиться.
В конечном итоге для резервирования я выбрал лайт-вариант — сихронизация архива писем с домашним сервером плюс резервная копия всех конфигов. В чрезвычайных обстоятельствах можно будет относительно быстро (пара часов плюс-минус) развернуть сервер заново на другой машине, и данные не пропадут. Пока что никаких проблем с приёмом почты, за исключеним описанной ранее «недружественности», я не испытывал.
ИМХО, вообще идеальный вариант — не backup MX, а полноценное зеркало с синхронизацией ящиков, антиспамом, IMAP-сервером и пр., но это задача не моего уровня опыта, и времени заниматься ей у меня в любом случае сейчас нет.
не совсем так. каждый туннель может связывать две точки, но туннелей может быть много.
Вы имеете в виду работу нескольких экземпляров OpenVPN на сервере, каждого со своей конфигурацией? Наверное, можно и так — тогда для каждого клиента будет свой ключ. В таком режиме как минимум будет проблема организации трафика между клиентами, если это по какой-то причине необходимо. Хотя в данном конкретном случае, описанном в статье, это всё же не нужно.
В целом, как я уже тут говорил, я не очень силён в вопросах криптографии, но вижу, что практически везде пишут, что static key менее безопасен, чем классический вариант с сертификатами. Хотя, возможно, на практике разница не слишком существенная.
Да, я упоминал, что как вариант можно сделать второй SMTP-сервер, который будет заниматься пересылкой сообщений. Преимущество в том, что он ещё будет работать как резервный (backup MX). Но мне кажется, что по сравнению с поднятием VPN это всё же менее тривиальная задача — как минимум из-за того, что в идеале такой промежуточный сервер должен иметь такие же настройки антиспама (включая антиспам-систему), что и основной — иначе, если он будет полагаться на нижестоящий спам-фильтр, то в случае отклонения им письма как спамерского он вынужден будет послать NDN (уведомление о недоставке) оригинальному отправителю по адресу MAIL FROM, так как он уже принял это письмо в очередь и закрыл соединение. А спамеры обычно подделывают адреса MAIL FROM, поэтому наш сервер сам превратится в источник спама. Чтобы этого не произошло, есть множество вариантов (отправка писем в чёрную дыру вместо возврата отправителю, синхронизация настроек антиспама, удалённый доступ к основной антиспам-системе и т.д.), но лично мне это кажется дополнительным геморроем, когда можно просто развернуть туннель и перенаправлять все соединения напрямую на основной сервер.
Дополню также, что такой промежуточный сервер, скорее всего, будет хранить временные данные в незашифрованном виде на диске — как минимум тот же Postfix это делает. Кому-то этот момент может быть важен, особенно если сервер находится на территории РФ.
Проверил всё ещё раз. Единственное, что я выяснил — файл VARS для EasyRSA нужно называть vars (маленькими буквами), иначе он не подхватывает настройки. Поправил этот момент в статье.
Параметр tls-cipher управляет наборами шифров на канале управления. Я его не настраивал, но, судя по логу, эллиптические кривые используются:
xxxxx openvpn[22488]: xxxxx:yyyy Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 521 bit EC, curve secp521r1, signature: RSA-SHA256
Если это на самом деле не так — прошу знающих людей подсказать, и я внесу исправления, т.к. в криптографии не очень силён, и это не основной момент данной статьи. Приношу извинения.
UCEPROTECT только деньги берут. На их списки можно вообще не смотреть.
В mxtoolbox они есть, значит, возможно, остались ещё какие-то провайдеры, которые их всё же используют. Но, вообще говоря, никакие письма не должны безусловно отклоняться при наличии отправителя в таком списке, даже если операторы этого списка не занимаются шантажом. В нормальной антиспам-системе (например, Rspamd) это всего лишь один из возможных факторов, которые позволяют признать письмо спамом.
Почтовый сервер у себя дома - это, конечно, заманчивая идея. Я задумывался об этом, но в итоге отказался так делать по следующим причинам:
Проблемы с PTR, как уже говорили выше. Не все провайдеры делают PTR-запись физическим лицам, и даже если запись присутствует, она может быть в формате IP-адреса (что-то вроде 1-2-3-4.static.providername.com), а записи такого вида частенько недолюбливают различные антиспам-системы;
Может быть закрыт 25-й порт для исходящих соединений, и далеко не любой провайдер может согласиться его открыть. Возможно, среди российских провайдеров это не очень распространённая практика, но достоверно утверждать не могу;
IP-адреса, предназначенные для раздачи конечным пользователям интернета, обычно заносятся в списки вроде Spamhaus PBL, и не всегда может быть возможность удалить себя оттуда самостоятельно, если вообще может быть (у Spamhaus политика удаления из PBL различается в зависимости от конкретного блока адресов);
Ну и, конечно, вопросы аптайма и резервирования в домашних условиях - даже если вы можете себе позволить оборудование уровня дата-центра, скорее всего, вам это всё равно обойдётся дороже, чем аренда виртуального сервера.
Если ДОМру действительно даёт возможность сделать любую PTR-запись и открыть 25-й порт, то всё равно остаются последние два пункта. При этом вопрос аптайма и резервирования, наверное, даже более важен, чем попадание в чёрные списки (так как это можно обойти с помощью того же VPN-туннеля). Вот вы уехали в отпуск на две недели, а у вас в городе авария на подстанции, нет света полдня. UPS может столько и не протянуть (и не факт, что оборудование провайдера на чердаке тоже не отрубилось), а вам срочно нужно получить или отправить какое-то письмо...
При этом я не говорю, что нет смысла вообще дома держать какой-то сервер, если ваш провайдер выдаёт белый IP-адрес. Но такой критически важный сервис, как электронная почта, я бы хостить у себя "под столом" не стал, особенно с учётом вышесказанных особенностей, связанных с его настройкой.
Теперь становится понятно, почему их сервера в Эстонии внезапно отключили под вечер 24 мая... Мне по запросу потом активировали бесплатно VPS в другой локации (не ЕС), хотя и небыстро - видимо, поддержка была завалена обращениями. И никакого письма о санкциях мне от них, к слову, не приходило - ни до отключения, ни после. А пока я жду от них подробного разбора инцидента, желательно с описанием мер, которые они планируют предпринять, чтобы избежать аналогичных ситуаций в будущем, они, оказывается, ребрендингом занимаются - о как!
Понятно, спасибо, я сам в электронике плохо разбираюсь, тем более в такой.
К сожалению, чек не могу найти (на сайте магазина в ЛК они почему-то только до 2021 года, но, наверное, можно сделать запрос в поддержку), да и ехать в сервис лень, к тому же я уже заменил карту на новую. Если бы не нужно было менять срочно, может, и попробовал бы. Но вообще сам факт того, что они могут вот так внезапно сломаться, напрягает. Там же нет механических деталей, как в жёстком диске, которые могут отказать... хотя это мог быть какой-нибудь статический разряд, например.
Спасибо, не знал об этом раньше. Проверил только что — торец белый.
Ёмкость я специально не тестировал, но проблем с нечитаемостью или перезатиранием данных не было, при этом использовалась более половины доступного объёма (порядка 130 ГБ, если не ошибаюсь). Сейчас по понятным причинам проверить её уже не представляется возможным, но я думаю, что с ней всё было в порядке.
К сожалению, это касается не только карт с AliExpress. Недавно у меня испортилась карточка Samsung на 256 ГБ, которую я использовал в музыкальном плеере. ЕМНИП, заказывал её на Ozon (из-за быстрой доставки) — возможно, она была поддельной, но не знаю, как это можно проверить, тем более стоила она не так дёшево, чтобы возникли подозрения по этому поводу.
Карта проработала меньше двух лет, при этом в последнее время я практически не записывал на неё никакой новой музыки, только слушал. В один прекрасный день она просто перестала отображаться в проводнике, а при попытке просмотра разделов на ней с помощью diskpart он намертво зависал. На машине с UNIX-системой лучше не стало: в лог ядра стали сыпаться ошибки «Unretryable error», любые попытки что-то прочитать вызывали сообщение «Input/output error». Сделал вывод, что восстановлению карта не подлежит.
Мораль как обычно: делайте резервные копии...
Действительно, похоже, что обновление прошло. На текущий момент последняя версия 102.0.5005.125, и именно такую показывает приложение у меня сейчас.
К сожалению, примерно неделю назад снова возникла такая же проблема. Возможно, это связано с обновлением моего телефона до Android 12 (обновление официальное), но не могу быть уверен на 100%, т.к. появилось это не сразу, а через несколько дней после обновления.
Пробовал чистить кэш и данные Google Play, перезагружаться, но доходит только до того, что скачивает, но установить не может (раньше вообще не мог скачать). Хотя, судя по тому, что размер обновления — 91 КБ, это скорее всего тоже глюк, а не санкции. Интересно только, что уже прошло довольно много времени с тех пор, как он начался, но в новостях ничего по этому поводу не проскакивало, как будто это и вправду только у меня.
Можно поднять на VPN-шлюзе DNS-резолвер и использовать его с основного сервера в качестве резервного. Я так и сделал, но мне эта идея пришла в голову уже после написания статьи, и поскольку она и так получилась довольно длинной, решил не добавлять об этом упоминание. В целом, с этим всё довольно тривиально, когда туннель уже поднят. Я ставил в качестве резолвера Unbound, по нему хорошая документация на официальном сайте.
Добрый день!
К сожалению, у меня редко находится время и желание (особенно именно в такой комбинации) на то, чтобы что-то писать, а в ближайший месяц точно не получится. На создание этой и предыдущей статьи меня, можно сказать, вдохновили последние события, так что это скорее исключение, чем правило. Вообще, я не очень люблю этим заниматься.
На самом деле не так много. Мой почтовый сервер работает чуть более полугода, и первые два месяца я практически каждый день что-то подкручивал в настройках, чтобы добиться того, чтобы всё работало именно так, как мне надо, а не как-то ещё.
Я использую Postfix + Dovecot, потому что лично мне показалось, что по этим двум программным продуктам больше всего документации. Ещё вроде бы часто используют Exim в качестве MTA и Cyrus в качестве IMAP-сервера. Но я не проводил сравнения используемого мной ПО с аналогами. Просто взял их потому, что в интерете именно по ним очень много руководств, от которых можно отталкиваться, если вообще ничего не понимаешь (а я, когда начинал настраивать, действительно мало что понимал).
Очень часто в туториалах упоминается SpamAssassin, но лично я использовал Rspamd, так как слышал, что у SpamAssassin'а могут быть проблемы с анализом писем в кодировке UTF-8. Но не могу сказать на 100%, актуальна ли данная проблема на сегодняшний день. Возможно, придётся потанцевать с бубном, чтобы её обойти. У Rspamd, с другой стороны, таких проблем нет, но и документации по нему явно меньше, как мне показалось.
Ранше я использовал почту для домена от Яндекса, так что домен остался. IP-адрес новый. По поводу попадания в спам лично у меня сложилось такое мнение, что даже если настроить всё абсолютно на 100% корректно, первое время всё равно такое возможно, если речь идёт об отправке почты крупным провайдерам (Gmail, Outlook etc). Складывается впечатление, что их антиспам-системы требуют какого-то минимального объёма отправляемой почты (суммарного или в единицу времени), чтобы этого избежать, но в случае с персональным сервером такие объёмы вряд ли достижимы. Однако со временем, скорее всего, ситуация наладится, особенно если просить получателей помечать ваши письма как не спам.
Самому стать спамером, если только не намеренно, возможно, если кто-то подберёт пароль к вашему аккаунту на сервере. Насколько я знаю, по умолчанию все современные почтовые сервера настроены так, чтобы не допускать пересылку писем на сторонние домены без авторизации. Также есть сервисы вроде MxToolbox, которые позволяют выявить многие потенциальные проблемы с почтой, включая и открытый релей (т.е. возможность неавторизованной пересылки).
В чёрных списках моего IP не было изначально, но Spamhaus (и многие другие провайдеры) позволяют удалять IP из чёрных списков в автоматическом или ручном режиме (с подтверждением), особенно если написать им что-то вроде "IP был не мой, возможно с него раньше рассылали спам" и указать, что сейчас всё настроено корректно (в первую очередь PTR-запись и обратный её резолвинг по A/AAAA-записям).
И сейчас не требуют - многие письма, которые я получаю (а получаю я в основном всякие уведомления, чеки и пр.) не авторизуются по DMARC из-за отсутствия DMARC-записи. По умолчанию Rspamd не добавляет за это штраф к спам-рейтингу письма. Это, конечно, не означает, что DMARC не стоит включать.
Не уверен здесь на 100%, но, насколько мне известно, в первую очередь играют роль IP-адреса отправителя, а не домены. Но для доменов есть свои спам-листы. Ну и стоит не забывать про все эти SPF, DKIM, DMARC, чтобы не допускать возможности отправлять письма от имени вашего домена без авторизации.
Спасибо! Добавил в статью ссылку на ваш комментарий с разъяснением.
Разве что если кого-то взломают, и опять же, вряд ли будут банить сразу же, по крайней мере, если это нормальный провайдер. Ещё в Postfix на такой случай есть различные ограничения, например, на количество отправляемых писем в единицу времени с одного IP, так что как минимум масштабы проблемы можно попытаться таким образом сдержать.
Вот что я люблю в Linux — один раз можно долго провозиться с настройкой, зато когда всё уже настроено, то работает как часы.
Вообще это действительно странно, потому что очень многие провайдеры (тот же Яндекс) используют грейлистинг, из-за которого сервер получателя вначале выдаёт 400-ю ошибку, которая считается временным сбоем — ровно таким же, каковым должно считаться для отправителя и отсутствие соединения с сервером. Я слышал, что проблемы с грейлистингом бывают (например, когда отправитель использует несколько серверов), но чтобы из-за него письма доходили через 3 дня — ни разу. Скорее всего, опять же, дело в криво написанном SMTP-клиенте, который по-разному воспринимает отсутствие связи и 400-е коды ответа SMTP.
Теоретически, провайдер имеет полный доступ к серверу, так что если захочет... особенно, если это российский провайдер, думаю, в теории это вполне возможно.
Но в целом, конечно, не могу с вами не согласиться, что способ со статическим ключом проще. Добавил упоминание о нём в статью.
Реальных отличий я не заметил (скорее всего, в моём случае они если и есть, то несущественны), а вот то, что тут надо лишний раз прописывать внешний IP, мне не очень понравилось. С одной стороны, вряд ли он может измениться, с другой — если это всё-таки по каким-то причинам случилось, то можно забыть, что прописал его там, и потом удивляться, почему всё сломалось.
За ссылку спасибо, полезный материал, т.к. с iptables я знаком лишь на базовом уровне.
Всё-таки, если провайдер решит забанить российских пользователей, скорее всего, он сообщит об этом заранее, и будет достаточно времени на перенос сервера в другое место. Уж сколько я новостей прочитал о прекращении обслуживания зарубежными компаниями клиентов из РФ, но не помню такого, чтобы отрубали мгновенно и без предупреждения (как минимум, если речь идёт о хостинг-провайдерах).
Насчёт даунтайма — лично у меня пока не было с этим проблем, видимо, повезло с провайдером. По идее, в дата-центре уровня TIER III и выше простой не может быть более пары часов в год (по моему опыту это пока что подтверждается). За такое время письма не должны теряться, даже если сервер не соблюдает RFC (которое, на минуточку, предусматривает максимальный период доставки аж до 5 дней — конечно, наверняка не все так делают, но повторные попытки доставки предприниматься обязаны). Если сервер недоступен несколько дней, то, вероятно, случилась какая-то катастрофическая ситуация (например, нас отключили от мирового интернета) и об этом будет известно почти сразу или даже заранее, так что будет время подготовиться.
В конечном итоге для резервирования я выбрал лайт-вариант — сихронизация архива писем с домашним сервером плюс резервная копия всех конфигов. В чрезвычайных обстоятельствах можно будет относительно быстро (пара часов плюс-минус) развернуть сервер заново на другой машине, и данные не пропадут. Пока что никаких проблем с приёмом почты, за исключеним описанной ранее «недружественности», я не испытывал.
ИМХО, вообще идеальный вариант — не backup MX, а полноценное зеркало с синхронизацией ящиков, антиспамом, IMAP-сервером и пр., но это задача не моего уровня опыта, и времени заниматься ей у меня в любом случае сейчас нет.
Вы имеете в виду работу нескольких экземпляров OpenVPN на сервере, каждого со своей конфигурацией? Наверное, можно и так — тогда для каждого клиента будет свой ключ. В таком режиме как минимум будет проблема организации трафика между клиентами, если это по какой-то причине необходимо. Хотя в данном конкретном случае, описанном в статье, это всё же не нужно.
В целом, как я уже тут говорил, я не очень силён в вопросах криптографии, но вижу, что практически везде пишут, что static key менее безопасен, чем классический вариант с сертификатами. Хотя, возможно, на практике разница не слишком существенная.
Действительно, есть вариант сделать статический симметричный ключ, здесь описано, как это делается. Там же упоминаются и недостатки:
Ограничение на один клиент — если вам вдруг понадобиться подключить ещё одного клиента к VPN-серверу, то всё равно придётся перенастраивать;
Отсутствие совершенной прямой секретности — если ключ скомпрометирован, то весь уже перехваченный трафик можно взломать;
Необходимо передавать секретным ключ между машинами (желательно по безопасному каналу), т.е. ключ покидает пределы машины, на которой он сгенерирован.
Вывод: для параноиков, скорее всего, не подойдёт. Но если лень возиться с EasyRSA, то вполне.
Про smtp relay написал ниже.
Да, я упоминал, что как вариант можно сделать второй SMTP-сервер, который будет заниматься пересылкой сообщений. Преимущество в том, что он ещё будет работать как резервный (backup MX). Но мне кажется, что по сравнению с поднятием VPN это всё же менее тривиальная задача — как минимум из-за того, что в идеале такой промежуточный сервер должен иметь такие же настройки антиспама (включая антиспам-систему), что и основной — иначе, если он будет полагаться на нижестоящий спам-фильтр, то в случае отклонения им письма как спамерского он вынужден будет послать NDN (уведомление о недоставке) оригинальному отправителю по адресу MAIL FROM, так как он уже принял это письмо в очередь и закрыл соединение. А спамеры обычно подделывают адреса MAIL FROM, поэтому наш сервер сам превратится в источник спама. Чтобы этого не произошло, есть множество вариантов (отправка писем в чёрную дыру вместо возврата отправителю, синхронизация настроек антиспама, удалённый доступ к основной антиспам-системе и т.д.), но лично мне это кажется дополнительным геморроем, когда можно просто развернуть туннель и перенаправлять все соединения напрямую на основной сервер.
Дополню также, что такой промежуточный сервер, скорее всего, будет хранить временные данные в незашифрованном виде на диске — как минимум тот же Postfix это делает. Кому-то этот момент может быть важен, особенно если сервер находится на территории РФ.
Проверил всё ещё раз. Единственное, что я выяснил — файл
VARSдля EasyRSA нужно называтьvars(маленькими буквами), иначе он не подхватывает настройки. Поправил этот момент в статье.Параметр
tls-cipherуправляет наборами шифров на канале управления. Я его не настраивал, но, судя по логу, эллиптические кривые используются:Если это на самом деле не так — прошу знающих людей подсказать, и я внесу исправления, т.к. в криптографии не очень силён, и это не основной момент данной статьи. Приношу извинения.
В mxtoolbox они есть, значит, возможно, остались ещё какие-то провайдеры, которые их всё же используют. Но, вообще говоря, никакие письма не должны безусловно отклоняться при наличии отправителя в таком списке, даже если операторы этого списка не занимаются шантажом. В нормальной антиспам-системе (например, Rspamd) это всего лишь один из возможных факторов, которые позволяют признать письмо спамом.
Почтовый сервер у себя дома - это, конечно, заманчивая идея. Я задумывался об этом, но в итоге отказался так делать по следующим причинам:
Проблемы с PTR, как уже говорили выше. Не все провайдеры делают PTR-запись физическим лицам, и даже если запись присутствует, она может быть в формате IP-адреса (что-то вроде 1-2-3-4.static.providername.com), а записи такого вида частенько недолюбливают различные антиспам-системы;
Может быть закрыт 25-й порт для исходящих соединений, и далеко не любой провайдер может согласиться его открыть. Возможно, среди российских провайдеров это не очень распространённая практика, но достоверно утверждать не могу;
IP-адреса, предназначенные для раздачи конечным пользователям интернета, обычно заносятся в списки вроде Spamhaus PBL, и не всегда может быть возможность удалить себя оттуда самостоятельно, если вообще может быть (у Spamhaus политика удаления из PBL различается в зависимости от конкретного блока адресов);
Ну и, конечно, вопросы аптайма и резервирования в домашних условиях - даже если вы можете себе позволить оборудование уровня дата-центра, скорее всего, вам это всё равно обойдётся дороже, чем аренда виртуального сервера.
Если ДОМру действительно даёт возможность сделать любую PTR-запись и открыть 25-й порт, то всё равно остаются последние два пункта. При этом вопрос аптайма и резервирования, наверное, даже более важен, чем попадание в чёрные списки (так как это можно обойти с помощью того же VPN-туннеля). Вот вы уехали в отпуск на две недели, а у вас в городе авария на подстанции, нет света полдня. UPS может столько и не протянуть (и не факт, что оборудование провайдера на чердаке тоже не отрубилось), а вам срочно нужно получить или отправить какое-то письмо...
При этом я не говорю, что нет смысла вообще дома держать какой-то сервер, если ваш провайдер выдаёт белый IP-адрес. Но такой критически важный сервис, как электронная почта, я бы хостить у себя "под столом" не стал, особенно с учётом вышесказанных особенностей, связанных с его настройкой.