1. Я не имел в виду, что IPV6 не нужен совсем, но его действительно чаще всего не используют, на моей практике не было ни одного такого случая, где приходилось бы работать с настройкой IPV6 адресов. Сама по себе штука безусловно нужная. Просто если бы коснулся этого вопроса, нужно было бы рассмотреть хотя бы кратко особенности этих протоколов, а это сильно отвлекло бы от сути статьи. 2. Ууу, да, тут я косякнул жоско, исправлю. 3. DMARC решил не расписывать в виду того, что как раз при написании статьи тестировал отправку писем без него и не обнаружил из-за этого никаких проблем ни у Гугл, ни у Яндекса, ни у Mail.ru, они корректно письма принимали, никаких с этим проблем не возникало. Отсутствие DMARC как правило просто говорит серверам получателей "используй свой DMARC по умолчанию", а это сработает только в том случае, когда SPF и\или DKIM будут некорректными - что бывает как раз у поддельных писем. Чтобы добиться 10 баллов у mail-tester всё равно придется добавить DMARC, поэтому, конечно, лучше эту запись указывать. Но я посчитал, что она не является одной из основных, поэтому и не расписал.
Я не хотел в данной статье касаться таких подробностей, чтобы она сильно не разрослась, но хотел рассмотреть в будущих кейсах. Посчитал, что простого упоминания inet_interfaces и краткого описания "для чего это нужно", будет достаточно. Рассматриваемый кейс не предполагает других клиентов кроме сайта (в статье я привожу пример сайта интернет-магазина, но это легко может быть и какая-нибудь b2b-платформа, корпоративный портал или crm-система), поэтому вопрос защиты не стоит остро. У меня есть один примечательный кейс для описания того, где и как придется озаботиться безопасностью и настройкой firewall, но решил его приберечь для других статей?
Моя практика работы с почтой показывает, что хорошего спам-фильтра не существует. Сигнатурная фильтрация как правило легко обходится - на распределенных (не важно, открытых или закрытых) базах можно проверить содержимое спама, скорректировать, чтобы фильтр не ругался, и отправить всем. Получатели как правило не сразу успевают проверить письмо, не сразу кликают на кнопочку "Спам", и, соответственно, сигнатура такого письма не сразу попадает в базы. А письма уже успеют отправиться огромному кол-ву пользователей, пока сигнатуры обновятся. Самые эффективные фильтры - это фильтры, которые используют всё сразу: и сигнатурную, и по правилам, и на статистическом обучении. Но даже это совсем не гарантирует полную защиту от спама - таковы реалии, к сожалению. Более подробно постараюсь рассказать в будущих статьях.
Вообще говоря да, так и должно быть, однако не сильно крупные проекты редко когда пользуются услугами devops-команд, иногда даже не имеют обычных администраторов серверов - большая часть их бюджета уходит на оплату работы разработчиков. Почта им тоже нужна, поэтому либо они начинают её самостоятельно настраивать (что как правило заканчивается неудачно), либо обращаются к уже имеющимся разработчикам, которые для этого не предназначены, но которые понимают хоть что-то в конфигурировании сервера (в отличии от бизнес-ориентированного клиента). Как-то так
1. Я не имел в виду, что IPV6 не нужен совсем, но его действительно чаще всего не используют, на моей практике не было ни одного такого случая, где приходилось бы работать с настройкой IPV6 адресов. Сама по себе штука безусловно нужная. Просто если бы коснулся этого вопроса, нужно было бы рассмотреть хотя бы кратко особенности этих протоколов, а это сильно отвлекло бы от сути статьи.
2. Ууу, да, тут я косякнул жоско, исправлю.
3. DMARC решил не расписывать в виду того, что как раз при написании статьи тестировал отправку писем без него и не обнаружил из-за этого никаких проблем ни у Гугл, ни у Яндекса, ни у Mail.ru, они корректно письма принимали, никаких с этим проблем не возникало. Отсутствие DMARC как правило просто говорит серверам получателей "используй свой DMARC по умолчанию", а это сработает только в том случае, когда SPF и\или DKIM будут некорректными - что бывает как раз у поддельных писем. Чтобы добиться 10 баллов у mail-tester всё равно придется добавить DMARC, поэтому, конечно, лучше эту запись указывать. Но я посчитал, что она не является одной из основных, поэтому и не расписал.
Я не хотел в данной статье касаться таких подробностей, чтобы она сильно не разрослась, но хотел рассмотреть в будущих кейсах. Посчитал, что простого упоминания inet_interfaces и краткого описания "для чего это нужно", будет достаточно. Рассматриваемый кейс не предполагает других клиентов кроме сайта (в статье я привожу пример сайта интернет-магазина, но это легко может быть и какая-нибудь b2b-платформа, корпоративный портал или crm-система), поэтому вопрос защиты не стоит остро. У меня есть один примечательный кейс для описания того, где и как придется озаботиться безопасностью и настройкой firewall, но решил его приберечь для других статей?
Моя практика работы с почтой показывает, что хорошего спам-фильтра не существует. Сигнатурная фильтрация как правило легко обходится - на распределенных (не важно, открытых или закрытых) базах можно проверить содержимое спама, скорректировать, чтобы фильтр не ругался, и отправить всем. Получатели как правило не сразу успевают проверить письмо, не сразу кликают на кнопочку "Спам", и, соответственно, сигнатура такого письма не сразу попадает в базы. А письма уже успеют отправиться огромному кол-ву пользователей, пока сигнатуры обновятся. Самые эффективные фильтры - это фильтры, которые используют всё сразу: и сигнатурную, и по правилам, и на статистическом обучении. Но даже это совсем не гарантирует полную защиту от спама - таковы реалии, к сожалению. Более подробно постараюсь рассказать в будущих статьях.
Вообще говоря да, так и должно быть, однако не сильно крупные проекты редко когда пользуются услугами devops-команд, иногда даже не имеют обычных администраторов серверов - большая часть их бюджета уходит на оплату работы разработчиков. Почта им тоже нужна, поэтому либо они начинают её самостоятельно настраивать (что как правило заканчивается неудачно), либо обращаются к уже имеющимся разработчикам, которые для этого не предназначены, но которые понимают хоть что-то в конфигурировании сервера (в отличии от бизнес-ориентированного клиента). Как-то так
нашлися! спасибо!)