Tenho o que eu descreveria caridosamente como um ódio-ódio com o e-mail. Tento desesperadamente evitar o envio de e-mails, não apenas para mim, mas também para o código que escrevo.
Apesar de minhas dúvidas, o e-mail é a barata dos meios de comunicação: o senhor simplesmente não consegue matá-la. O e-mail é o único método de contato on-line que quase todo mundo, pelo menos aquele subconjunto de “todo mundo” que inclui as pessoas que suportam tocar em um computador, tem a garantia de ter e usar. Sim, o senhor pode apresentar um argumento bastante convincente de que o e-mail é para pessoas velhas e estúpidas, mas vamos deixar essa discussão de lado por enquanto.
Portanto, com relutância, chegamos à questão do envio de e-mail por meio de código. É fácil! Vamos enviar alguns e-mails por meio de oh, não sei, digamos … Ruby, cortesia de um código de exemplo que encontrei enquanto navegando na tag Ruby no Stack Overflow.
require 'net/smtp'
def send_email(to, subject = "", body = "")
from = "my@email.com"
body= "From: #{from}\r\nTo: #{to}\r\nSubject: #{subject}\r\n\r\n#{body}\r\n"
Net::SMTP.start('192.168.10.213', 25, '192.168.0.218') do |smtp|
smtp.send_message body, from, to
end
end
send_email "my@email.com", "test", "blah blah blah"
No entanto, há um bug nesse código. O senhor está vendo?
Só porque o senhor enviar um e-mail não significa que ele será recebido. Nem de longe. Lembre-se de que esse é o e-mail de que estamos falando. Ele nunca foi projetado para sobreviver a uma investida amarga de criminosos e spam, sem mencionar o crescimento explosivo e exponencial que teve nos últimos vinte anos. O e-mail é um poço que foi verdadeira e completamente envenenado – o equivalente digital de um local de limpeza de superfundo. O ecossistema em torno do e-mail é um miasma úmido de hacks e soluções alternativas anti-spam implementadas pela metade e com suporte incompleto.
Isso significa que a probabilidade de aquele e-mail aleatório que seu código acabou de enviar chegar ao seu destino específico é… irregular. Na melhor das hipóteses.
Se o senhor quiser que o e-mail que seu código envia seja realmente chegar na caixa postal da AOL de alguém, para os tons suaves de “You’ve Got Mail!”, há algumas coisas que o senhor deve fazer primeiro. E a maioria delas está relacionada apenas perifericamente a escrever código.
1. Certifique-se de que o computador que está enviando o e-mail tenha um registro PTR reverso
O que é um registro PTR reverso? É algo que o seu provedor de serviços de Internet precisa configurar para o senhor, uma forma de verificar se o e-mail enviado de um determinado endereço IP realmente pertence ao domínio do qual ele supostamente provém.
Nem todo endereço IP tem um registro PTR correspondente. Na verdade, se o senhor pegasse uma amostra aleatória de endereços que o seu firewall bloqueou porque não estavam fazendo nada de bom, provavelmente descobriria que a maioria não tem registro PTR – um dig -x não lhe dá nenhuma informação. Isso também pode ser verdade para spammers de e-mail, ou o PTR deles não corresponde: se o senhor fizer um dig -x no IP deles, obterá um resultado, mas se procurar esse resultado, poderá não obter o mesmo IP com o qual começou.
É por isso que os registros PTR se tornaram importantes. Originalmente, os registros PTR eram apenas uma conveniência e, talvez, uma maneira de ser organizado e completo. Ainda não há nenhuma exigência de que o senhor tenha um registro PTR ou que ele seja preciso, mas, devido ao abuso da Internet por spammers, certas convenções se desenvolveram. Por exemplo, talvez não seja possível enviar e-mail para alguns sites se o senhor não tiver um registro PTR válido ou se o seu ponteiro for “genérico”.
Como o senhor obtém um registro PTR? O senhor pode pensar que isso é feito pelo registrador de domínios – afinal, ele aponta seu domínio para um endereço IP. Ou o senhor pode pensar que quem cuida do seu DNS faria isso. Mas o registro PTR não é responsabilidade deles, mas sim do ISP que “possui” o bloco de IP de onde ele veio. São eles que precisam criar o registro PTR.
Um registro PTR reverso é fundamental. Quão crítico? Não se preocupe em continuar lendo até que tenha verificado que seu ISP configurou corretamente o registro PTR reverso para o servidor que enviará o e-mail. Essa é absolutamente a verificação mais comum feita pelos servidores de e-mail atualmente. Se a verificação de PTR reverso falhar, garanto que um enorme porcentagem dos e-mails que o senhor envia vai parar no grande balde de bits no céu, e não nas caixas de entrada de e-mail que o senhor pretendia.
2. Configure o DomainKeys Identified Mail em seu DNS e código
O que é DomainKeys Identified Mail? Com o DKIM, o senhor “assina” cada e-mail que envia com sua chave privada, uma chave que só o senhor poderia saber. E isso pode ser verificado ao tentar descriptografar o e-mail usando a chave pública armazenada em seus registros DNS públicos. É realmente muito inteligente!
A primeira coisa que o senhor precisa fazer é gerar alguns pares de chaves público-privadas (uma para cada domínio do qual deseja enviar e-mail) por meio do OpenSSL. Eu usei o uma versão win32 que encontrei. Emita esses comandos para produzir as chaves nos arquivos abaixo:
$ openssl genrsa -out rsa.private 1024
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
Essas chaves públicas e privadas são apenas grandes strings codificadas em Base64, portanto, coloque-as em seu código como recursos de string de configuração que podem ser recuperados posteriormente.
Em seguida, adicione alguns registros DNS. O senhor precisará de dois novos registros TXT.
- _domainkey.example.com
“o=~; r=contact@example.com” - selector._domainkey.example.com
“k=rsa; p={public-key-base64-string-here}”
O primeiro registro DNS TXT é a política global do DomainKeys e o e-mail de contato.
O segundo registro DNS TXT é a chave pública base64 que o senhor gerou anteriormente, como uma cadeia gigante e ininterrupta. Observe que a parte “selector” desse registro pode ser o que o senhor quiser; basicamente, é apenas uma cadeia de caracteres de desambiguação.
Quase pronto. Uma última coisa: precisamos assinar nossos e-mails antes de enviá-los. Em qualquer mundo racional, isso seria feito por uma biblioteca de e-mail de algum tipo. Usamos Mailbee.NET o que torna isso bastante simples:
smtp.Message = dk.Sign(smtp.Message,
null, AppSettings.Email.DomainKeyPrivate, false, "selector");
3. Configure um registro SPF / SenderID no seu DNS
Para ser sincero, ID do remetente é um pouco “bom de se ter” em comparação com os dois anteriores. Mas se o senhor já chegou até aqui, é melhor ir até o fim. O SenderID, apesar de ser um pouco antiquado e meio… centrado na Microsoft/Hotmail. centrado na Microsoft/Hotmail… não exige muito esforço adicional.
O SenderID não é complicado. Trata-se de outro registro DNS TXT na raiz de, por exemplo, example.com, que contém uma cadeia de caracteres especialmente formatada que documenta todos os endereços IP permitidos de onde se espera que o e-mail venha. Aqui está um exemplo:
"v=spf1 a mx ip4:10.0.0.1 ip4:10.0.0.2 ~all"
O senhor pode usar o Assistente de registro SPF de ID de remetente para gerar um desses registros para cada domínio do qual o senhor envia e-mails.
Isso foi péssimo. Como posso saber se todo esse lixo está funcionando?
Concordo, foi péssimo. O e-mail é uma porcaria; o que o senhor esperava? Usei dois métodos para verificar se todos os itens acima estavam funcionando:
- E-mails de teste enviados para uma conta do GMail.
Use o menu “show original” no e-mail que está chegando para ver o conteúdo bruto da mensagem, conforme visto pelo servidor de e-mail. O senhor deseja verificar se os cabeçalhos contêm definitivamente o seguinte:
Received-SPF: pass Authentication-Results: ... spf=pass ... dkim=pass
Se o senhor vir isso, então o PTR reverso e a assinatura DKIM que configurou estão funcionando. O Google fornece excelente feedback de diagnóstico nos cabeçalhos de seus servidores de e-mail, portanto, se algo não estiver funcionando, o senhor geralmente pode descobrir uma dica suficiente para descobrir o motivo.
- E-mails de teste enviados para o verificador de e-mail Port25
O Port25 oferece um serviço público muito bacana: o senhor pode enviar um e-mail para check-auth@verifier.port25.com e ele responderá ao endereço from: com um diagnóstico abrangente! Veja um exemplo de resultado resumido de um e-mail de teste que acabei de enviar para ele:
SPF check: pass DomainKeys check: fail DKIM check: pass Sender-ID check: pass SpamAssassin check: ham
O senhor deseja ser aprovado no SPF, DKIM e Sender-ID. Não se preocupe com a falha do DomainKeys, pois acredito que ela seja espúria – o DKIM é a versão mais “nova” desse mesmo protocolo.
Sim, as três etapas acima são bastante trabalhosas apenas para enviar um e-mail de baixa qualidade. Mas eu não envio e-mails levianamente. Quando chego ao ponto em que sou forçado a escrever código para enviar e-mails, o senhor já sabe o que fazer, Eu realmente, realmente quer que esses malditos e-mails cheguem. Por qualquer meio necessário.
E para aqueles que são os infelizes destinatários desses e-mails: minhas condolências.