Debian etch e PATA drivers

Não é de hoje o problema do debian-installer com maquinas muito novas, desta vez meu problema foi com suporte a DVD-Rom PATA(isso mesmo... um IDE comum), a maquina inicia o instalador, mas no momento em que inicia a detecção de hardware informa que não foi possível encontrar um leitor de mídia, e então a instalação para.

Lembrei das imagens de instalador Debian do JAPA, usei para instalar o sarge em maquinas com interfaces SATA mais recentes ao lançamento da versão do debian. Ao entrar no site do sujeito, lá estava a imagem do etch re-assemblada perfeita! Para instalar bastou inicializar com as seguintes opções: all_generic_ide=1

A versão do d-i do JAPA nada mais é que a original com um kernel mais recente, use-a por sua conta e risco.

Jeguepanel

Já conhece(http://www.jeguepanel.net)? Não? Excelente ferramenta, ainda em desenvolvimento, o nome é engraçado, mas nao deixe as aparências enganarem você. A idéia é realmente muito boa, o núcleo do sistema roda em perl e shell script, recebe os comandos via socket inet, os comandos são bem simples e interpretados por um switch/case do núcleo em shell script. mole de estender, mole de manter, molesa pra debugar.

O que você precisa pra usar:

• Linux (preferencialmente Debian)
• postfix
• openldap
• courier
  

Com essa ferramenta fica fácil manter diversos domínios de email em um pool de servidores ou não, me arrisco até a dizer que se tudo correr bem a ferramenta será uma boa opção para quem não se adaptou ao qmail-ldap.

Publicando o registro SPF de seu dominio

Publicar o registro SPF de seu dominio é uma tarefa simple, e antes de fazer isto é preciso saber alguns prós e contras

Prós:

• É possível definir quais maquinas estão autorizadas a enviar emails
• Acaba com emails forjados usando seu dominio
• Larga adesão por grandes domínios conhecidos
  

Contras:

• O mecanismo só funciona se o MTA que recebe a mensagem realizar a checagem
• Quebra o funcionamento de redirecionamentos (aliases, .forward, etc), contornável com o mecanismo SRS
  
• Não impede que maquinas autorizadas enviem spam
  

Sabendo disso, para publicar seu registro SPF permitindo o envio de emails somente a partir do servidor de correio definido no DNS de seu dominio através do registro MX:

dominio.com.br. IN TXT "v=spf1 mx -all"

salve, incremente o serial do dominio e recarregue a zona.

Outras opções de configuração e inclusive um wizard de configuração está disponível no site oficial do projeto
Publicamos o registro, mas ainda não configuramos nosso servidor para realizar a checagem desta informação, mas esta fica pra proxima.

Protegendo aliases de email

Aliase de email são endereços de email válidos no dominio de email, recebem spam também, os problemas começam quando mais de um destinatário recebe emails a partir daquele endereço, e quando essa lista fica grande... ai não tem jeito, você precisa proteger este endereço.

main.cf:
smtpd_recipient_restrictions =
...
check_recipient_access hash:/etc/postfix/enderecos_protegidos
...
smtpd_restriction_classes = remetentes_autorizados
remetentes_autorizados = check_sender_access hash:/etc/postfix/remetentes_autorizados, reject

enderecos_protegidos:
todos@dominio.com.br remetentes_autorizados
funcionarios@dominio.com.br remetentes_autorizados

remetentes_autorizados:
dominio.com.br OK
email@dominio.com.br REJECT
email2@outrodominio.com.br OK

# postmap /etc/postfix/enderecos_protegidos
# postmap /etc/postfix/remetentes_autorizados
# postfix reload

Pronto, agora somente os aliases de email todos@dominio.com.br e funcionarios@dominio.com.br, só recebem emails de:

• Endereços de origem @dominio.com.br
• Com exceção de email@dominio.com.br
• email@outrodominio.com.br

Esta lista pode aumentar e você pode também em endereços protegidos, criar arquivos de controles diferentes para cada alias de emai.

Mesmo com esta configuração, os aliases de email ainda não estão 100% protegidos, pois é possivel forjar o endereço de origem do remente, para melhorar mais um pouco isto, é preciso publicar o registro SPF do dominio em questão, mas isso fica pra outro dia.

Postfix + LDAP + Grupos unix como aliases

Muito se fala sobre usar LDAP em conjunto com Postfix, bom, na maioria das vezes o uso é natural atravez da libnss_ldap, ou seja, nesta situação o postfix nem sabe que está trabalhando com LDAP, pois a verificação da existencia de usuários unix é feita utilizando chamadas da glibc, então para a existencia de usuários OK, mas para aliases de emails ou emails de grupo mesmo que sem proteção fica assim:

main.cf:
alias_maps = ldap:/etc/postfix/ldap-groups.cf, ldap:/etc/postfix/ldap-aliases.cf

ldap-aliases.cf:
server_host = localhost
version = 3
search_base = ou=Aliases, dc=dominio, dc=com, dc=br
query_filter = (&(objectClass=nismailalias)(cn=%u))
result_attribute = rfc822mailmember

ldap-groups.cf:
server_host = localhost
version = 3
search_base = ou=Groups, dc=dominio, dc=com, dc=br
query_filter = (&(objectClass=posixGroup)(cn=%u))
result_attribute = memberUid


Depois explico como melhorar um pouco a proteção disto usando restriction_classes do postfix.