7.3.3.4. Gestión de usuarios

Hasta ahora nos hemos limitado a utilizar usuarios definidos en el sistema que tienen todos cuenta en un mismo dominio. Sin embargo, esto es solamente un caso particular. Por un lado, lo habitual es que los usuarios de correo sea usuarios exclusivos, reconocibles sólo por este servicio. Por otro, puede darse el caso de que nuestro servidor gestione distintos dominios y que cada dominio tenga sus propios usuarios. Ambas situaciones, que generalizan la comnfiguración del servidor, se estudiaran bajo el prsente epígrafe.

Ver también

Es sumamente importante que lea qué se entiende por usuario, expuesto en los primeros párrafos del epígrafe dedicado a las cuentas virtuales.

7.3.3.4.1. Usuarios exclusivos

Para que postfix reconozca, además, usuarios distintos a los del sistema tenemos dos posibilidades:

• Manipular la autenticación con el servidor smtp de PAM.

• Si está disponible, es más recomendable manipular la autenticación de dovecot, que pasa por haber usado el SASL que éste proporciona para postfix.

7.3.3.4.1.1. A través de PAM

Nota

Bajo este epígrafe se tratará la creación de usuarios exclusivos de manera muy simple y que no es en absoluto recomendable cuando se gestiona un gran número de este tipo de usuarios. Esto es así, porque si se usan módulos como pam_userdb o pam_pwdfile sólo existe información sobre el nombre de usuario y su contraseña, y no sobre el resto de características de la cuenta (el directorio de usuario, por ejemplo). Además, tampoco posibilita el cambio de la contraseña.

La habilitación de usuarios exclusivos en postfix supone tres operaciones distintas:

7.3.3.4.1.1.1. Creación de usuarios

Necesitaremos el paquete db-util:

# apt-get install db-util

Tras ello, lo primero es crear una base de usuarios que contenga los nombres y contraseñas de los usuarios exclusivos. Para ello debe crear primero un fichero de texto plano en que se dispongan alternativamente nombres y contraseñas:

# cat /etc/postfix/vusers
pepe
24iLOKFSxXxdo
paco
bKsPsgguh00tU

Las contraseñas se obtienen cifrándolas con openssl. Por ejemplo, si la contraseña de pepe es soypepe:

$ openssl passwd -crypt soypepe
24iLOKFSxXxdo

Hecho esto, debemos generar la base de datos:

# db_load -T -t hash -f /etc/postfix/vusers /etc/postfix/vusers.db
# chmod 600 /etc/postfix/vusers.db

Si no se conserva el fichero original, puede consultarse el contenido de la base de datos, así:

# db_dump -p /etc/postfix/vusers.db

Nota

Para añadir usuarios a la base de datos puede usarse un nuevo fichero que contenga los nuevos usuarios y la opción -n de db_load:

# db_load -T -n -t hash -f /etc/postfix/mas_usuarios /etc/postfix/vusers.db

o bien, si es uno sólo leerlo directamente de la entrada estándar sin incluir la opción -f:

# db_load -T -n -t hash /etc/postfix/vusers.db <<EOF
> jesus
> $(openssl passwd -crypt soyjesus)
> EOF

7.3.3.4.1.1.2. Configuración de PAM

Es decir, configurar la autenticación para que postfix reconozca los usuarios como válidos. Esto exige modificar (en realidad, crear) el fichero /etc/pam.d/smtp y dejarlo del siguiente modo:

auth sufficient pam_userdb.so crypt=crypt db=/etc/postfix/vusers
account sufficient pam_userdb.so crypt=crypt db=/etc/postfix/vusers

account required pam_succeed_if.so user ingroup mailusers

@include common-auth
@include common-account

La configuración propuesta hace, en realidad, dos cosas:

• Permite la autenticación de los usuarios exclusivos.

• Exige a los usuarios reales la pertenencia al grupo mailusers, lo cual exigirá su creación:

  # addgroup --system mailusers
  

Para comprobar la configuración basta hacer algo así:

# testsaslauthd -u pepe -p soypepe -f /var/spool/postfix/var/run/saslauthd/mux -s smtp
0: OK "Success."

7.3.3.4.1.1.3. Configuración de los buzones

Antes de continuar es preciso indicar que, aunque los usuarios exclusivos no existen para el sistema, sí es necesario almacenar en el sistema de ficheros los mensajes que reciben. Estos ficheros en que se transforman los mensajes, deben pertenecer a algún usuario y tener un grupo propietario. Sin embargo, los usuarios exclusivos no tienen nada de eso ya que son, simplemente, un nombre y una contraseña. Por ese motivo, postfix requiere mapear esto usuarios pra que dispongan de un uid y un gid. La manera más sencilla de hacerlo es crear un usuario real y un grupo real (mailusers nos vale) y mapear todos los usuarios exclusivos con ellos dos.

Consecuentemente, debemos crear un usuario[1]:

# adduser --home /var/spool/mail/vusers --shell /bin/false --ingroup mailusers \
   --gecos "Usuario para usuarios de correo" mailuser --disabled-password --uid=500

La configuración de postfix se basa en crear un dominio virtual que sepamos que no existe, por ejemplo, mail1.vusers, redirigir los mensajes de los usuarios exclusivos hacia este dominio virtual y, por último, definir los buzones de éstos.

La configuración a añadir en /etc/postfix/main.cf es la siguiente[2]:

virtual_mailbox_domains = mail1.vusers
virtual_mailbox_base = /var/spool/mail/vusers
virtual_alias_maps = hash:/etc/postfix/vusersmap
virtual_mailbox_maps = hash:/etc/postfix/mailbox_vusers
virtual_uid_maps = static:500
# Suponemos que el grupo mailusers tiene GID 115
virtual_gid_maps = static:115

El fichero vusersmap debe contener el mapeo de los usuarios exclusivos hacia el dominio virtual[3]:

# cat > /etc/postfix/vusersmap
pepe@mail1.org    pepe@mail1.vusers
paco@mail1.org    paco@mail1.vusers

Y el fichero mailbox_users la localización de los buzones de éstos[4]:

# cat > /etc/postfix/mailbox_vusers
pepe@mail1.vusers    pepe/Maildir/
paco@mail1.vusers    paco/Maildir/

Lo cual quiere decir que los correos de pepe acabarán en pepe/Maildir/, por ejemplo. La ruta es relativa, porque se ha definido ya la base en el fichero de configuración (virtual_mailbox_base), por lo que la ruta completa será /var/spool/mail/vusers/pepe/. El hecho de que se incluya una barra final, implica que se quieren buzones en formato maildir.

Por último, debe crearse el directorio que contendrá estos buzones:

# mkdir -p /var/spool/mail/vusers
# chown mailuser:mailusers /var/spool/mail/vusers
# chmod 700 /var/spool/mail/vusers

Nota

Que la autenticación no proporcione completamente la información sobre la cuenta (UID, GID, directorio de usuario) obligará, si se configura dovecot, a mapear en ella también a estos usuarios exclusivos. Se verá más adelante.

7.3.3.4.1.2. A través de dovecot

Advertencia

Tenga presente quen si configura usuarios exclusivos usando dovecot, se verá obligado a autenticar con dovecot y a usarlo como MDA[5].

Ver también

Siga las indicaciones del para habilitar los usuarios virtuales a dovecot

Hechas las modificaciones en dovecot, aunque queda un escollo en postfix. Dado que no hemos eliminado nuestro dominio mail1.org de mydestination, postfix comprueba que el usuario es un usuario local para lo cual usa el valor de la directiva local_recipient_maps:

# postconf local_recipient_maps
local_recipient_maps = proxy:unix:passwd.byname $alias_maps

que básicamente comprueba si el nombre se encuentra en /etc/passwd o listado en /etc/alias. En consecuencia, cuando se envíe mensaje a un usuario virtual, se devolverá un error de que el usuario no existe (»User unknown in local recipient table»). Para evitarlo puede redefinirse como vacía la directiva, que deshabilita la comprobación,pero eso lo desaconseja enérgicamente la documentación oficial, así que lo que haremos es redefinirla para que se busquen también los usuarios en la base de datos:

local_recipient_maps = proxy:unix:passwd.byname $alias_maps sqlite:/etc/postfix/tb/users.cf

y este fichero /etc/postfix/tb/users.cf debe ser el siguiente:

dbpath = /etc/dovecot/private/users.db
query = SELECT 'OK' FROM users WHERE userid || '@' || domain = '%s' AND active = 'Y'

Nota

Por la forma en que hemos configurado dovecot, los mensajes enviados al dominio localhost, se entregarán si el usuario es un usuario real del sistema, pero no si es un usuario exclusivo. No debería ser un problema, puesto que sólo tendría sentido usar esas direcciones dentro del sistema y los usuarios exclusivos no tienen acceso a él.

7.3.3.4.2. Usuarios en varios dominios

Nota

Cerciórese primero de que el paquete postfix-sqlite está instalado en el sistema.

Para gestionar varios dominios con postfix lo más sencillo es configurar con dovecot la autenticación, la entrega de mensajes y la gestión de usuarios de los distintos dominios. A continuación, debemos rematar la configuración en postfix:

mydestination = sqlite:/etc/postfix/tb/domains.cf, localhost
local_recipient_maps = proxy:unix:passwd.byname $alias_maps sqlite:/etc/postfix/tb/users.cf
mailbox_transport = lmtp:unix:private/dovecot-lmtp
#transport_maps = sqlite:/etc/postfix/tb/transports.cf
virtual_alias_maps = sqlite:/etc/postfix/tb/aliases.cf

Advertencia

Recuerde que tendrá que usar postmap después de crear cada fichero.

/etc/postfix/tb/users.cf debe contener lo expuesto bajo el epígrafe anterior. De hecho, convendría que leyera tal epígrafe, si aún no lo ha hecho.

El fichero /etc/postfix/tb/domains.cf nos permite obtener los dominios que gestionamos de la base de datos sin tener que escribirlos directamente:

dbpath = /etc/dovecot/private/users.db
query = SELECT domain FROM domains WHERE domain='%s'

Si definimos cuentas virtuales en la base de datos entonces deberemos obtenerlas consultando en ella, consulta que declara /etc/postfix/tb/aliases.cf:

dbpath = /etc/dovecot/private/users.db
query = SELECT
          CASE WHEN goto IS NULL
            THEN userid || '@' || domain
            ELSE goto
          END AS goto
        FROM aliases WHERE address='%s' AND active = 'Y'

En principio, el único transporte que necesitaremos es el LMTP de dovecot, así que transport_maps no será necesario, pero en caso contrario /etc/postfix/tb/transports.cf debe quedar así:

dbpath = /etc/dovecot/private/users.db
query = SELECT transport FROM domains WHERE domain='%s'

Advertencia

transport_maps se consulta antes de que opere el agente local de postfix. En consecuencia, para los dominios que definan el transporte a través de la base de datos, no tendrá validez lo dispuesto para este agente (como las definiciones de /etc/aliases).

Podemos comprobar cómo resolverá postfix las consultas SQL del siguiente modo:

# postmap -q 'mail1.org' sqlite:/etc/postfix/tb/domains.cf
mail1.org

Notas al pie

[1]

Al usuario se le ha dado el uid 500 para separarlo del resto de usuarios normales (que tienen uid por encima del 1000 en debian) y para que cumpla la restricción de dovecot que exige que los usuarios de correo tenga un uid a partir de este número.

[2]

Obsérvese que la configuración incluye la definición de virtual_alias_maps, el cual ya se definió anteriormente para otros propósitos. Si queremos mantenerlos, basta con separar con comas todos los ficheros:

virtual_alias_maps = hash:/etc/postfix/vmailbox, regexp:/etc/postfix/desechables, hash:/etc/postfix/vusermaps

[3]

Desgraciadamente hay que escribir los usuarios uno a uno. Sin embargo, si decidiéramos que los usuarios exclusivos cumplieran una regla de nombrado que los distinguiera de los usuarios reales, entonces sí sería posible usar una expresión regular. Por ejemplo, si decidiéramos, que todos los nombres de usuarios exclusivos acaban en .vir, de modo que nuestros usuarios son de la forma pepe.vir, paco.vir, etc. Podríamos hacer lo siguiente:

virtual_alias_maps = regexp:/etc/postfix/vusermaps

y crear el fichero así:

# cat > /etc/postfix/vusermaps
/(.+)\.vir@mail1\.org$/    $1.mail1.vusers

Advertencia

Téngase en cuenta, en este caso, que eliminar el punto de los nombres es un problema, y esto:

virtual_alias_maps = pcre:/etc/postfix/desechables, regexp:/etc/postfix/vusermaps

provocaría que jamás se detectaran los usuarios exclusivos. En este caso, podríamos eliminar todos los puntos, excepto aquel que antecede a .vir, haciendo uso de expresiones regulares de perl (de ahí que hayamos escrito pcre: y no regexp:. La línea que deberíamos incluir en el fichero es:

/(.*)\.(?!vir@)(.*@mail1\.org)$/    $1$2

[4]

Según la documentación (virtual(8)), para virtual_mailbox_maps las substituciones de expresiones regulares están deshabilitadas, por lo que no podemos resolver la asignación de buzones con ellas.

[5]

Esto último no es cierto y podrían seguirse entregando los mensajes con postfix mediante la conversión de los dominios en virtuales y el uso de virtual_mailbox_maps, virtual_uid_maps y virtual_gid_maps con consultas a la base de datos sqlite para definir la información de usuario necesaria. La solución, no obstante, es más engorrosa y no funcionará del todo bien con las cuotas definidas en dovecot.