IPs usados no envio

Tente fazer os seus envios usando poucos endereços IPs, e que sejam consistentes. Se os seus emails estão saindo de vários IPs de redes diferentes, os servidores de destino podem achar que seu sistema está falsificando os IPs de envio, ou usando alguma rede para fazer o envio (botnets, por exemplo). Com isso, sua chance de ter o email marcado como spam aumenta bastante.
Se você se limita a fazer o envio a partir de um único IP, ou poucos IPs, não vai sofrer com esse tipo de problema. Além disso, os provedores agora trabalham com o conceito de “reputação” de um IP. Ou seja, se você envia emails consistentemente através de um IP, e esses emails tem taxa de reclamação baixa, a tendência é que a reputação suba.

DNS reverso

O sistema de DNS serve para traduzir nomes para IPs. Por exemplo, quando digita “www.ataraxia.com.br” no seu navegador, ele é traduzido para um endereço IP (no momento em que escrevo, 75.119.213.142). Hoje em dia, o DNS é essencial para o funcionamento da Internet.
Assim como existe a tradução de nomes para IPs, tambem existe a tradução inversa, ou seja, de IPs para nomes. E é importantíssimo que o endereço IP do seu servidor de email possa ser traduzido de volta para o nome dele.
Servidores que não tem DNS reverso cadastrado e apontando de volta para ele mesmo normalmente não conseguem mandar email de forma consistente, pois a maior parte dos filtros já barra a conexão antes mesmo de receber a mensagem. Ou seja, o conteúdo nem mesmo é analisado.

Use um remetente consistente

O remetente é o nome e email que aparecem para quem recebe o email. Tente usar o mesmo para a campanha inteira. Colocar nomes e emails diferentes para cada email que sai é mais um indício de spam, pois spammers falsificam essas informações para tentar ocultar sua identidade. Coloque no remetente algo que deixe bem claro quem você é.

Publique registros SPF

O SPF é um framework que utiliza registros DNS para divulgar informações sobre permissão de envio de emails, e tem a intenção de combater o envio de emails falsificados.
Um registro SPF indica para o mundo quem tem permissão de mandar emails usando um domínio. E como quem tem controle sobre um domínio e seus registros é normalmente a organização detentora da marca, seria uma forma da organização dizer: “somente os servidores X, Y e Z podem mandar email usando minha marca”.
Todos os grandes provedores checam registros SPF, e um email que falhe nessa checagem já é mais um indicativo de possível falsificação de email.
Não vou colocar um tutorial sobre SPF nesse artigo, pois foge um pouco do escopo, mas para saber mais sobre a tecnologia, e como implementar, basta visitar o site http://www.openspf.org/. Existe tambem um ótimo assistente para geração do registro SPF para publicação no servidor DNS.

Assinaturas DomainKeys e DKIM

DomainKeys é uma tecnologia que usa criptografia para verificar o domínio de quem enviou a mensagem, e a integridade das mensagens. É usada principalmente pelo Yahoo!, e foi usada como base pelo IETF para o desenvolvimento do DKIM (DomainKeys Identified Mail), sucessor do DomainKeys.
A idéia é usar duas chaves, uma pública e uma privada. A chave privada fica guardada no servidor que faz o envio, e cada email é assinado digitalmente usando essa chave privada. A chave pública é disponibilizada via DNS, e qualquer um que receba um email assinado usando a DomainKeys e/ou DKIM pode verificar se a mensagem foi realmente enviada por um servidor autorizado, checando a assinatura através da chave pública.
Além disso, a assinatura garante também que a mensagem não foi modificada em trânsito, pois caso tenha sido modificada, a assinatura não vai conferir.
Embora o DKIM tenha vindo para ser o sucessor do DomainKeys, a maior parte dos grandes provedores checam as duas assinaturas, então não existe problema em assinar a mensagem duas vezes, pois ambas coexistem sem problema.

Lista de emails

Qualquer email que esteja na sua lista deve ter dado a permissão explícita para que você faça o envio de emails. Qualquer inscrição deve preferencialmente utilizar o mecanismo de “double opt-in”, ou seja, a pessoa coloca seu email em um formulário no seu site, você envia um email de confirmação com um link, e só adiciona a pessoa na sua lista após essa confirmação. Isso evita a adição de pessoas que não pediram para ser cadastradas, e com isso, evita reclamações.

Manutenção da lista

A regra número 1 é bem simples: respeite seus usuários. Se alguem não quer mais receber seus emails, não envie mais. Vai ser um usuário a menos gerando reclamações. Não vale a pena forçar seus emails goela abaixo dos usuários.
Todo email que você enviar deve conter um link para que o usuário possa sair da lista. Esse link deve funcionar, de preferência de forma automática e imediata.
Além disso, qualquer email que gere um “bounce” deve ser removido da lista, caso seja um erro permanente (por exemplo, “email inexistente”). Erros não permanentes (por exemplo, “caixa postal cheia”) devem ser removidos caso persistam por alguns envios.

Formato do email

Todas as mensagens devem seguir o padrão descrito na RFC 5322. Esse padrão é o sucessor da RFC 2822, que por sua vez é o sucessor da RFC 822. Esse padrão descreve o formato que um email deve seguir.
Caso envie emails em HTML, siga os padrões descritos pelo W3C.
Adicione sempre o cabeçalho “Precedence: bulk”, para sinalizar ao servidor de destino de que seu email faz parte de um envio em massa. Isso ajuda o servidor que recebe a priorizar melhor a entrega das mensagens, caso esteja sobrecarregado.
O assunto do email deve ser relevante, e ter relação com o conteúdo da mensagem.

O email em si

Evite uso de palavras chaves normalmente associadas a spam. Evite o uso de pontuação em excesso, como por exemplo, muitas exclamações.
Caso esteja enviando email em HTML, não esqueça de fazer tambem uma versão em texto puro, para quem não lê HTML. Por exemplo, muitos dispositivos móveis não lêem emails em HTML. Além disso, emails somente em HTML muitas vezes ganham uma pontuação nos sistemas antispam.
No HTML, evite colocar somente imagens. Tente manter uma boa proporção de texto para imagem. Siga os padrões da W3C, colocando o atributo “alt” nas imagens. Além disso, lembre-se que por padrão, os grandes provedores não exibem imagens externas por padrão, então caso seu email contenha somente imagens, existe uma boa probabilidade do email não ser lido.

Blacklists e whitelists

Tente fazer monitoramento constante nas várias listas negras existentes na Internet. Caso seu servidor seja listado, começará a ter problemas de entrega, pois qualquer servidor configurado para checar a lista negra irá barrar sua conexão. Tente trabalhar de forma a evitar a entrada nessas listas, e caso entre, tente corrigir o problema e providenciar a saída o mais rápido possível.
Assim como existem as listas negras, existem tambem listas brancas, de servidores que foram cuidadosamente verificados, e que fazem envio de email de forma responsável. A mais famosa é a certificação SenderScore da ReturnPath. Existe um custo, mas por sua vez, uma vez certificado, basta manter as boas práticas para conseguir melhores taxas de entrega para grandes provedores, como Hotmail e Yahoo!.

Conclusão

Resumindo: mandar emails para a Internet de forma consistente é um verdadeiro inferno hoje em dia. E acredite, você certamente terá problema de entregas uma hora ou outra. Não tem muito pra onde fugir. Mas seguindo essas regras (simples?), dá pra se manter o nível de rejeição em um patamar aceitável.
Alguem tem alguma dica extra? Postem nos comentários!

Artigos relacionados

• Evitando spam em formulários
• Evitando fornecer seu email verdadeiro
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Acessando sites fora do ar
• Envio de emails em PHP
• Segurança no envio de emails em PHP

Porém, tão importante quanto minimizar o número de conexões, é ter certeza de que a quantidade de dados transferidos seja sempre a menor possível. Como vimos antes, o Minify já ajuda nesse sentido, pois retira dos scripts e das folhas de estilo caracteres desnecessários como espaços em branco e quebras de linha.

Este artigo não é específico de PHP, pois lida uma camada abaixo, direto no protocolo HTTP. As soluções apresentadas aqui podem ser implementadas diretamente na linguagem, mas ficam bem melhores se implementadas no servidor (Apache, no caso), como demonstrado neste artigo.

Começando com o HTTP 1.1, os navegadores podem especificar formas de codificação aceitáveis para o conteúdo, através do cabeçalho Accept-Encoding. Por exemplo, utilizando:

Accept-Encoding: gzip, deflate

o navegador indica para o servidor web que pode receber o conteúdo solicitado de forma comprimida, utilizando um destes dois métodos (gzip ou deflate). Caso o servidor possa comprimir utilizando uma das formas solicitadas, irá retornar um cabeçalho Content-Encoding, informando a codificação usada, como por exemplo:

Content-Encoding: gzip

A codificação mais popular hoje em dia é o gzip, que é uma especificação aberta e bem documentada pela RFC 1952. A outra codificação (deflate) também pode ser usada, mas é menos popular e menos eficiente que o gzip.

A codificação gzip consegue comprimir conteúdo texto (HTML, CSS, JavaScript, e outros) em aproximadamente 70%. Levando-se em consideração que mais de 90% dos navegadores atualmente em uso suportam esta compressão, é altamente recomendável configurar o servidor web para comprimir arquivos texto.

Para o Apache, dependerá da versão utilizada. O Apache 1.3 utiliza o mod_gzip, enquanto que o Apache 2.x usa o mod_deflate. Como o Apache 1.3 já não é muito utilizado, vou mostrar os exemplos para o mod_deflate.

Devemos levar em conta que somente arquivos texto devem ser comprimidos. Arquivos binários, como imagens, áudio e vídeo em geral já estão em um formato comprimido, e colocar mais compressão em cima, além de não diminuir o tamanho do arquivo (pelo contrário, as vezes até aumenta!), causa também desperdício de CPU para o servidor.

A configuração do mod_deflate em geral é feita especificando quais tipos de arquivo serão comprimidos. Em geral, arquivos texto devem ser comprimidos. Podemos, por exemplo, especificar que alguns tipos devem ser comprimidos utilizando diretivas de Apache como:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript text/x-json

A primeira linha liga o mecanismo de compressão do mod_deflate, e a segunda especifica alguns tipos que devem ser comprimidos. No caso, estou informando ao servidor que arquivos tipo HTML, texto puro, XML, CSS, JavaScript e JSON devem ser comprimidos. Alguns navegadores mais antigos podem ter problemas com a compressão gzip, mas felizmente isto é coisa do passado. De qualquer forma, a página com a documentação do mod_deflate mostra como desligar a compressão de acordo com o navegador usado.

Um bom site para se testar se o servidor está configurado corretamente para servir conteúdo comprimido é o mod_gzip Test. Basta colocar a URL do site e clicar em “Test” para saber se o servidor está preparado para servir conteúdo comprimido.

Artigos relacionados

• Otimização em PHP, parte 1: Minify
• Otimização de sites, parte 3 – Cache
• Envio de emails em massa
• Otimização de sites com memcached
• Otimização: imagens inline
• Acessando sites fora do ar
• Páginas de manutenção

Existem alguns fatores que influenciam no tempo de carregamento de uma página:

• Tamanho total dos dados
• Tempo de geração da página
• Número de conexões HTTP necessárias

O tamanho total dos dados é de extrema importância, pois quanto mais dados pra se transferir (páginas, imagens, folhas de estilo, scripts externos, etc), maior o tempo de carregamento de uma página. O tempo de geração também é importante, e este tempo depende de uma programação eficiente e de um banco de dados rápido.

Porém, o número de conexões necessárias é frequentemente esquecido, e é um fator de extrema importância para que uma página seja carregada rapidamente.

Para entendermos o porque, precisamos saber o que o navegador faz quando pedimos para ele abrir uma página.

Primeiramente, é realizada uma consulta ao servidor DNS para se determinar o endereço do servidor que estamos tentando acessar. Esta consulta leva algum tempo, mas normalmente é cacheada pelo navegador uma vez feita. Num segundo passo, temos a primeira conexão, que baixa a página que foi pedida.

Após a busca da página, o navegador analisa sua estrutura, e busca elementos externos necessários, como imagens, folhas de estilo (CSS), scripts, arquivos de Flash, etc etc.

Cada elemento externo a ser baixado exige a abertura de mais uma conexão HTTP (nem sempre… existe pipelining e outras coisas que melhoram isso, mas pra simplificar, vou ignorar por enquanto). Cada conexão, para ser estabelecida, leva um tempo antes da transferência de dados ser iniciada. Este overhead gera um atraso, visto que muitas vezes, dependendo do tamanho do arquivo, o tempo para se estabelecer a conexão chega a ser maior que o tempo para se baixar o arquivo.

Some-se a isso uma regra que diz que navegadores devem abrir no máximo 2 conexões simultâneas por host. Ou seja, se a página possui 30 elementos externos a serem baixados, as conexões serão estabelecidas duas a duas até que os 30 sejam completados. Algo que se pode fazer para melhorar isto é dividir os elementos externos em alguns hosts diferentes, já que a regra manda 2 conexões por host, mas isto fica para mais adiante.

Muitas vezes, uma página possui vários arquivos CSS e vários scripts em JavaScript. Ao invés de utilizar, digamos, 5 tags para se carregar 5 arquivos CSS diferentes, e mais 10 tags para carregarmos 10 scripts externos, não seria muito melhor se pudéssemos abrir apenas duas conexões, e baixar todo o CSS em uma, e todo o JavaScript em outra? E melhor, que ao fazer isto eles já viessem “condensados”, de forma a diminuir seu tamanho?

Pois bem, a idéia do Minify é justamente fazer isto. O Minify é um script em PHP que recebe uma lista de arquivos como parâmetro (CSS ou JavaScript) e “junta” todos eles em um único download (ele faz mais, mas para mais detalhes, veja direto na página do Minify).

Para fazer a instalação, tudo muito simples. Basta descompactar o arquivo na raiz do site, e fazer algumas modificações nas tags. Ao invés de termos:

<script type="text/javascript" src="/js/script1.js"></script>
<script type="text/javascript" src="/js/script2.js"></script>
<script type="text/javascript" src="/js/script3.js"></script>
<script type="text/javascript" src="/js/script4.js"></script>
<script type="text/javascript" src="/js/script5.js"></script>

passamos a ter somente:

<script type="text/javascript" src="/min/?f=/js/script1.js,/js/script2.js,/js/script3.js,/js/script4.js,/js/script5.js"></script>

Ou seja, chamamos somente o “/min/”, e passamos como parâmetro (chamado f) uma lista com os scripts, separados por vírgulas, e o Minify se encarrega do resto. Com o CSS, a mesma coisa. Ao invés de termos:

<link rel="stylesheet" type="text/css" href="/css/style1.css" />
<link rel="stylesheet" type="text/css" href="/css/style2.css" />
<link rel="stylesheet" type="text/css" href="/css/style3.css" />
<link rel="stylesheet" type="text/css" href="/css/style4.css" />
<link rel="stylesheet" type="text/css" href="/css/style5.css" />

teremos somente:

<link rel="stylesheet" type="text/css" href="/min/?f=/css/style1.css,/css/style2.css,/css/style3.css,/css/style4.css,/css/style5.css" />

Apenas usando o Minify, já podemos conseguir baixar o número de conexões HTTP necessárias para se carregar a página inteira, e com isso, diminuir o tempo total.

Um site interessante, que fornece um mapa com todos os elementos do site, assim como o tempo de carregamento de cada um é o Full Page Test do Pingdom. O tempo de cada elemento é dividido em 3: tempo para se começar, tempo para se estabelecer a conexão e a transferência em si. Olhando bem, dá pra perceber que o tamanho das páginas (parte azul da barra) tem uma influência menor do que o número de conexões.

Existem outras técnicas, que podem ser usadas em conjunto com o Minify para melhorar ainda mais, mas ficarão para os próximos artigos da série.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização de sites, parte 3 – Cache
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Envio de emails em massa
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Evitando SQL injection em PHP
• Otimização: imagens inline
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Precedência no PHP
• Acessando sites fora do ar
• Páginas de manutenção
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

Um destes artifícios é usar um CDN, uma rede com servidores espalhados pelo mundo, que fazem cache de quase tudo na Internet.

Um CDN bastante popular é o Coral CDN. Pra usar, é bem fácil. Pegue o endereço do site que você deseja acessar, e coloque “.nyud.net” no final do nome do host.

Por exemplo, se o endereço que você está tentando acessar é o deste site (que acredito não estar fora do ar, já que você está lendo), bastaria pegar o endereço http://www.ataraxia.com.br/ e transformar em http://www.ataraxia.com.br.nyud.net/.

Pronto, você vai ter acesso a uma “réplica” do site, e se a informação procurada já tiver sido cacheada, vai ser encontrada lá.

Outra opção, que também está disponível, é verificar se o Google possui a página em cache. Isso é bem fácil. Basta colocar a URL do site na busca do Google, e ao invés de clicar no link para o site, clicar logo abaixo, onde aparece “Em Cache”. Este link te levará para o cache que o Google tem da página em questão, da última vez em que a visitou. Um problema nisso é que normalmente as imagens não são cacheadas, e se o site estiver fora do ar, as imagens não serão carregadas. Mas não deixa de ser uma alternativa, caso o CDN falhe.

Artigos relacionados

• Envio de emails em massa
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify