Category Archives: Blog

Um conversa sobre o conteúdo de uma campanha de e-mail

Hi Everyone! :D

Vejamos aqui parte de uma “proposta de conteúdo” para uma notificação por e-mail:

“Prezado Cliente ABC, gostaríamos de lembrá-lo que o boleto encaminhado via correio vence HOJE dia XX/XX/XXXX.”

Bem, só para que todos entendam, esse é o trecho de uma ação de cobrança, mais precisamente um lembrete do vencimento de um boleto bancário, enviado anteriormente para quitação de dívida. A intenção da assessoria de cobrança era explorar melhor o envio de e-mail como canal de relacionamento com cliente.

Pergunte a si mesmo sobre o Conteúdo da sua Campanha de E-mail

Você pode se perguntar porque isso me chamou a atenção.  Bem, vamos começar a questão é que um prazo errado em uma campanha de e-mail pode invalidar toda a campanha já na largada.

Lembrete por e-mail com data limite para hoje não

Lembrete por e-mail com data limite para hoje não

Você olha o seu e-mail, principalmente aquele endereço pessoal, todo dia? Sim? Mas olha todo ele? Todas as abas? Não? Além disso, você é como eu e outras pessoas que, dependendo do título do e-mail e de quem enviou ele teria maior ou menor prioridade? Nunca percebeu esse seu comportamento?

Essas e outras questões precisam ser pensadas e levadas em conta quando usamos uma restrição de data em um conteúdo de e-mail. A maioria das pessoas que devem algo a alguém, imagino eu, daria o e-mail pessoal para contato. Essas caixas de e-mail costumam ser menos acessado/verificado do que um e-mail corporativo, por exemplo, não acha? Sendo assim não é aconselhável enviar um e-mail com validade para HOJE. É uma urgência que não pode ser garantida por e-mail e, nem mesmo por outros canais muito usados por essas empresas como SMS, por exemplo. E se “HOJE” eu esqueci meu celular em casa? E se “HOJE” eu decidi que não vou abrir meu e-mail pessoal porque ontem a noite eu já chequei e atualizei tudo que precisava? E se “somente HOJE” eu esqueci o carregador do meu celular em casa (e a bateria acabou antes do seu SMS chegar?).

 

 

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!

A Black Friday e os Filtros AntiSpam

Pois bem, eis que surge a Black Friday. Praticamente TODOS os programas de afiliados, desde os mais conhecidos até os mais “exóticos” estão anunciando, disparando emails de campanhas incríveis para seus afiliados conforme cresce a quantidade de promoções nos anunciantes. Coisa de louco! Lomadee, Afilio, Actionpay, Hotmart etc etc etc. Todo mundo com “descontos incríveis”

Eu não estou aqui para discutir sobre o que é ou não promoção ou sobre o que é ou não prática ideal de Black Friday. Nosso negócio aqui é e-mail marketing e o e-mail marketing BOMBA DEMAIS, junto com a Black Friday. É uma chuva de e-mails para tudo o que é lado, com vários disparadores branquelos (aqueles que seguem todas as melhores práticas de mercado e só enviam e-mails para os reais interessados) e milhares de disparadores cinzentos (aqueles outros que enviam e-mails para listas dos mais variados tipos, que seguem as boas práticas técnicas e de gerenciamento de listas, porém não possuem uma lista engajada de verdade).

Bom, se você fosse o administrador dos sistemas de antispam de um grande provedor de serviços de e-mail como o Outlook.com, o que você faria? Beeeeem… eu, sem sombra de dúvidas, sabendo da chegada desse momento e sabendo que é um evento global (o que facilita a manutenção do ecossistema) conversaria com meus fornecedores de “inteligência” (por exemplo, os fornecedores de sistema de segurança e de monitoramento da internet) e diria que “QUERO AUMENTAR A CAPACIDADE DOS MEUS FILTROS ANTISPAM. ME DIGAM COMO E FAÇAMOS ISSO!”.

IPs bloqueados em Outlook.com

IPs bloqueados em Outlook.com

Qual seria o resultados disso? Apenas um: MAIS BLOQUEIOS (de cinzentos, principalmente). E é o que está acontecendo com um dos meus clientes de consultoria.

E agora? O que fazer?????

 

Combate ao SPAM com a Microsoft

Essa é uma prática que eu já sabia que a Microsoft, fazia mas nunca tinha visto. Nos últimos dias eu fui convidadeo, através de um email do domínio outlook.com, a participar do programa de combate ao spam – SpamFightersProgram. Veja a mensagem que recebi na minha caixa:

Programa de Combate ao SPAM

Email enviado pela Microsoft para meu endereço de email no outlook.com

Combato ao SPAM Microsoft

Ok, então! Vamos participar ;)

É claro que eu optei por participar mas como uso muito pouco essa conta, passei quase uma semana sem acessá-la. Até que resolvi fazer um teste de uma campanha que estava desenvolvendo e coloquei esse mesmo endereço na lista de contatos de teste. Quando fui verificar como o email da campanha havia chegado eis que estava lá a mensagem me perguntando se aquela campanha era spam ou não.

 

EEEi! Esse e-mail não é SPAM

EEEi! Esse e-mail não é SPAM

Respondi a esse e desde então venho respondendo regularmente quando me perguntam o que eu acho que seja ou não spam.

Pensando sobre o Combate ao SPAM

  1. Eu já ouvi (e li) várias vezes que a Microsoft e o time do Outlook.com mantém a reputação dos seus usuários “por mailbox”, ou seja, cada um usuário de outlook.com tem seus comportamentos analisados e com isso, uma parte da reputação de um disparador (branquelo, cinzento etc) é contabilizada em um contexto unico também!
  2. Digo “também” na afimação anterior pois é claro que eles não deixam de contabilizar a reputação “geral”, ou seja, quando eu pego um e-mail e mando para o lixo eletrôncio, ele não só conta como um conteúdo que EU não quero receber, como também afeta todo o “ecossistema” e, é claro, outros usuários.
  3. Suponhamos então que um desses usuários afetados “indiretamente” pela minha escolha (e de todos os outros usuários reclamões), resolva tirar esse e-mail do lixo eletrônico e o coloque de volta em sua caixa de entrada. Isso afetará todo o ecossistema igualmente? É claro que não! Essa escolha afetará APENAS a ele próprio e não mudara de forma geral a reputação do disparador.
  4. Enfim, quando eu “reporto” um e-mail enviado (e referenciado) pelo SpamFightersProgram@hotmail.com como sendo um SPAM, eu estou obviamente que contribuindo para todo o ecossistema. Agora imagine que dos seus 1.000.000 emails enviados na última campanha, 1000 desses reportem seu e-mail como sendo “lixo eletrônico”? Onde vai parar a sua reputação?

Sim, casos como esses, são feitos para se pensar, até mesmo porque NENHUM PROVEDOR publica suas regras antispam (os motivos são óbvios). Sendo assim, nós disparadores, branquelos ou cinzentos, temos que “pensar” e trabalhar com nossas percepções. Testes, muitos testes!

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!

 

…e o corpo ainda é pouco!!!! (assim: atenção ao conteúdo do seu e-mail)

Muita gente que teve contato com o mundo do advertisement acaba por querer ter o seu “próprio negócio”, por assim dizer. Ficam enlouquecidos com a possibilidade de conseguir uma grana mandando emails. Muitos optam por usar as redes de afiliados para conseguir material de anunciantes e outros, com mais contatos e mais “profissionalmente”, vão até os anunciantes para conseguir porcentagens maiores sobre as vendas.

Um dos clientes de infraestrutura que atendo é desses. E uma das campanhas que ele manda é da Netshoes (que fique claro, é apenas um exemplo). Como parte do meu trabalho estou sempre em busca de melhorias da entregabilidade dos servidores que administro e para isso muito tempo de pesquisa é despendido.

Não é novidade que o conteúdo de um email, o corpo, <body>, é analisado por filtros antispam. Feature básica, deixemos claro aqui. A analise dos links encontrados nesse corpo também é um procedimento básico de qualquer sistema antispam que se preze.
O que não é novidade também é que o conteúdo disponibilizado pela Netshoes é compartilhado por N parceiros entre aqueles sérios (advertisers) e aqueles não tão sérios (spamvertizers) assim. O resultado está abaixo (clique para visualizar).

Netshoes listed Sorbs

 

A SORBS (Spam and Open Relay Blocking System) é lista de bloqueios operada pela Proofpoint, uma das maiores players do mercado de segurança em e-mail. Ter um IP ou uma URL listada nela é motivo de muita dor de cabeça e pouca entregabilidade. A questão é que TODO MUNDO que envia campanhas de advertisement está em desvantagem com os filtros antispam. Para evitar isso as empresa precisam selecionar criteriosamente quem irá enviar seu conteúdo, qual a origem da lista de e-mail e se todos que receberam esse conteúdo realmente se interessam por ele. Precisam monitorar a reputação de suas URLs e punir o parceiro que ameaçar a qualidade dessa reputação. Ou então todos acabarão como o Walmart que cancelou seu programa de advertisement, pelo menos aqui no Brasil. Ruim para todo mundo!

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!

 

Básico do email marketing

… e eu nem sequer estou considerando as regras de criação de conteúdo (HTML), por exemplo. Estamos apenas falando de uma das camadas de um modelo em camadas muito maior. E muito maior mesmo! Esse infográfico representa a “explosão” de uma camada que poderia ser chamada de “camada sistema de gestão de envios de email marketing”. O que deve ser considerado na hora de criar, avaliar, repensar uma estrutura e/ou sistema que faz os envios de campanhas de email marketing. Vide abaixo! Posso estar esquecendo de alguma coisa mas (acho que) está (quase) tudo aí.

Estourando os miolos com email marketing (1)

“DMARC” o seu território!

Se você ainda não demarcou o seu território, saiba que a autenticação do envio de e-mails é um movimento crescente e mais forte a cada dia. Está mais do que na hora de você se preocupar com a sua reputação! DMARC seu território.

Começando mais sério com SPF, passando pelo obsoleto Sender-ID, pegando mais pesado com DomainKeys, evoluindo para DKIM e agora com o DMARC, empresas, provedores, locais, globais…. enfim, todo mundo que depende do envio de e-mails nos negócios deve conhecer essas ferramentas de autenticação e validação de identidade. Em suma, todas elas garantem para quem receber o seu e-mail, que foi você quem enviou a mensagem de fato, não algum spammer sem vergonha querendo esconder suas artimanhas e rastros de atividades escusas.

No último mês vimos um movimento forte de grandes ISPs que publicaram políticas de rejeição em seus registros DMARC. Começando com Yahoo, partindo para AOL e dizem as “boas línguas”, Google pretende fazer o mesmo.

Do que estou falando? Estou falando que o DMARC, registro publicado na sua zona do domínio DNS cuja autoridade técnica/administrativa é você,  informa a quem está recebendo o “seu” e-mail (voce@seudominio.tld) o que deve fazer no caso de problemas com sua identidade. Se as ferramentas de autenticação (imagino que você use SPF e DKIM) falham por algum motivo, no registro DMARC que VOCÊ publica, o lado B da comunicação, o destino, o cliente, o alvo, pode usar esse registro para tomar uma ação. Melhor, VOCÊ diz que ação deve ser tomada. No caso do Yahoo, esse diz que a mensagem @yahoo (ou domínios relacionados) devem ser REJEITADAS se não vierem dos servidores que eles publicam em seus registros de autenticação.

Isso é muito bom! Fato! Mas…. o ecossistema de e-mails é muito falho, em partes por causa da própria fragilidade que os protocolos envolvidos apresentam, afinal, quando foram criados, o mundo tinha muito menos mal-caráter do que hoje em dia, e em partes por conta de serviços que foram sendo criados sobre essa estrutura frágil. Exemplos? Listas de discussão, servidores de relay, auto-responders etc. Em alguns casos não conseguimos saber quem está “encaminhando” nossos e-mails e nem como. Com um registro DMARC publicado sem testes e homologações, isso pode ser um enorme problema.

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.