oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: mta

Postfix autenticació amb sasldb

Reading time: 2 – 2 minutes

Quatre notes que tinc pendents de classificar, com donar suport d’autenticació a postfix de forma ràpida i senzilla.

Paquets que cal tenir a més del postfix: cyrus-sasl, cyrus-sasl-md5.

Línies que cal tenir al /etc/postfix/main.cf:

smtpd_sasl_application_name = smtpd
smtpd_sasl_type = cyrus
smtpd_sasl_path = sasl2/smtpd.conf
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Fitxer de configuració del servei d’autenticació /etc/sasl2/smtpd.conf:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

Assegurar-se que el propietari del fitxer /etc/sasldb2 és postfix.

El fitxer /etc/sasldb2 és una base de dades Berkeley DB que guarda els usuaris i les seves paraules de pas en text pla. Així doncs, no és molt segur però una solució més que suficient per molts entorns SOHO.

Gestió d’usuaris:

# afegir usuari
saslpasswd2 -a smtpd -u domini_exemple.com nom_usuari

# borrar usuari
saslpasswd2 -d -u domini_exemple.com nom_usuari

# llistar usuaris
sasldblistusers2

La configuració que heu de posar al MUA pel que fa al servidor de correu ha de ser del tipus:

usuari: nom_usuari@domini_exemple.com
pass: el que hagiu definit
mecanisme d'autenticació suportats:  PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

UPDATE 27/2/2012:

Perquè es pugui tenir accés al fitxer /etc/sasldb2 cal que el mòdul smtpd de postfix no es llenci com a chroot. Per evitar això cal modificar el fitxer /etc/postfix/master.cf concretament la línia del dimoni smtpd ha de quedar així:

smtp      inet  n       -       n       -       -       smtpd

Per tenir suport de SASL a Ubuntu Lucid cal instal·lar els paquets: sasl2-binlibsasl2-modules.

pfqueue – GUI per la gestió de cues del Postfix

Reading time: 1 – 2 minutes

Amb el pfqueue podreu gestionar les cues del Postfix v1 i v2, a més de l’exim. Jo en realitat només l’he provat per la v2 de postfix. L’eina malgrat no ser molt ràpida és realment còmode i potent. En poques paraules facilita molt la feina de gestió de les cues. No és senzill jugar amb els IDs dels correus que tenim amb les múltiples cues de postfix. Posar-los en hold, reencuar-los, fer-los flush, eliminar-los, etc. Gràcies a aquesta interficie els veurem amb una llista poden fins hi tot fer clic sobre de cadascún per veure en detall la informació de contexte dels mateixos i el contingut. Després a través de les tecles d’accés ràpid a les accions podrem fer el mateix que si usessim la comanda postsuper i algunes coses més.

pfqueue screenshot

Aquesta eina l’he trobat disponible a Gentoo i a Ubuntu 8.04.1 però no a Ubuntu 6.06. Per altre banda, és realment senzill compilar-la i instal·lar-la en una 6.06 així doncs si realment teniu un postfix en aquesta distro ús recomano molt l’eina.

authsmtp – serveis de relay autenticat

Reading time: 2 – 2 minutes

Tot llegint documentació sobre temes de postfix que com sempre ja sabeu que hi estic molt posat he trobat una empresa que es dedica a vendre serveis de relay dels nostres dominis via processos autenticats. És a dir, podem usar el nostre servidor domèstic amb una simple ADSL amb IP dinàmica i a través d’ASMTP podem enviar correus a través d’una IP lliure d’RBLs, registre PTR i altres problemes similars. Per tant, els nostres correus sortiran a la xarxa de forma totalment legítima i ben protegits a través d’aquest enllaç. El millor són els preus del servei que són més que raonables. Per exemple, per moltes PIMES i sistemes domèstics el cost mensual no superaria els 2€-3€.

No us confongueu, els serveis de l’empresa són de relay és a dir, no fan de mail-backup per tant els correus entrants no els guardaran ells i els re-enviaran cap al vostre SMTP sinó alrevés; el que vosaltres envieu usarà com a smart-host el servidor d’aquesta empresa. A més d’aquest servei també fan còpies de seguretat de tot el que s’envia perquè es pugui consultar a posteriori i es comprova que no s’enviin correus duplicats. A més quan vosaltres no estigueu dintre de l’oficina o de casa podreu enviar correus directament contra l’ASMTP com si del vostre servidor de correu es tractés. Tot el correu que s’envia passarà també per un anti-virus per assegurar que no envieu virus sense voler als vostres destinataris, això és realment una descàrrega de feina molt gran pels servidors de la vostre empresa ja que sovint és el que més carrega els servidors de correu.

Si voleu donar un cop d’ull a l’empresa: AuthSMTP

ACL Policy Daemon for Postfix

Reading time: 3 – 4 minutes

Fins ara l’únic policy daemon que usava per postfix és el policyd v1 que esta fet amb C i per temes de rendiment em donava grans funcionalitats, rapidesa i escalavilitat sobretot pel seu backend en MySQL. Però avui m’he vist obligat a instalar el ACL Policy Daemon que esta programat amb Twisted+Python i que a través de la seva capacitat de configurar les regles d’accés al Postfix vai ACLs m’he pogut montar una funcionlitat un pel rebuscada que em calia per un client.

El problema és que aquest client necessita:

  • Rebre correu pels seus dominis
  • Permetre relay previa autenticació dels seus roadwarriors

Doncs bé això planteja un problema degut a una funcionalitat contradictoria. Si configurem el Postfix perquè rebi correu local, podem protegir aquest correu contre UBE tan com volguem i més però si l’origen especificat en la transacció SMTP indica que el remitent és una compte de correu del mateix domini que el destí (sovint la mateixa compte de correu), aquest correu s’acceptarà com a legítim i no es demanarà autenticació perquè l’MTA on s’està enviant el correu és el destí del mateix. Gràcies a això el correu serà acceptat al MTA i només quedarà a expenses del anti-spam i regles UBE anturar-lo, el qual malgrat via SPF i d’altres similars intentarà aturar aquest correu això no sempre serà possible i menys si els intents d’injecció són de l’ordre de desenes de milers al dia. Ens trobavem que alunes desenes passaben els filtres igualment.

Així doncs, gràcies a aquest policy daemon he pogut programar un regla que diu algo així:

  • si IP d’enviant no és local
  • si origen del correu és un domini local
  • si destí del correu és un destí local
  • si l’usuari no s’ha autenticat
  • NO es pot enviar aquest correu!

Els clients que estan fora de l’empresa (roadwarriors) sempre que envien un correu ho fan via ASMTP així doncs, si volen enviar un correu a alguna compte del mateix domini que la seva ho faran de forma autenticada. Per altre banda, si un client de correu intern a l’emrpesa intenta enviar un correu ho farà amb una IP local de l’empresa i aquest filtre no el bloquejarà.

Com podeu veure el problema és una mica enrabassat. Per altre banda, si voleu fer un cop d’ull al fitxer de configuració policy.conf (un dels fitxers de configuració del aplicyd) que he creat és de l’estil d’aquest:

acl wl client_address NET_IP/MASK
action nice_users DUNNO
access wl nice_users

acl remitent sender @example.com
acl desti recipient @example.com
acl aut sasl_method (PLAIN|LOGIN)
action rej REJECT Auth required
access remitent desti !aut rej

Malgrat jo he usat el apolicyd per temes molt concrets s’ha de dir que el seu codi font és molt entenedor i simple de modificar, a més de suportar moltíssimes funcionalitats de serie que permeten ajustar les nostres regles de filtrat moltíssim. Realment m’ha sorprès de forma molt positiva no m’esperava que estigués tan ben pensat.

pop2smtp: POP3 (“recojetodo”) a SMTP amb múltiples destins

Reading time: 2 – 3 minutes

Alguns ISPs ens permeten tenir una compte que reculli tot el correu enviat a un domini, això per exemple es pot usar com a mail-backup del nostre domini. Doncs bé a través de fetchmail és molt senzill re-injectar el correu enmagatzemat a una compte POP3 a un servidor SMTP contra un usuari. El més complicat, és si el correu que hi ha a la compte POP3 pot anar a més d’un destí, com el que deia fa un moment en comptes POP3 tipus ‘recojetodo’ o cul de sac com diuen alguns.

Doncs bé, per això he fet un petit script en python que a partir d’un fitxer BSMTP modifica la companda RCPT TO en funció de la informació de l’etiqueta Envelope to que conté una llista de les comptes d’email destí a qui va dirigit el correu. Així doncs, bàsicament la tasca consisteix en buscar quines comptes d’email apareixen a l’etiqueta comentada i després borrem la comanda RCPT TO i creem tantes comandes d’aquest tipus com faci falta en el seu lloc per enviar copies del correu que volem enviar als seus destins. Aquest nou fitxer BSMTP modificat l’injectem al nostre MTA. Aquest MTA serà l’encarregat de processar aquest correus i entregar-los a les comptes destí.

En el meu cas he decidit fer un petit shell script que s’executa des del crontab cada 10min. Aquest script, Crida a fetchmail per obtenir el fitxer BSMTP amb el correu que hi havia a la compte POP3, després crida l’script de python per modificar el fitxer BSMTP d’entrada tal com he comentat i crea un nou fitxer BSMTP de sortida. Finalment aquest fitxer s’injecta via SMTP cridant un petit script que gràcies al NetCat envia per SMTP el contingut del fitxer BSMTP de sortida.

L’script amb l’estructura de directoris empaquetat en un fitxer: pop2smtp_r1.tar.gz.

Segur que hi ha formes més elegants de resoldre el problema, però la veritat no les he sabut trobar.