andrelop’s blog

Masoquismo virtual 102 : configurando um MX secundário (the easy way)

Eu não me canso de ficar espantando com a facilidade de se fazer as coisas com o Postfix se comparando a outras soluções de MTA, sejam elas proprietárias ou livres.

Hoje precisei configurá-lo para que meu servidor de mensagens pudesse temporariamente atuar como MX secundário para alguns domínios de um amigo, de modo que os mesmos não ficassem completamente invisíveis para todo o mundo durante a movimentação de um servidor para outro.

Minha tarefa foi somente fazer a porção que me cabia como administrador do servidor que atuaria como MX secundário e não também configurar o servidor que já atua como MX primário. Para minha surpresa, foi algo extremamente simples de ser feito usando Postfix, como eu já esperava, dadas as minhas experiências anteriores felizes lidando com o mesmo.

Eu simplesmente tive que incluir os domínios em questão no parâmetro relay_domains e me certificar de que o parâmetro smtpd_recipient_restrictions tivesse uma restrição que checasse os domínios anteriormente listados no parâmetro relay_domains. Para isso, a documentação do Postfix indica o uso da restrição check_relay_domains, mas essa restrição ficou obsoleta e foi substituída pela restrição reject_unauth_destination já há alguns anos.

No final, as linhas inseridas/modificadas no arquivo de configuração principal do Postfix (arquivo /etc/postfix/main.cf em meu caso) foram as seguintes :


relay_domains = $mydestination, dominioadicional1.com, dominioadicional2.com, dominioadicional3.com

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:60000, reject_unauth_destination


Para essa tarefa, a única restrição realmente importante a ser inserida no parâmetro smtpd_recipient_restrictions é a restrição reject_unauth_destination. As outras restrições presentes cumprem outras tarefas que não vem ao caso no momento e não são assunto para este post (quem sabe um post futuro).

Isso já foi o bastante para que meu servidor passasse a receber as mensagens destinadas aos domínios adicionais e enfileirá-las localmente, de forma que as mesmas ficassem armazenadas temporariamente até que o servidor MX primário voltasse a ficar operacional posteriormente.

Mas o leitor esperto irá notar que, somente com essa configuração, estamos recebendo toda e qualquer mensagem destinada aos domínios adicionais em questão. Lógico, meu antispam e minha solução de greylisting vão cuidar da maioria da porcaria virtual, mas seria importante receber e manter as mensagens somente para os endereços reais dos domínios adicionais e não para qualquer coisa que termine com os domínios em questão como endereço.

Para isso, simplesmente utilize o parâmetro relay_recipient_maps e aponte para um mapa de lookup do Postfix que contenha os endereços os quais você saiba que são endereços realmente válidos. Um exemplo de configuração desse parâmetro seria, no arquivo de configuração principal do Postfix, o seguinte :


relay_recipients_maps = hash:/etc/postfix/relay_recipients


O próximo passo é criar o arquivo apontado pelo parâmetro relay_recipients_maps, ou seja, no caso, o arquivo /etc/postfix/relay_recipients. Esse arquivo irá conter os endereços válidos dos domínios adicionais da seguinte forma :


usuario1@dominioadicional1.com OK
usuario2@dominioadicional1.com OK
usuario1@dominioadicional2.com OK
usuario2@dominioadicional2.com OK
usuario1@dominioadicional3.com OK
usuario2@dominioadicional3.com OK


Para finalizar, criamos o arquivo /etc/postfix/relay_recipients.db usando o comando o comando postmap e forçamos a releitura do arquivo de configuração principal do Postfix recém modificado, usando os comandos a seguir :


# postmap /etc/postfix/relay_recipients
# postfix reload


Pronto. A partir de agora, quando o servidor de mensagens que atua como MX primário dos domínios adicionais em questão for colocado fora de funcionamento temporariamente, as mensagens que antes seriam entregues ao mesmo serão recebidas por meu servidor, enfileiradas temporariamente no disco local e entregues de volta ao servidor que atua como MX primário quando este voltar a operar novamente.

Com a vantagem de que mensagens destinadas a endereços inválidos ou inexistentes destes domínios adicionais serão rejeitadas por meu servidor atuando como MX secundário, o que evitará que tais mensagens ocupem recursos do servidor (como espaço em disco, por exemplo) para depois serem sumariamente apagadas quando forem repassadas ao MX primário.

Aderindo ao Rec6

Conforme noticiado pelo BR-Linux, também estou aderindo ao Rec6, uma espécie de Digg nacional. Para isso, segui a dica para quem usa Wordpress no post do Bruno Alves apontado pelo BR-Linux e modifiquei os arquivos index.php e single.php dentro do diretório de meu tema (no meu caso, wp-content/themes/default, já que uso o tema padrão) e acrescentei o trecho de código para acrescentar o botão do Rec6 aos meus posts.

Agora, qualquer doido que por um desastre da natureza gostar do que escreve e quiser votar nos meus posts, fazendo com que os mesmos subam de posição no Rec6, ou ao menos apareçam por lá, é só clicar no botão Rec6 que aparecerá abaixo de cada um dos posts em meu blog.

Controle de spam em blogs : mais acessibilidade

Ok, eu sabia que mais cedo ou mais tarde eu iria acabar abandonando minha tática para barrar spam nos comentários de meu blog. Como eu havia dito no post que fiz sobre o assunto, o idéia de usar captcha não é politicamente correta pois deixa seu blog menos acessível (pense em acessibilidade).

Depois de alguns testes, também acabei percebendo que, além do problema de falta de acessibildade, o plugin de captcha que eu estava usando estava impedindo que trackbacks para meus posts funcionassem. Decidi que deveria mudar e acabei desabilitando o plugin que implementava captcha que usava até então.

Por enquanto, deixei habilitado somente o Akismet, um plugin que usa uma espécie de blacklist online para afastar spam em comentários. Sei que definitivamente não será tão eficiente quanto o plugin usado anteriormente, mas posso aceitar ter um pouco mais de trabalho administrativo para deixar meu blog mais acessível e não perder comentários potencialmente interessantes.

Novo plugin : AutoMeta

Instalei um novo plugin no blog, o AutoMeta. Esse plugin, segundo a descrição, automaticamente gera e inclui HTML Meta Tags e Technorati Tags com base em todo o texto de cada post.

E, como nenhuma tecnologia que faz tudo 100% de forma automatizada é 100% perfeita, permite que você revise tudo antes de dar seu aceite final. Vou testá-lo por uns dias, já que não custa nada (literalmente) e estou mesmo querendo começar a atender e explorar as capacidades do Technorati.

Quem sabe não fico mais na moda usando tecnologias Web 2.0 ?

Plugins antispam para sistemas de blogs

Existem inúmeras opções para combate a blogspam. Apesar de não ser a opção mais acessível, uma vez que impede que usuários com dificuldades visuais possam comentar, acabei instalado um plugin que implementa o esquema de Captcha, ou seja, uma imagem com letras e números aleatórios são gerados e colocados em uma imagem na página de comentários e um campo deve ser preenchido com essas mesmas letras e números aleatórios para que o comentário seja aceito.

Existem opções que acrescentam sistemas antispam ao mecanismo de comentários do Wordpress, inclusive plugins que o conectam com o SpamAssassin (SA). Apesar de utilizar o SA em inúmeros sistemas de combate a spam em MTAs, meu servidor pessoal ainda é muito modesto em termos de memória disponível para poder se dar ao luxo de utilizar o SA.

Ou seja, por enquanto, mesmo sabendo que utilizar um esquema de Captcha não é a melhor opção, infelizmente é o que tenho que utilizar. Recomendações de opções mais acessíveis e não tão memory-hungry são bem-vindas.

ikiwiki : mais uma maravilha saída da mente de Joey Hess

Não é segredo para ninguém que sou fã de Joey Hess. Eu já inclusive disse isso a ele quando tive oportunidade (via e-mail, lógico). O cara simplesmente está envolvido em muita coisa relacionada ao projeto Debian e consegue ser extremamente produtivo.

É impressionante ver a quantidade de código decente que ele produz e como depois de tanto tempo contribuíndo ele ainda tem motivação suficiente para continuar contribuíndo como se tivesse iniciado hoje. O debhelper é algo fantástico, o debian-installer nunca seria o mesmo sem ele e muitas outras áreas do Debian se beneficiam da genialidade do joeyh.

Agora que tenho meu próprio servidor, estive procurando por alternativas para manter um site pessoal. Minhas exigências é que a ferramenta de auxílio a esta tarefa fosse simples, me permitisse atualizar o site sem que para isso eu precisasse utilizar uma interface Web (apesar de eu estar me acostumando mal com essa interface de posts do Wordpress) e que, preferencialmente, me possibilitasse utilizar controle de versão para manter o conteúdo e poder recuperá-lo de qualquer versão anterior caso alguma catástrofe acontecesse.

Acabei decidindo que um Wiki seria a ferramenta ideal e, em minha procura, encontrei o ikiwiki, criado por nada mais nada menos que o Joey Hess. O ikiwki é simples e me permite manter meu site/Wiki pessoal com simplicidade, usando meu editor de textos preferido e enviar as atualizações através de um commit num repositório Subversion que configurei para armazenar o site.

Perfeito O ikiwiki não está disponível para stable, mas está disponível para unstable e testing. Como não queria manter um sistema misto e meu servidor usa somente stable. Verifiquei as dependências do ikiwiki e notei que a única dependência não satisfeita do mesmo na stable é o pacote libcgi-formbuilder-perl, que existe na stable mas em uma versão mais antiga do que a versão mínima necessária.

Fiz um backport do pacote para uso local e reconstruí o pacote do ikiwiki para uso pessoal no servidor e ambos parecem estar funcionando bem. Agora é só começar a explorar as possibildades fornecidas pelo ikiwiki. Já estou usando um script post-commit gerado pelo ikiwiki.setup que reconstrói as páginas do site automaticamente após os commits no repositório Subversion.

Agora só falta configurar o ambiente de forma decente para que eu possa fazer commits de outros locais diferentes do console do servidor de forma segura, via svn+ssh. Esta parcialmente feito, na verdade. Só faltam alguns detalhes.

Caso alguém tenha interesse, expresse nos comentários ou me envie um e-mail que ficarei feliz em disponibilizar os backports do libcgi-formbuilder-perl e do ikiwiki. Só não os fiz ainda porque não achei que fosse algo que seria de interesse geral.

First post and already tired

Well, I have just finished setting up my virtual machine in a hosting provider which offers a very nice virtual machine plan called VPS.

It’s very nice because they give you full root access so you can install whatever you want to install. Also, it’s Debian based and even the control panel they provide is as I like things to be : minimalist and easy to use. Sure, it works like a charm also.

I’m tired because I was fighting the blog system I installed for a long time trying to convince it to get installed in a proper VirtualHost but it kept giving me trouble everytime I tried to access its root page. I gave up and installed it in a directory under my default page and then it worked as expected.

Someday I need to take a closer look at it and find out what really went wrong. Well, actually, I know what went wrong and I even knew how one could fix the issue as I already fixed issues like this one lots of time in the past, but this time my tricks didn’t helped.

Anyway, mail setup is already working, complete with SSL-based IMAP/POP, SMTP-AUTH through SASL and all the basic services I wanted to have are already working. Now I think I can have some sleep a it’s past 4:00AM.

Well, enough for a first post.