Category Archives: Tech Info

PowerMTA não inicializa? Pergunte-me como!

Sim, o PowerMTA, melhor MTA (mail transfer agent) do mercado, aquele cara que faz o papel do “servidor SMTP” no ecossistema de e-mail marketing, é meio obscuro e com pouco acesso a documentação. Tem um fórum excepcional mantido pela própria empresa mantenedora, a Port25, mas tem muita gente aí no mercado usando o sistema com configurações automatizadas (tá cheio de gente “vendendo” isso) mas que, na hora de um problema mais sério, não sabe como resolver. Sequer se dão ao trabalho de olhar o manual do sistema (sim, manuais servem para várias coisas). Hoje me chamaram por causa de um desses problemas.

O que fazer quando o PowerMTA (pmtad) não inicializa? Não consigo enviar e-mails!

Bem, quando o PowerMTA não inicializa, o que faço é muito simples: troubleshooting!!!!

  1. Já viu se tem espaço em disco? Um simples “df -h” nos mostra isso

    comando df -h

    comando df -h

  2. O cliente disse que não iniciava, mas vamos ver se é isso mesmo. “service pmtad restart”

    service pmtad restart

    service pmtad restart

  3. Já que deu falha na tentativa de inicialização, vamos olhar o log do sistema. Uma das coisas que aprendi e que é importante lembrar é que quando um sistema tem seu próprio arquivo de log, ele só registra alguma coisa alí quando seu prórpio processo está em execução. Aqui não é o caso! O processo do PowerMTA (pmtad) simplesmente não inicializa, logo, o erro tem que estar registrado em outro lugar e, por experiência, de fato, esse registro de erro “pré-start” vai para o /var/log/messages.log (falando de uma distribuição linux redhat-based)

    Verificando os logs do pmta no messages.log

    Verificando os logs do pmta no messages.log

  4. A última linha do arquivo de log messages.log mostra que há um problema no arquivo onde o PowerMTA guarda os status das queues/ips desativados. Essas queues e IPs são desativados conforme configuração. Para saber mais a respeito é só me chamar. Para resolver, temos duas formas de agir: A primeira é acessar o arquivo e ir acertando conforme o PowerMTA for registrando em log um erro…. dependendo do tamanho do sistema, isso pode levar um booooom tempo ;) A outra forma é simplesmente “detonando” (deletando, removendo, apagando, jogando no lixo) esse arquivo e deixando o próprio PowerMTA recriá-lo

    Arquivo disabled-sources do PMTA

    Arquivo disabled-sources do PMTA

  5. Eis que, enfim, vem o start do sistema!

    service pmtad restart SUCESSO!

    service pmtad restart SUCESSO!

Porque isso aconteceu?

É como eu disse aí em cima: o PowerMTA é um sistema que requer conhecimento para manutenção do próprio sistema, da entregabilidade, da saúde dos IPs e queues etc. Muito disso só vem com o uso, experiência, pesquisa e muita dor de cabeça. O manual do sistema é bom mas não é excelente e muitos usuários do sistema que entram em contato comigo com problemas tem pouco conhecimento nessa parte da manutenção.

Esse problema especificamente eu vejo acontecer quando o servidor foi desligado inesperadamente, quando o disco lotou e o processo do PowerMTA foi desligado pelo próprio sistema ou quando há um problema com a partição lógica ou com o disco físico. Aqui nesse caso, o disco não estava cheio mas o uptime do servidor estava abaixo de 1 hora, o que me leva a acreditar que o PowerMTA parou de funcionar por falta de espaço, o cliente tentou reiniciar o servidor, o mesmo continuou não funcionando, o cliente então viu que não havia espaço em disco disponível e fez uma limpeza emergencial (não olhei os historicos de comandos para saber mas poderia ;) ), tentou reiniciar o sistema de novo, mas não funcionou. Enfim, vou repetir: experiência é tudo quando falamos de sistemas pouco conhecidos. PowerMTA não é como um Windows, um Linux, um Postfix, um Exim ou um Sendmail (ou um Exchange :P) e também não é um sistema que não precisa de manutenção e monitoramento. Tudo precisa ser monitorado!

Meu iptables não funciona. O que é firewalld?

Pois é! No CentOS 7/RHEL 7 o iptables não é a ferramenta padrão de gerenciamento de firewall. O NETFILTER agora é gerenciado pelo novo daemon firewalld. Eu gosto de aprender e consequentemente a minha atitude usual seria “destrinchar” a nova ferramenta. Entretanto, a urgência em ativar um novo servidor de emails, me fez decidir por insistir no uso do iptables, que eu já conheço bem, que eu já venho usando por anos a fio. Prometo que o próximo servidor que eu usar com CentOS7, irei mais a fundo em firewalld.

Desativando firewalld

Para desativar o firewalld basta executar os comandos abaixo:

  1. systemctl mask firewalld
    Esse comando “detona” todo o arranjo de zonas de segurança que o firewalld cria
  2. systemctl disable firewalld
    Com esse comando, o firewalld nunca mais irá incomodar, só se você decidir que sim.

Reativando iptables

Aqui precisamos instalar os comandos e ativar o daemon iptables

  1.  yum install iptables
    Com yum, tudo é mais fácil, não? ;)
  2. systemctl enable iptables
    Com esse comando aqui, o iptables volta a ser o seu gerenciador de firewall.

Pronto! Agora você já pode voltar a usar os bacanas iptables-save, iptables-restore, /etc/sysconfig/iptables-config e /etc/sysconfig/iptables.

 

Habilitando Multiplos Endereços IP

Olá,

Voltando ao trabalho mais técnico, tenho um servidor novo para configurar. Com CentOS 7 + Postfix + OpenDkim, ele fará o transporte de diversas campanhas de email marketing. Trata-se de um cinzento que quer aumentar seus envios e para isso contratou 256 endereços IP de um datacenter Russo.

Classicamente, para se ter multiplos endereços IPs configurados em um sistema Redhat-like como o CentOS, basta seguir as instruções abaixo até o passo 2. Entretando, CentOS 7 requer mais passos (3 e 4):

  1. Verificar qual a interface de rede que receberá os IPs adicionais -o comando ip link me mostra a interface ativa (UP)
    comando-ip-link
  2. Configurar o arquivo “range” para essa interface – no meu caso a interface é a enp1s0f1configurar-range-fileO conteúdo do arquivo (ifcfg-enp1s0f1-range0) deve conter as linhas com o primeiro e último endereços IP do range, a máscara de rede e um identificador para cada interface “clonada” (sim, é isso que o arquivo de range faz)
    conteudo-range-fileBasta agora reiniciar o serviço de rede. Maaaas… para CentOS 7, temos mais algumas coisas para fazer, a seguir…
  3. Desativar o bendito serviço NetworkManager – editar o arquivo de configuração da interface enp1s0f1 e acrescentar a linhaNM_CONTROLLED=NO
    configurar-nm_desativadoSem isso, essa porcaria não funcionaria nem com reza brava….
  4. Agora sim, reiniciar os serviços de rede com o comando systemctl restart network (sim, nada mais de service network restart… vamos usar o novo jeito) e tudo deve funcionar bem com os IPs no ar.

Esse é o jeito para configurar um range relativamente grande de IPs. Para configurar alguns poucos IPs, há um jeito diferente. Repare que no screenshot do item 3, temos algumas linhas interessantes:

IPADDR0: x.x.x.x (endereço ip zero, uhum…)
PREFIX0: xx (cidr ref. a mascara de rede do ip zero, bom….)
GATEWAY0: x.x.x.x (gateway do ip zero, é opcional…)

Sendo assim, para alguns poucos endereços IPs adicionais, basta configurar

IPADDR1: y.y.y.y
PREFIX1: yy
IPADDR2: z.z.z.z
PREFIX2: zz
IPADDR3: w.w.w.w
PREFIX3: ww

Bacana, não? Estamos falando de incluir vários endereços IPs no mesmo arquivo de configuração da interface enp1s0f1, que no meu caso é a que me interessa. Vivendo, pesquisando, estudando e aprendendo! ;)

UPDATE em 05/12/2017

Acrescente o parâmetro abaixo ao seu arquivo e evite ficar DIAS esperando as interfaces do servidor subir por estar verificando via ARP se mais alguém está usando o IP da interface:

ARPCHECK=no

Agora sim, só alegria!

 

VirtualHost no Apache 2.4 em VPS rodando CentOS 7

Não sou expert em webserver mas há tempos uso o Apache para os projetos onde sou envolvido. Com o tempo algumas coisas se tornam “automáticas” devido a repetição, o que está mudando com o uso dos automatizadores como Chef ou Puppet. Mas o fato é que com o advento do Apache 2.4 vindo por padrão no CentOS 7, algumas coisas básicas mudaram:

Versão do Apache me execução em uma VPS com CentOS 7:
# apachectl -v
Server version: Apache/2.4.6 (CentOS)
Server built: Jul 23 2014 14:48:00

“NameVirtualHost: *80″

Essa instrução, usada para “ativar” o uso de virtual hosts no webserver, não é mais usada no Apache 2.4 e deve ser totalmente removida.

“Order Allow,Deny
Allow from all”

Essas instruções, muito usada principalmente em sites pequenos sites de intranet e projetos menores também não é mais usada (uma pena! Eu gostava dela :D). Era uma forma simples de controla o acesso, principalmente por IP, ao site/recurso. No caso acima, a galáxia toda seria permitida. Bem, o fato é que se você quiser usar esse recurso novamente (dá-lhe saudosismo) pode reativá-lo carregando um módulo específico:

LoadModule access_compat_module modules/mod_access_compat.so

A nova forma de controlar o acesso ao seu site é usando a instrução “require”. Veja o exemplo abaixo com as linhas em destaque:

<VirtualHost *:80>
 ServerName quebratudo
 ServerAlias quebratudo
 DocumentRoot /var/www/quebratudo
   <Directory "/var/www/quebratudo">
     AllowOverride All
     Require local
     Require ip 192.168.3
   </Directory>
</VirtualHost>

Acesso liberado para a rede local + rede 192.168.3.0/24

Done!!!

 

Ioncube Loader

Existem 2 sistemas de e-mail marketing que permitem instalação em uma infraestrutura própria e disputam a preferência de quem quer oferecer soluções customizadas: Interspire Email Marketer e Octeth Oempro. Ambos tem como pré-requisito o uso de ioncube loader para PHP. Ioncube é usado para criptografar e acelerar o carregamento de arquivos php.

A instalação e carregamento é muito simples:

Download:

# wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz

Extração:

# tar xvfz ioncube_loaders_lin_x86-64.tar.gz -C /opt/
ioncube/
ioncube/ioncube_loader_lin_5.0.so
ioncube/ioncube_loader_lin_4.3.so
ioncube/ioncube_loader_lin_4.2.so
ioncube/ioncube_loader_lin_5.6.so
ioncube/ioncube_loader_lin_5.3.so
ioncube/ioncube_loader_lin_5.5_ts.so
ioncube/ioncube_loader_lin_5.4.so
ioncube/ioncube_loader_lin_4.3_ts.so
ioncube/ioncube_loader_lin_5.5.so
ioncube/ioncube_loader_lin_5.4_ts.so
ioncube/ioncube_loader_lin_5.3_ts.so
ioncube/ioncube_loader_lin_4.4.so
ioncube/ioncube_loader_lin_4.4_ts.so
ioncube/ioncube_loader_lin_5.2.so
ioncube/ioncube_loader_lin_4.1.so
ioncube/ioncube_loader_lin_5.1_ts.so
ioncube/ioncube_loader_lin_5.0_ts.so
ioncube/ioncube_loader_lin_5.1.so
ioncube/ioncube_loader_lin_5.6_ts.so
ioncube/ioncube_loader_lin_5.2_ts.so

Agora é só editar o arquivo /etc/php.ini e inserir a linha abaixo logo no início do arquivo:

 zend_extension = /opt/ioncube/ioncube_loader_lin_5.4.so

Feito isso e arquivo salvo, basta fazer o reload do seu web server ou application server.

Em um arquivo com phpinfo() você consegue conferir o módulo carregado:

Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with the ionCube PHP Loader v4.7.1, Copyright (c) 2002-2014, by ionCube Ltd.

Done!!!!

Coisas Legais do CentOS 7

Sempre me dei bem com distribuições linux redhat-like e por isso sempre me dei muito bem mesmo com CentOS. A versão 7 tem um monte de coisa nova. Resolvi atender com CentOS 7 um cliente antigo que queria novos servidores no ar.

Cadê o bendito ifconfig????

Bem, conheço as ferramentas ip (iptools) mas sempre uso ifconfig. Pois eis que no CenOS7 usamos ip addr e ip link para saber sobre nossas interfaces. Saudoso como sou, instalei o pacote que precisava para ter o ifconfig funcionando

# yum install net-tools

done!!!!

Cadê meus scripts init.d ????

Já era!!! /etc/init.d/nome-do-serviço reload já era! Agora o negócio é usar o comando systemctl:

# systemctl –help
systemctl [OPTIONS...] {COMMAND} …

Query or send control commands to the systemd manager.

-h –help Show this help

done!!!

 O que mais mudou???

Com certeza mais uma penca de coisas.  Com certeza muito mais eu vou descobrindo conforme uso o novo sistema. Mas eu confio nas mudanças da comunidade opensource. Consigo lidar com elas muito bem. Já na outra comunidade…. é preciso estar sempre muuuito atento!!!

Trocando senha de usuários MYSQL

Para trocar senhas de usuário MYSQL/MariaDB (table user, database mysql):

SET PASSWORD [FOR user] =
    {
        PASSWORD('cleartext password')
      | OLD_PASSWORD('cleartext password')
      | 'encrypted password'
    }

Exemplo:

MariaDB [mysql]> set password for ‘o-tal-do-user’@'o-tal-do-host’ = password(‘blablabla’);

Done!

Gmail, E-mail e limites

Error: "421 4.7.0 [xxx.yyy.aaa.kkk 15] Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines. l5si769520oej.102 - gsmtp"

Pois bem! Essa é uma mensagem de bloqueio típica dos servidores de entrada (MX) de e-mail do Google. A mensagem é bem clara informando que você ainda não foi completamente bloqueado e sim o seu tráfego está sendo digamos “limitado”.

O Google confia fortemente em suas políticas para envio/recebimento de e-mails em massa e não é para menos. Se você gerencia bem a sua caixa postal, os sistemas de classificação deles são excelentes. Eu particularmente não troco minhas contas gmail.

Para contornar esse problema verifique o que está sendo enviado pelo IP que está recebendo esta mensagem:

  1. Sua lista é qualificada? Estamos falando de contatos interessados em seu conteúdo?
  2. Você não comprou essa lista de e-mails na esquina, certo?
  3. Está usando todos os mecanismos de autenticação de infraestrutura (servidores, dominios, conexões) ?
  4. Está sendo bondoso ao estabelecer a relação “Endereços IP x Volume” e “Conexões x Limite de e-mails”?
  5. Já leu o “Bulk Senders Guide” fornecidos pela gigante?
  6. Quer ajuda? Entre em contato! 

 

Tinha alguém no meu PMTA. Open-Relay Sucks!

Peguei um PowerMTA mal configurado com restos de filas (queues) de e-mails como aquelas que o pessoal da Coréia e do Japão gostam de criar… Sim! Tudo indica que esse servidor um dia esteve open-relay (essa conversa dá um outro artigo sobre powermta open-relay).

O problema já tinha sido resolvido com firewall, autenticação e reorganização dos arquivos de configuração do MTA e sendo assim, faltava apenas apagar essas benditas filas. Nenhum “estrago” foi feito aos IPs pois como o(s) IP(s) de origem que submeteram os e-mails para retransmissão não eram permitidos, o resultado foi que tudo o que  estava enfileirado, estava em uma queue desativada. O único problema foi que quase 100% do HD foi consumido com filas inúteis (em 85% o Nagios gritou!!!).  Sorte este ser um servidor virtual com apenas 5 GB de disco. Quando me foi pedido que verificasse, o servidor já havia voltado a uso. Veja:

Queues no PMTA

Queues no PMTA

Bem, nada que um bom scriptzinho em Bash não possa resolver, para diferenciar o que é fila antiga do que é fila nova, um Grep na saida do comando pmta ajuda:

Deletando filas desativadas no PMTA

Deletando filas desativadas no PMTA]

for x in $(pmta show disable sources|grep 2014-08-07|awk ‘{print $1}’); \
  do pmta delete –queue=$x; \
done

Bem, o script é super simples. O que faz a diferença é saber como usar a linha de comando com PowerMTA. Para mais comandos uteis, basta usar o pmta –help e estudar as opções disponíveis.

Qualquer dúvida, não se acanhe em deixar um comentário ou entre em contato.

 

 

 

 

Zero-Day Domains: Novo domínio, velho trabalho

Quem é do meio do email marketing já deve ter ouvido falar em um pre-requisito de entregabilidade chamado “warmup de endereços IP“. Assunto dedicado a alavancar a reputação de um endereço IP através dos diversos sistemas anti-spam e redes de informação relacionadas a segurança, esse não é a única panela que precisa ser “aquecida”. Tem que ter feijão, mas tem que ter arroz também.

Você confiaria naquela padaria que acabou de abrir, toda bonitona, com cesto de pão super decorado com cara de “banhado a ouro”? Mas de onde vem o pão? E aquela padaria da esquina que é aquela que vende o pão que te acompanhou por toda a infância, que, mesmo não sendo tão bonita nem tendo um cesto de ouro como a mais nova, nunca te deixou incapacitado em um hospital? Mas pensando bem, há muito tempo, essa velha conhecida também já foi uma novata (suspeita) no pedaço. E agora?

Você acabou de registrar um novo domínio para um novo produto que acabou de ganhar um hotsite novinho. Você acabou de separar um grupo de IPs que estava constantemente enviando campanhas com ótima receptividade, com uma lista de contatos de clientes que interagem positivamente. “Pão novo quentinho”, você pensa… e ao enviar o primeiro teste para o seu e-mail do Gmail, SPAM!!!! “WTH????”, você pensa.

Alguns sistemas anti-spam verificam não só a reputação do seu IP mas também a reputação do seu domínio. Esse conceito é velho. Pode-se dizer que nem são alguns sistemas e sim TODOS os sistemas anti-spam verificam a data de criação/publicação de um domínio, ou uma URIBL, ou até mesmo uma base de dados de informação interna composta por recursos próprios e de terceiros para saber por onde aquele domínio já passou e qual a reputação que ele tem/recebeu. Uma simples consulta “whois” é suficiente para uma parte importante dessa informação que é a idade do domínio.

Nunca usei de fato mas já ouvi falar que a Barracuda Networks, um dos maiores players do mundo em sistemas anti-spam, entre outras coisitas mais, tem em seus sistemas esse recurso.

E agora? Quem quer pão novinho fresquinho?

Esquentando os IPs e sua entregabilidade

Warming up de endereços IP. Bem, para quem não sabe o que isso significa, explico: Todo endereço IP, desde que novo, desde que nunca usado para e-mail, desde que nunca usado em serviço nenhum, aquele IP “virgem”, terá uma reputação “nula” atribuída. Essa reputação dita nula pode ser por exemplo de 50% (nem bom, nem ruim. Nula, de fato!). Mas, dependendo do provedor, geralmente o tratamento é do tipo “você não presta até que prove o contrário”. Por isso, começar a usar um IP fazendo campanhas de baixo volume, lista de contatos e conteúdos feitos um para o outro e um domínio que faça sentido para o público escolhido é importante para melhorar essa reputação.

O fato é que hoje, o conceito acima é muito mais amplo do que simplesmente ter um bloco de endereços IP, fazer envios de campanhas controladas e medir a reputação através das ferramentas conhecidas. Hoje os sistemas que “rankeiam” seu IP são muito mais complexos. E consideram muito mais variáveis do que antigamente. Hoje temos que contabilizar tudo! Por exemplo, a qual região geográfica pertence o bloco (ASN) que contem seu endereço IP? Indo mais a fundo, a qual país esse bloco foi cedido? Brasil?
Qual ISP/Datacenter teve a honra de receber a responsabilidade da subrede que contem o seu endereço IP? Qual a reputação dessa região ao redor do mundo? Qual a reputação do seu ISP? Qual a reputação do domínio do cliente que usou esse IP antes de você? Onde você está enfiando o pé?

Junte a isso o fato de que o assunto da escassez dos endereços IP versão 4 (que é usado globalmente nos serviços de e-mail) não é brincadeira! Tente conseguir uma rede e use o argumento real: “quero enviar e-mails!” ou “estou montando um serviço de e-mail marketing” para ver se é fácil. Não mesmo! Pelo menos não nos datacenters mais conhecidos.

Uma estrutura bem montada seguindo as melhores práticas de mercado, compliance com as RFCs necessárias, mecanismos de autenticação e seja lá o que mais houver de pre-requisito técnico para o envio de e-mails com qualidade não se sobrepõe ao histórico que o seu endereço IP tem guardado internet afora. Think about it!

Proofpoint e hotmail.com(.br)

Estava analisando alguns logs e acompanhando algumas filas se formando em um servidor de um cliente. Estava um tanto estranho já que o volume dele (100 mil emails) estava sendo enviado por um pool de 5 IPs, e, até a última vez que vi (pois está fora do escopo dos serviços monitorar isso) nenhum deles estavam listados nas principais RBLs que monitoro. Enfim, tudo nos conformes se ainda considerarmos que “a lista de contatos usada nesse projeto é toda double opt-in”. Mesmo assim havia uma fileira que unicamente se destacava de todas as outras com pouco mais do que algumas unidades de emails. Essa tinha pouco mais de 1000 (~1%) de emails endereçados a HOTMAIL.COM e HOTMAIL.COM.BR

Sempre soube que esse seria um trabalho interessante e fui com a certeza de que sairia enriquecido (intelectualmente, é claro) desse caso. Primeiro achei estranho que o enfileiramento estivesse acontecendo apenas para esses dois destinos e não para OUTLOOK.COM e/ou outros como LIVE.COM. Muito estranho!

No log apenas o famigerado “421 RP-001″ que conforme as notas disponíveis no site para Postmaster da Microsoft: “The mail server IP connecting to Outlook.com server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.” Como excedi esse limite? E se excedi, porque o threshold para o IP/Domínio usado está tão baixo?

Tenho um script feito em meus momentos “code fun” que uso para checar as RBLs que considero as principais, do tipo “se você está listado aqui muito provavelmente terão outras também” e ao executá-lo, voilá! o IP pelo qual o delivery estava sendo “freado” estava listado na RBL da Proofpoint. Essa  é um tanto complicada de pedir delist, o IP não pode ser reincidente etc, aquelas coisas que quem lida com isso esta acostumado e #chateado de TER QUE LIDAR COM ISSO DE FATO! Mas o que mais me supreendeu é saber que a Microsoft utiliza, de algum maneira, essa base de informação, mas porque apenas esses domínios? Porque não os outros nomes mais novos como o Outlook? E, a pergunta que não quer calar (e meu cliente não quer responder): se a lista de contatos é double opt-in, porque esse tipo de problema está acontecendo?

É impossível? Não!
É simples? Menos ainda… saco!

 

Registros de Operações de SPAM

ROKSO - The Register of Known Spam Operations. Todo marketeiro digital que se preze deveria entender o tamanho do problema que isso causa para os seus resultados. Deveriam conhecer também um pouquinho de como funciona o envio de e-mails em todas as suas fases, desde o envio, até a gestão da lista de contatos, criação de conteúdo etc. Conhecer só um pouquinho. Não precisa virar um especialista ou se aprofundar demais no assunto (senão pessoas como eu perderão seus empregos). Acho ainda que, muitos não acreditam o quão sérias são as organizações que combatem práticas de SPAM.

Dito isso tudo aí, a base de dados que citei no inicio desse post é incrível. E nela tem muita informação para quem quer alimentar um sistema antispam. Cheguei a achar pessoas conhecidas do ramo (sim, brasileiras) com as quais já trabalhei em outras oportunidades. Nesse caso fiz alguns ajustes de infraestrutura e apresentei alguns conceitos de ordem técnica. Na ROKSO database é possível encontrar informações assim…

Enviar SPAM é perigoso

 

Bem, acho que pelo menos eu tenho a obrigação de avisá-los caso ainda não saibam do que andam falando sobre eles. Feito isso, vale ressaltar que as organizações de investigação de atividades relacionadas a abuso do ecossistema de e-mails não são de brincadeira. São serias sim e merecem respeito sim. (na verdade a ROKSO é mantida pela Spamhaus que, acredito, ninguém seria louco de não se importar com o trabalho desses caras)

Puppet e infraestrutura distribuída de MTAs

Pois bem. Mesmo já tendo ouvido falar do Puppet, nunca tive a necessidade (ou o prazer inenarrável) de usá-lo nos clientes que atendo. Até que a oportunidade veio. E achei simplesmente Incrível.
Gerência de configuração (configuration management ) e automação da TI (IT Automation) são assuntos sempre muito discutidos pelo pessoal de desenvolvimento e operações. Com a moda DevOps, todo mundo ama o Puppet! Cumpre o papel e manda muito bem nessas áreas fazendo valer o esforço de aprendizado.

Meu cliente querido queria ter a possibilidade de ativar múltiplas VPSes em vários lugares. Assim poderia trabalhar estratégias de segmentação, custo e disponibilidade. Bom desafio! Ótimo para tentar algo com o Puppet. Foi o que fiz: adquiri um ebook que virou minha leitura diária por uma semana e comecei os laboratórios na prática.

O único pré-requisito da estrutura é trabalhar com arquitetura x64 mas não por causa do Puppet e sim por causa dos pacotes que o cliente tem para instalação, CentOS 6.x, capacidade de processamento de 3.0Ghz e 1GB de RAM. Necessidades pequenas para um projeto de porte. Pelo uso e estudo, vi que Debian tem todos os pacotes necessários também. É uma opção mas para mim, redhat-like-lover, vamos de CentOS. Uma VPS ficou dedicada ao papel de repositório GIT e essa mesma se tornou o MX da estrutura, bem como processador de bounces e feedbackloop. Após definir alguns módulos e variáveis e templates e linhas e linhas de conf no Puppet (falar é bem mais fácil) temos o resultado: Configuração de rede, hostname, dns server , ftp server, alguns scripts de apoio ao mta, o mta propriamente dito (com pools de ip, logs etc), tudo o que o cliente precisa é configurado em 5 min de trabalho em qualquer VPS de qualquer lugar do mundo. Fiquei apaixonado pela ferramenta e daqui pra frente a ideia é aprender mais. Além do mais, evita a fadiga da repetição e tracking de alterações e a mente agradece ;-)

Porque falei de repositório git lá em cima? O ebook que usei como referência não usa o puppet master que seria o servidor da estrutura e cita bons motivos para isso como maior demanda de configuração e manutenção. Aceitei a proposta e fui pelo git, porém, em um lab caseiro, próximo passo será brincar SIM com a estrutura completa.

Adoção do IPv6 cresceu… mas esqueceram dos e-mails

Fato! IPv6 não está pronto para e-mail marketing!

Existe um movimento bacana em prol da adoção do IPv6 “estruturas afora” mas, para o ecossistema de e-mails, a coisa está muito aquém do que achei que estaríamos em 2014. Tudo bem que o movimento “World IPv6 Launch“, talvez o mais legal de todos, só ganhou vida em 2012, mas essa onda está aí para ser surfada a algum tempo. E até agora nada! Tudo muito devagar… para os e-mails! A adoção é muito maior quando pesquisamos serviços Web e DNS. Porque? Segurança?

Dois sites muito legais sobre o assunto são:

  • IPv6.br: Nosso recurso pt-br com muita informação legal;
  • Google IPv6: Logo de cara vemos um mapinha bem informativo mostrando o quão pequeno ainda é a adoção da tecnologia.

Bem, o que me levou a escrever esse post foi um pedido de um “amigo-cliente” que, ao estruturar uma nova operação comercial, me pediu para especificar e montar a estrutura de servidores para a parte de e-mail marketing do negócio e disse estar interessado em usar IPv6 para enviar e-mails. Ele me mandou o link de um site que eu já havia visto em outro momento, quando pesquisava sobre a adoção do novo endereçamento em serviços de internet. O site, www.vyncke.org/ipv6status/ é um recurso muito bom também e foi por ele que concluímos que pouquíssimos ISPs e até mesmo grandes grupos de pesquisa, governo etc que, nos meus pensamentos, deveriam fomentar a adoção, ainda não adotaram. Algumas consultas abaixo nos dão uma fotografia melhor do que está acontecendo. Basta clicar nos links:

  1. Para os serviços de e-mail, o Google domina com IPv6 nos EUA;
  2. Já no Brasil…. Google de novo nos e-mails;
  3. O país com a maior taxa de adoção do IPv6 nos e-mails é a Líbia! Mas só porque todo mundo usa o Google;
  4. Uol, Bol, Terra, Ig, Hotmail, Yahoo, esse pessoal “ainda” não adotaram IPv6 em seus servidores de e-mail. Por isso, se você não pretende enviar e-mails apenas para sites que usam Google Apps e o próprio Gmail, não acho interessante nem necessário adotar IPv6.

 

Onde eu me encaixo? (o famigerado graymail)

No início de 2010 eu vi pela primeira vez a definição do que a maioria dos sites que se relacionam com os clientes/usuários por email costumam fazer. Foi em um post no blog do time da Microsoft, onde eles publicaram um estudo sobre os e-mails que eram spam para alguns e não-spam para outros. Afirmavam que os resultados das filtragens usadas no Hotmail (hoje outlook.com), esse conjunto de técnicas de detecção e contenção que formam o excelente(???) Smartscreen, chegaram a um ponto em que “spam de fato não entra mais”. Mas “spam de fato” era spam para quase todo mundo. Esses outros e-mails não. Algo havia de ser feito para resolver o problema dos e-mails de ofertas, news, updates de redes sociais etc, que naquele momento, representavam uma grande porcentagem do total de emails que transitavam pelo ecossistema do Hotmail e nem sempre eram bem-vindos ou, em dado momento, deixavam de ser.

E-mails que, pela clássica definição de spam, não podiam ser chamados assim (pois em algum momento houve no mínimo um desejo “primitivo” de recebê-los) receberam um nome: GRAYMAIL – basicamente e-mails que em um momento são queridos mas em outro não são mais.

Desse momento em diante conclui que a maioria dos meus clientes se encaixam nessa definição. Em 2011, um novo post mostrando mais avanços. E eis que então, nos dias atuais, todo o esforço da indústria de ferramentas e serviços antispam são voltadas para esses caras! E “esses caras” pode ser VOCÊ! Por isso o engagement, a relação do usuário, dono da mailbox, com o SEU CONTEÚDO,  torna-se tão importante. Pois bem. O que já era difícil tem se tornado cada vez mais complicado. Fazer com que o seu conteúdo chegue na caixa de entrada ou em qualquer outra “tab” como “promotions”, “social”, “updates” nos tira horas de sono revisando estrutura, fazendo warm ups, pesquisando BLs, compactuando com best practices. Tudo muito mais difícil hoje em dia. Minhas mailboxes agradecem ;)

Agora me diz, onde eu me encaixo?

A pergunta para essa resposta é muito simples. Veja:

  • Você comprou um CD com alguns gazilhões de e-mails na feirinha da esquina para enviar as promoções de cremes e perfumes da sua tia: spammer! louco! péssimo sobrinho!
  • Você tem um site onde algumas pessoas se cadastram. Você não confirma esses cadastros de nenhuma forma e manda e-mails da padaria da esquina: spammer! spammer! Queimem o spammer!
  • Você tem um site de informações, sobre as descobertas das plantas mais exóticas do mundo em risco de extinção. Algumas pessoas se cadastram e você dispara, nesse momento, um e-mail para esse cadastro confirmando a inscrição (e a intenção) para receber as novidades: Show! Está fazendo muito bem!!!
  • Uma parte dos botânicos de plantão não abrem mais seus e-mails. Pior! Alguns (loucos) até reportam que o seu e-mail é spam, clicando no famigerado botãozinho “isso é spam” ou coisa do tipo: bem… seu e-mail se tornou um graymail. (…e provavelmente você esqueceu do link visivel de descadastro)
  • Com um novo site (depois de um mega trabalho porque o outro começou a ficar mal visto na internet), você fez todo o processo de inscrição e confirmação e ainda manda periodicamente mas não tão frequente um e-mail pedindo para o cadastrado confirmar que ainda tem interesse em receber seus updates: você é meu cliente preferido! :) 

Nesse último caso, eu gosto de pensar que temos aí a origem da análise (e geração de “score”) do engajamento do cliente com o seu conteúdo…. O que acham?