A reescrita do SRS é absolutamente necessária para um servidor de encaminhamento de mensagens?


14

Estou operando um servidor de email Postfix para o meu domínio, por exemplo, meudominio.com. Ele atua principalmente como um servidor de encaminhamento de email: os usuários recebem um endereço de email @ meudomínio.com, mas geralmente optam por encaminhar seu endereço para uma caixa de entrada externa (Gmail, Yahoo, etc.). Como alguns milhares de endereços estão sendo encaminhados, o servidor lida com um volume bastante significativo de tráfego de mensagens.

No passado, o servidor não usava a reescrita do SRS. Obviamente, isso significava que o correio encaminhado falharia nas verificações do SPF, pois meu endereço IP não está tecnicamente autorizado a enviar emails em nome do domínio do remetente original. No entanto, pelo que vejo, não parece estar causando problemas significativos. Geralmente, nenhuma reclamação de usuários como Gmail, Yahoo etc. parece ser inteligente o suficiente para ignorar as falhas do SPF e entregar as mensagens de qualquer maneira.

Com isso em mente, é realmente necessário habilitar a reescrita do SRS? Estou pensando em habilitá-lo, mas minha principal preocupação é que meu domínio seja colocado na lista negra por enviar spam quando o spam for inevitavelmente encaminhado. A reescrita não faria parecer que eu sou o criador do spam? (Pelo menos, este é meu entendimento ao ler Práticas recomendadas do Gmail para encaminhamento de servidores de email ).

Concedido, eu já estou tomando algumas das precauções recomendadas, como usar o SpamAssassin para adicionar "SPAM" à linha de assunto de spam suspeito antes de encaminhar, não encaminhar spam de alta confiança (15 ou mais pontos) e usar a lista de bloqueio de spamhaus, mas essas medidas não são é perfeito e o spam ainda pode passar despercebido.

A ativação da reescrita do SRS vale a pena se aumentar o risco de ser erroneamente marcada como spammer? Ou seria mais seguro deixá-lo como está e ignorar falhas no SPF?


Sei por experiência própria que alguns provedores de serviços de Internet no Reino Unido rejeitarão os e-mails recebidos que afirmam ser de seus próprios clientes, mas que não foram enviados por seus próprios destinatários. O mesmo também pode se aplicar ao Gmail, Yahoo e AOL. Tais situações só podem ser resolvidas reescrevendo o endereço do remetente.
roaima

Respostas:


8

Parece-me que sua pergunta se resume a " quantos servidores de correio lá fora verificam os registros SPF nos emails recebidos? ". Se é a maioria deles, o SRS é um requisito absoluto para um servidor de encaminhamento; se não for um deles, você não precisa do SRS.

Infelizmente, não posso colocar imediatamente minhas mãos em nenhum trabalho acadêmico sobre isso. Mas como eu verifico o SPF nos emails recebidos, posso afirmar com certeza que alguns servidores de email o verificam. Qualquer um de seus clientes que tiver seu servidor encaminhado para contas no meu servidor perderá o email enviado pelos remetentes que anunciam um SPF que termina (como todos deveriam) -all, a menos que você use o SRS. Portanto, posso dizer com certeza que, sem o SRS, alguns dos emails de seus clientes não serão entregues .

Peço desculpas a Marc por não saber ler alemão, por isso não sei dizer se o PDF que ele cita apresenta argumentos convincentes, mas posso reiterar que, sem o SRS, uma fração do e-mail de seus clientes não será entregue. Não posso dizer qual é essa fração, mas não é zero - e, dado isso, acho que você não tem outra alternativa a não ser executar o SRS.

Concordo que seu servidor não estará ajudando a si próprio encaminhando SPAM, mas, na minha experiência, a maioria dos danos à reputação são causados ​​ao seu endereço IP, não ao domínio envelope-De; isso será feito independentemente do uso do SRS.

A resposta mais profunda à sua pergunta é que, entre o SPF e seu DMARC (subestimado e desrespeitando a Internet), parece-me que os serviços de encaminhamento de correio tiveram seu dia. Eu já exigi que todos, exceto um dos meus usuários, tivessem entrega final no meu servidor e esse usuário precisará mudar ou sair em 2016. Atualmente, muitos sistemas de webmail permitem a integração em várias caixas de correio, coletando e-mails fora do servidor usando IMAP ou POP, e muitos clientes de correio permitem que várias contas IMAP ou POP sejam apresentadas como uma única caixa de entrada integrada; portanto, o encaminhamento não é o benefício da leitura centralizada que costumava ser.

Em resumo, eu diria que você precisa de SRS no curto prazo e de um novo modelo de negócios no longo prazo.


O problema é que o SRS é uma solução para solucionar problemas de encaminhamento do SPF. O SRS reescreve, por exemplo, usuário @ A a A = usuário @ B e os registros SPF de B são os responsáveis ​​então. Problema: B ainda pode forjar endereços! Portanto, alguns estão adicionando hashes de criptografia e carimbos de hora no endereço reescrito. Para que isso funcione em grande escala, é necessária adoção global que não existe. Também funciona apenas se algo estiver sendo encaminhado uma vez, mas não mais. As respostas também são um problema. Lembre-se também de que o SPF é uma técnica para proteger seu próprio domínio de abuso, nada mais.
Marc Stürmer

@ MarcStürmer "O SRS é uma solução para solucionar problemas de encaminhamento do SPF ": sim, é exatamente isso que é. Sabe-se que o SPF quebra o encaminhamento simplista; se você acha que o SRS é um preço que vale a pena pagar, não anuncie um registro SPF. " Problema: B ainda pode forjar endereços ": não para o domínio de A, ou qualquer outro domínio protegido por um registro SPF decente, ou o email será rejeitado no SPF; mas fora isso, sim, pode, e não vejo isso como um problema. "O SPF é uma técnica para proteger seu próprio domínio de abuso, nada mais ": eu concordo.
MadHatter

@ MarcStürmer: "Também funciona apenas se algo estiver sendo encaminhado uma vez, mas não mais." está errado. O SRS funciona completamente bem em vários servidores de encaminhamento. Ele sofre apenas se houver um servidor sem marcação na linha. Mas esse é o mesmo problema que em qualquer servidor sem marcação em geral, seja um salto de avanço inicial ou posterior. Em um mundo SPF, você não precisa do SRS, apenas assume a responsabilidade do correio encaminhado e garante que você possa entregar um possível retorno. SRS é apenas uma técnica que faz isso, o Google, por exemplo, usa algo diferente.
Adrian Zaugg

O problema é que o uso do SRS interrompe a verificação do alinhamento do DMARC (por exemplo, remetente do envelope! = From:Cabeçalho) e fará com que o Gmail rejeite as mensagens se o domínio no From:cabeçalho tiver p=rejectsua política de DMARC. Se você reescrever o From:também, o e-mail será verificado de acordo com as regras do seu próprio domínio. Mas uma verificação DKIM falhará e o remetente mostrado no cliente de email é desconfigurado.
mbirth

@ afaik afaik, você está certo. Mas, pessoalmente, considero o DMARC um desastre completo, até porque ele unilateralmente quebrou as listas de discussão e (na minha capacidade de administrador de uma grande lista de comunidades) simplesmente aconselha as pessoas a não usarem qualquer ISP que publique uma p=rejectpolítica. Se o SRS quebra o DMARC, bem, isso é difícil para o DMARC.
MadHatter

8

O SRS parece ser uma boa ideia no papel, mas na prática não funciona muito bem, de acordo com o pessoal do Suporte da Heinlein (eles estão executando um serviço de correio de tamanho médio com mais de 100000 contas.)

Os detalhes estão em seu discurso, embora em alemão, por que: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

O principal motivo é que o SRS é um pequeno patch para problemas sérios de implementação do SPF na realidade, porque o SPF não cobre muito bem alguns casos de uso comuns de email. Para que o SRS faça sentido, ele precisa ser implantado em uma grande base de servidores, o que é improvável que isso aconteça. Portanto, até que seja implantado nessa grande base de servidores, não faz muito sentido.

O problema com os grandes provedores de correio é que hoje em dia eles têm uma grande base de usuários e estão implementando mais e mais técnicas (o sucessor do DMARC já está no pipeline), o que torna cada vez mais difícil para um usuário normal configuração do servidor de e-mail para enviar e-mails a eles de uma maneira confiável.

Se você deseja que seu e-mail seja entregue melhor aos grandes provedores de e-mail, como Gmail, Hotmail e outros, deve implementar pelo menos DKIM e DMARC, mas também configurá-lo para falhas leves na melhor das hipóteses e talvez implementar alguns mecanismos de limitação de taxa na entrega de e-mails faria maravilhas para você.

Esse problema com os grandes fornecedores é a razão pela qual hoje existem serviços como Mailchimp, Mandrill ou Returnpath. Esses fornecedores pagam dinheiro ao Google & Co. para uma melhor qualidade de entrega.


1
O problema aqui é SPF, não SRS. Desde que alguns ISP usem o SPF, é necessário implementar o SRS (ou algo semelhante) para que o encaminhamento funcione com todos eles. O problema com a lista cinza é diferente, você deve "descompactar" os endereços dos remetentes marcados com SRS para a lista cinza (além dos e-mails marcados com BATV).
Adrian Zaugg

3

Concordo com cada palavra de @MadHatter, MAS fato importante sobre o Google!

Se você fornece um serviço de encaminhamento ao gmail, há uma boa chance de você também fornecer acesso SMTP, para que seus usuários possam enviar e-mails do gmail em nome do endereço armazenado por você.

Nesse caso, o gmail sabe que você é um encaminhador para este e-mail e não sinaliza seus encaminhamentos como spam, mesmo que a verificação SPF falhe.

Você pode enviar e-mails aos seus clientes a partir de bill@microsoft.com. A mensagem chegará à caixa de entrada sem nenhum aviso! (A Microsoft tem -all no registro spf)

Verificado e verificado. Exemplo em anexo.

esta mensagem foi para a caixa de entrada.gmail Mostrar original

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.