Является ли перезапись SRS абсолютно необходимой для пересылки почтового сервера?


14

Я использую почтовый сервер Postfix для своего домена, скажем, mydomain.com. Он в основном действует как сервер пересылки электронной почты: пользователи получают адрес электронной почты @ mydomain.com, но обычно предпочитают пересылать свой адрес на внешний почтовый ящик (Gmail, Yahoo и т. Д.). Пересылается несколько тысяч адресов, поэтому сервер обрабатывает довольно значительный объем почтового трафика.

В прошлом сервер не использовал перезапись SRS. Это, конечно, означало, что переадресованная почта не пройдет проверку SPF, поскольку мой ip-адрес технически не авторизован для отправки электронной почты от имени исходного домена отправителя. Тем не менее, насколько я вижу, это не вызывает каких-либо существенных проблем. Обычно жалобы со стороны пользователей, таких как Gmail, Yahoo и т. Д., Кажутся достаточно умными, чтобы игнорировать сбои SPF и доставлять сообщения в любом случае.

Имея это в виду, действительно ли необходимо включить перезапись SRS? Я рассматриваю возможность его включения, но моя главная проблема заключается в том, что мой домен попадет в черный список для отправки спама, когда спам неизбежно получает поддержку. Разве переписывание не заставило бы это казаться, как будто я - источник спама? (По крайней мере, я так понимаю, прочитав рекомендации Gmail по пересылке почтовых серверов ).

Конечно, я уже принимаю некоторые из рекомендованных мер предосторожности, таких как использование SpamAssassin для добавления «СПАМА» в строку темы подозреваемого спама перед пересылкой, не пересылка спама с высокой достоверностью (оценка 15+) и использование блок-списка spamhaus, но эти меры не не идеален, и спам все еще может проскользнуть без опознавательных знаков.

Стоит ли включать перезапись SRS, если это увеличивает риск быть ошибочно помеченным как спамер? Или было бы безопаснее просто оставить все как есть и игнорировать сбои SPF?


По своему опыту я знаю, что некоторые интернет-провайдеры в Великобритании будут отклонять входящие электронные письма, которые, как утверждается, принадлежат их собственным клиентам, но не были отправлены их собственными почтовыми программами. То же самое можно сказать и о Gmail, Yahoo и AOL. Такие ситуации могут быть разрешены только путем перезаписи адреса отправителя.
Роайма

Ответы:


9

Мне кажется, что ваш вопрос сводится к тому, « сколько почтовых серверов там проверяют записи SPF на входящей электронной почте? ». Если это большинство из них, SRS является абсолютным требованием для сервера пересылки; если это не один из них, вам не нужен SRS.

К сожалению, я не могу сразу приложить руки к какой-либо научной работе по этому вопросу. Но так как я проверяю SPF на входящей электронной почте, я могу с уверенностью сказать, что некоторые почтовые серверы проверяют это. Любой из ваших клиентов, у которых ваш сервер переадресован на учетные записи на моем сервере, потеряет электронную почту, отправленную отправителями, которые сообщают об окончании SPF (как они все должны) -all, если вы не используете SRS. Поэтому я могу с уверенностью сказать, что без SRS электронная почта некоторых ваших клиентов не будет доставлена .

Я прошу прощения у Марка за то, что не могу читать по-немецки, поэтому я не могу сказать, приводит ли цитируемый им PDF-документ убедительные аргументы, но я могу повторить, что без SRS некоторая часть электронной почты ваших клиентов не будет доставлена. Я не могу сказать, что это за фракция, но она не равна нулю, и, учитывая это, я не думаю, что у вас есть какая-либо альтернатива, кроме как запустить SRS.

Я согласен с тем, что ваш сервер не будет помогать самому себе, пересылая СПАМ, но по моему опыту большая часть ущерба репутации наносится его IP-адресу, а не домену конверта-От; это будет сделано независимо от использования SRS.

Более глубокий ответ на ваш вопрос заключается в том, что между SPF и его (непродуманным и взломанным Интернетом) DMARC мне кажется, что у служб пересылки почты был свой день. Я уже потребовал, чтобы все пользователи, кроме одного, имели окончательную доставку на моем сервере, и что одному пользователю придется изменить или уйти в 2016 году. В настоящее время многие системы веб-почты позволяют интегрировать несколько почтовых ящиков, собирая почту вне сервера с использованием IMAP или POP и многие почтовые клиенты позволяют представлять несколько учетных записей IMAP или POP в виде единого интегрированного INBOX, поэтому пересылка не является благом для централизованного чтения, как это было раньше.

Короче говоря, я бы сказал, что вам нужен SRS в краткосрочной перспективе и новая бизнес-модель в долгосрочной перспективе.


Дело в том, что SRS - это решение для устранения проблем переадресации SPF. SRS перезаписывает, например, user @ A - A = user @ B, и записи SPF B ответственны. Проблема: B все еще может подделать адреса! Поэтому некоторые добавляют криптованные хеши и метки времени к переписанному адресу. Для того, чтобы это работало в больших масштабах, нужно глобальное принятие, которого там нет. Это также работает, только если что-то передается один раз, но не более. Также ответы являются проблемой. Также имейте в виду, что SPF - это метод защиты вашей собственной области злоупотреблений, не более того.
Марк Штюрмер

@ MarcStürmer « SRS - это решение для устранения проблем переадресации SPF »: да, именно так оно и есть. SPF, как известно, нарушает упрощенную пересылку; если вы не думаете, что SRS - это цена, которую стоит заплатить, не рекламируйте запись SPF. « Проблема: B все еще может подделать адреса »: не к домену A или любому другому домену, защищенному приличной записью SPF, иначе почта будет отклонена в соответствии с SPF; но кроме этого, да, это может, и я не вижу в этом проблемы. « SPF - это метод защиты вашей собственной области злоупотреблений, не более того »: согласен.
MadHatter

@ MarcStürmer: «Это также работает, только если что-то передается один раз, но не более». неправильно. SRS отлично работает на нескольких серверах пересылки. Он страдает только в том случае, если в строке есть сервер без тегов. Но это та же проблема, что и с любым сервером без тегов в целом, будь то первый или более поздний переход вперед. В мире SPF вам не нужен SRS, вам просто нужно взять на себя ответственность за пересылку почты и убедиться, что вы можете доставить возможный отскок назад. SRS - это всего лишь один метод, который делает это, например, Google использует что-то другое.
Адриан Заугг

Проблема в том, что использование SRS нарушает проверку выравнивания DMARC (т. From:Е. Отправителя конверта! = -Header) и заставляет Gmail отклонять сообщения, если домен в From:заголовке имеет p=rejectв своей политике DMARC. Если вы перепишете From:письмо, почта будет проверена в соответствии с правилами вашего домена. Но проверка DKIM не удастся, и отправитель, показанный в почтовом клиенте, искажен.
mbirth

@ mbirth afaik, ты прав. Но я лично считаю DMARC полной катастрофой, не в последнюю очередь потому, что она в одностороннем порядке сломала списки рассылки, и (в моем качестве администратора большого списка сообществ) просто советую людям не использовать любого провайдера, который публикует p=rejectполитику. Если SRS сломает DMARC, ну, это просто тяжело для DMARC.
MadHatter

9

SRS, кажется, хорошая идея на бумаге, но не очень хорошо работает на практике, по словам людей из Heinlein Support (они используют почтовый сервис среднего размера с более чем 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. для лучшего качества доставки.


1
Проблема здесь в том, что SPF, а не SRS. Пока некоторые интернет-провайдеры используют SPF, вам нужно внедрить SRS (или что-то подобное), чтобы переадресация работала со всеми из них. Проблема с серыми списками отличается, вы должны "распаковать" адреса отправителей с тегами SRS для списков серых списков (а также почты с тегами BATV).
Адриан Заугг

3

Я согласен с каждым словом @MadHatter, НО важный факт о Google!

Если вы предоставляете службу пересылки в gmail, есть большая вероятность, что вы также предоставите SMTP-доступ, чтобы ваши пользователи gmail могли отправлять письма из gmail от имени сохраненного вами адреса.

В этом случае - gmail знает, что вы переадресовываете это письмо, и не помечает ваши пересылки как спам, даже если они не прошли проверку SPF.

Вы можете отправлять письма своим клиентам с bill@microsoft.com. Сообщение попадет в их почтовый ящик без предупреждения! (Microsoft имеет -all в записи SPF)

Проверено и проверено. Пример прилагается.

это сообщение отправлено в почтовый ящик.gmail Показать оригинал

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.