mknod /dev/blog c 1 3

NOTA: desi acest articol se bazeaza pe Debian, poate fi aplicat si la alte distributii, cu schimbarile de rigoare.

Atunci cand am de ales prefer sa folosesc Postfix ca  server de e-mail. Il prefer in primul rand pentru usurinta cu care se configureaza sau se poate urmari traseul e-mailurilor prin el. Singurul aspect mai complicat este autentificarea  "road warriors" via sasl (de vina fiind de obicei mesajele de log destul de criptice si faptul ca in Debian, Postfix ruleaza in chroot).

Mai intai pachetele. Pe o masina Debian care are deja un Postfix functional sunt necesare urmatoarele:

• libsasl2
• sasl2-bin (contine daemonul saslauthd, precum si utilitarul testsaslauthd)
• libsasl2-modules (daca postfix insista sa crape cu "no mechanisms found", poate lipseste pachetul asta)
• postfix-tls (da, nu e postfix-sasl, binarul din acest pachet e compilat cu suport de sasl pe langa tls - de care va fi oricum nevoie)

Urmeaza configurarea saslauthd. (NOTA: de ce e nevoie de saslauthd, daca documentatia spune ca poate postfix sa se ocupe direct de treaba asta? Ei bine, atunci cand e in chroot nu mai are acces la /etc/shadow, printre altele, si ar fi o problema sa i se copieze mereu acolo, ca sa nu mai vorbim de riscul de securitate.) Se editeaza /etc/default/saslauthd si se fac urmatoarele schimbari:

• START=yes
• MECHANISMS="pam" (aici si in continuare o sa presupun ca e vorba de useri de sistem, pentru useri virtuali sunt unele schimbari care ar complica prea mult articolul)

Urmeaza niste modificari in /etc/init.d/saslauthd

• mai intai, la sfarsitul variabilelor initiale, se trece dir="root sasl 755 ${PWDIR}"
• mai jos, in linia PARAMS="${PARAMS} -a ${MECHANISMS}" se adauga un -r (pentru a transmite adresa completa  mai departe in cazul in care exista "@" in username)
• si mai jos, se comenteaza dir=`dpkg-statoverride --list $PWDIR`

NOTA: aceste schimbari pot fi evitate adaugand userul postfix in grupul sasl (pentru partea cu directorul) , respectiv declarand PARAMS="-r" in /etc/default/saslauthd (sau de loc, daca nu se folosesc useri virtuali). Nu am testat aceste solutii, dar o sa aduc la zi articolul cand o fac.

Urmeaza schimbari pentru compatibilitatea cu chrootul postfix (care este in /var/spool/postfix):

• rm -rf /var/run/saslauthd
• mkdir -p /var/spool/postfix/var/run/saslauthd
• ln -s /var/spool/postfix/var/run/saslauthd /var/run/

Mai trebuie si modul de pam. In principiu e nevoie de optiunile default la modulele account, session si auth (de password nu e nevoie). Astea trebuie sa stea in /etc/pam.d/smtpd (desi cred ca testsaslauthd foloseste "imap"), desi pe unele distributii (cum ar fi Debian) /etc/pam.d/other este configurat permisiv, asa ca pasul asta e optional.

Cam atat cu saslauthd, /etc/init.d/saslauthd restart (s-ar putea sa comenteze nitel ca e directorul nou, dar ii trece). Urmeaza bateria 1 de teste:

• mai intai trebuie identificat un user functional (sa mearga sa primeasca si sa trimita mailuri)
• testsaslauthd -u USERNAME -p PASSWORD
• testsaslauthd -u USERNAME -p PASSWORD -f /var/spool/postfix/var/run/saslauthd/mux  (ar trebui sa mearga amandoua, exista symlink)

Bun, urmeaza postfix. Se creaza directorul /etc/postfix/sasl , si in el fisierul smtpd, care trebuie sa contina umatoarele 2 randuri: "pwcheck_method: saslauthd" si "mech_list: plain login". NOTA: se pot adauga si alte mecanisme, dar nu functioneaza cu parole stocate criptat, asa ca se recomanda utilizarea de tunele ssl pentru protejarea parolelor transmise in clar.

Next, main.cf :

• "smtpd_sasl_auth_enable = yes"  - comentarea acestei linii e suficienta pentru dezactivarea rapida a sasl
• "broken_sasl_auth_clients = yes"  - anumite versiuni de outlook (toate?) nu detecteaza corect linia de auth, asa ca li se mai da una custom (vezi mai jos la teste)
• smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination  (sa aibe permit_sasl_authenticated undeva inainte de reject_uanuth_destination, sa ofere relay pt. useri)

Restart postfix. Done! (sort of). Urmeaza teste:

• pentru testarea autorizarii se ruleaza undeva urmatorul oneliner: perl -MMIME::Base64 -e 'print encode_base64("testuser\0testuser\0testpasswd");' , unde testuser si testpasswd se inlocuiesc cu valorile
  corespunzatoare, se copiaza stringul rezultat si se tine minte
• telnet mailserver 25
• testul 1, pasiv: daca apare bannerul (ESMTP stuff), inseamna ca postfix si-a citit setarile lui si a gasit modulele de autentificare
• testul 2, se scrie "ehlo my.host.name": daca apar liniile cu "250-AUTH PLAIN LOGIN" si "250-AUTH=PLAIN LOGIN" inseamna ca intr-adevar raporteaza ca stie de smtp-auth (o linie e pt. outlook, remeber broken_sasl_auth_clients)
• testul 3, "auth plain dGVzdHVzZXIAdGVzdHVzZXIAdGVzdHBhc3N3ZA==", unde stringul ala e generat de onelinerul perl de mai sus: ar trebui sa fie evident daca merge sau nu Daca aici nu merge s-ar putea sa fie problema de parametrul -r la saslauthd (desi nu ar fi mers nici cu testsaslauthd mai sus) sau de generarea/copierea digestului, caz in care poate ar merita incercat un client full de e-mail

Ce lipseste din acest howto:

• ssmtp, pentru protejarea parolelor (base64 e reversibil)
• useri virtuali in mysql sau ldap
• mecanisme de autentificare criptate