Я использую почтовый сервер Postfix для своего домена, скажем mydomain.com. В основном он действует как сервер пересылки электронной почты: пользователи получают адрес электронной почты @ mydomain.com, но обычно предпочитают пересылать свой адрес во внешний почтовый ящик (Gmail, Yahoo и т. Д.). Пересылается несколько тысяч адресов, поэтому сервер обрабатывает довольно значительный объем почтового трафика.
Раньше сервер не использовал перезапись SRS. Это, конечно, означало, что пересылаемая почта не прошла проверку SPF, поскольку мой IP-адрес технически не авторизован для отправки электронной почты от имени домена исходного отправителя. Однако, насколько я могу судить, это не вызывает серьезных проблем. Как правило, от пользователей нет жалоб, поскольку Gmail, Yahoo и т. Д. Кажутся достаточно умными, чтобы игнорировать сбои SPF и в любом случае доставлять сообщения.
Имея это в виду, действительно ли необходимо включать перезапись SRS? Я подумываю о его включении, но меня больше всего беспокоит то, что мой домен попадет в черный список за рассылку спама, когда спам неизбежно попадает в сеть. Разве при переписывании не будет казаться, что я являюсь автором спама? (По крайней мере, так я понял из чтения Рекомендации Gmail для пересылки почтовых серверов).
Конечно, я уже принимаю некоторые из рекомендуемых мер предосторожности, например, использую SpamAssassin для добавления «СПАМА» в строку темы подозреваемого спама перед пересылкой, не пересылаю спам с высокой степенью достоверности (оценка 15+) и использую черный список spamhaus, но эти меры неприменимы не идеален, и спам все равно может пройти без отметки.
Стоит ли включать перезапись SRS, если это увеличивает риск ошибочной маркировки как спамера? Или было бы безопаснее просто оставить все как есть и игнорировать сбои SPF?
SRS кажется хорошей идеей на бумаге, но, по словам сотрудников службы поддержки Heinlein, на практике не очень хорошо работает (у них есть почтовая служба среднего размера с более чем 100000 учетными записями).
Подробности в их разговоре, хотя и на немецком, почему: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf
Основная причина в том, что SRS - это небольшой патч для серьезных проблем с реализацией SPF в реальности, потому что SPF не очень хорошо охватывает некоторые распространенные варианты использования электронной почты. Чтобы SRS имела смысл, ее необходимо развернуть на большой базе серверов, что вряд ли когда-либо произойдет. Так что, пока он не будет развернут на этой большой базе серверов, в этом нет никакого смысла.
Проблема с крупными почтовыми провайдерами заключается в том, что в настоящее время у них действительно большая база пользователей, и они внедряют все больше и больше техник (преемник DMARC уже находится в стадии разработки), что делает это все более и более трудным для обычного настройка почтового сервера для надежной отправки им писем.
Если вы хотите, чтобы ваша почта лучше доставлялась крупным почтовым провайдерам, таким как Gmail, Hotmail и т. Д., Вам следует реализовать как минимум DKIM и DMARC, но также настроить его в лучшем случае на мягкий сбой и, возможно, реализовать некоторые механизмы ограничения скорости при доставке почты. творит чудеса для вас.
Эта проблема с крупными поставщиками является причиной того, что в настоящее время существуют такие службы, как Mailchimp, Mandrill или Returnpath. Эти поставщики действительно платят деньги Google & Co. для лучшего качества доставки.
Мне кажется, ваш вопрос сводится к следующему: "Сколько почтовых серверов проверяют записи SPF на входящую почту?". Если их большинство, SRS является абсолютным требованием для сервера пересылки; если их нет, вам не нужна SRS.
К сожалению, я не могу сразу взять в руки какую-либо научную работу по этому поводу. Но поскольку я проверяю SPF на входящую почту, я могу с уверенностью сказать, что некоторые почтовые серверы это проверяют. Любой из ваших клиентов, у которых ваш сервер перенаправлен на учетные записи на моем сервере, потеряет электронную почту, отправленную от отправителей, которые рекламируют SPF, который заканчивается (как все они) -all
, если вы не используете SRS. Так что могу с уверенностью сказать, что без SRS некоторые электронные письма ваших клиентов не будут доставлены.
Я приношу свои извинения Марку за то, что не могу читать по-немецки, поэтому я не могу сказать, содержит ли цитируемый им PDF убедительные аргументы, но могу повторить, что без SRS некоторая часть электронных писем ваших клиентов не будет доставлена. Я не могу сказать, что это за доля, но она не равна нулю - и учитывая это, я не думаю, что у вас есть альтернатива, кроме как запустить SRS.
Я согласен с тем, что ваш сервер не будет помогать себе путем пересылки СПАМА, но, по моему опыту, большая часть репутационного ущерба наносится его IP-адресу, а не домену отправителя конверта; это будет сделано независимо от использования SRS.
Более глубокий ответ на ваш вопрос заключается в том, что между SPF и его (необдуманным и нарушающим интернет) последующим DMARC, мне кажется, что у служб пересылки почты свое время. Я уже потребовал, чтобы все мои пользователи, кроме одного, имели окончательную доставку на моем сервере, и этот один пользователь должен будет сменить или уйти в 2016 году. В настоящее время многие системы веб-почты допускают интеграцию с несколькими почтовыми ящиками, собирая почту вне сервера с помощью IMAP или POP, а также многие почтовые клиенты позволяют отображать несколько учетных записей IMAP или POP как единый интегрированный почтовый ящик INBOX, поэтому пересылка не является благом для централизованного чтения, как раньше.
Короче говоря, я бы сказал, что вам нужна SRS в краткосрочной перспективе и новая бизнес-модель в долгосрочной перспективе.
Я согласен с каждым словом @MadHatter, НО важный факт о Google!
Если вы предоставляете услугу пересылки для Gmail, есть большая вероятность, что вы также предоставите доступ SMTP, чтобы ваши пользователи Gmail могли отправлять письма из Gmail от имени адреса, хранящегося вами.
В этом случае - Gmail знает, что вы являетесь пересылкой этого письма, и не помечает ваши пересылки как спам, даже если проверка SPF не прошла.
Вы можете отправлять своим клиентам письма с адреса bill@microsoft.com. Сообщение попадет в их почтовый ящик без предупреждения! (Microsoft имеет -all
в записи SPF)
Проверено и проверено. Пример прилагается.
это сообщение попало во входящие.