/etc/postfix/main.cf.
mail.falcot.com. Esta es la única pregunta que se hace de forma predeterminada, pero la configuración que genera no es lo suficientemente completa para las necesidades de Falcot, por lo que los administradores deben ejecutar dpkg-reconfigure para poder personalizar más parámetros.
localhost, pero el dominio principal falcot.com tiene que ser agregado de forma manual. En general se deberían añadir todos los dominios para los que esta máquina debe ejercer como servidor MX; en otras palabras, todos los dominios para los cuales el DNS anuncie que esta máquina aceptará correo. Esta información acaba siendo escrita en la variable mydestination del archivo de configuración principal de Postfix — /etc/postfix/main.cf.
192.168.0.0/16 al valor predeterminado. Si no se realiza esta pregunta durante la instalación, la variable de configuración correspondiente es mynetworks, tal y como puede verse en el ejemplo siguiente.
procmail. Esta herramienta permite a los usuarios clasificar su correo en función de reglas contenidas en su archivo ~/.procmailrc. Tanto Postfix y Exim4 sugieren procmail por defecto, pero hay alternativas comomaildrop o filtros Sieve.
Ejemplo 11.1. Archivo /etc/postfix/main.cf inicial
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname
virtual_alias_domains y establezca un archivo de traducción de direcciones en la variable virtual_alias_maps.
virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual describe la relación con una sintaxis muy sencilla: cada línea contiene dos campos separados por espacios en blanco; el primer campo es el nombre del alias y el segundo es una lista de las direcciones de correo a las que se redirigen. La sintaxis especial @dominio.com abarca todos los alias pertenecientes a un dominio.
[email protected] [email protected] [email protected] [email protected], [email protected] # El alias siguiente es genérico y abarca todas las direcciones # del dominio falcotsbrand.com que no están incluidas explícitamente # en este archivo. # Estas direcciones reenvían el correo al usuario con el mismo nombre # del dominio falcot.com @falcotsbrand.com @falcot.com
/etc/postfix/virtual, la tabla postfix /etc/postfix/virtual.db necesita ser actualizada utilizando sudo postmap /etc/postfix/virtual.
virtual_mailbox_domains y hacer referencia a un archivo de asociación de casillas en virtual_mailbox_maps. El parámetro virtual_mailbox_base contiene el directorio en el que se almacenarán todas las casillas.
virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts
virtual_uid_maps (o virtual_gid_maps respectivamente) hace referencia al archivo que contiene la asociación entre las direcciones de correo y el usuario de sistema (o grupo respectivamente) «dueño» de la casilla correspondiente. Para lograr que todas las casillas pertenezcan al mismo usuario/grupo, la sintaxis static:5000 asigna un UID/GID fijo (aquí el valor 5000).
/etc/postfix/vmailbox es bastante directo: dos campos separados con espacios en blanco. El primer campo es una dirección de correo en alguno de los dominios virtuales y el segundo campo es la ubicación de la casilla asociada (relativa al directorio especificado en virtual_mailbox_base). Si el nombre de la casilla finaliza con una barra (/), se almacenarán los correos en formato maildir; de lo contrario se utilizará el formato mbox tradicional. El formato maildir utiliza un directorio completo para almacenar una casilla, cada mensaje individual es almacenado en un archivo separado. Por el otro lado, en el formato mbox se almacena toda la casilla en un archivo y cada línea que comience con «From (From es seguido por un espacio) indica el comienzo de un nuevo mensaje.
# Se almacena el correo de Jean como maildir, con # un archivo por correo en un directorio dedicado [email protected] falcot.org/jean/ # Se almacena el correo de Sophie en un archivo # «mbox» tradicional con todos los correos # en un solo archivo [email protected] falcot.org/sophie
soft_bounce = yes. Al preceder una directiva de dirección con warn_if_reject, solo se registra un mensaje en vez de rechazar la petición.
smtpd_client_restrictions controla qué máquinas pueden comunicarse con el servidor de correo.
Ejemplo 11.2. Restricciones basadas en la dirección del cliente
smtpd_client_restrictions =
permit_mynetworks,
warn_if_reject reject_unknown_client_hostname,
check_client_access hash:/etc/postfix/access_clientip,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_reverse_client rhsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.sorbs.netpermit_mynetworks, como primera regla, acepta todos los correos que provienen de equipos en la red local (definida por la variable de configuración mynetworks).
warn_if_reject antes de la directiva reject_unkown_client: este modificador convierte el rechazo en una simple advertencia guardada en los registros. Los administradores pueden revisar la cantidad de mensajes que hubiesen sido rechazados si esta regla hubiese sido aplicada y luego tomar decisiones informadas si desean activarla.
check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
HELO (o EHLO), seguido del nombre del servidor de correo que envía. Puede ser interesante comprobar la validez de este nombre. Para hacer cumplir las restricciones listadas en smtpd_helo_restrictions totalmente, la opción smtpd_helo_required necesita estar habilitada. De lo contrario, los clientes se saltarían las restricciones sin enviar ninguna orden HELO/EHLO.
Ejemplo 11.3. Restricciones en el nombre anunciado con EHLO
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
check_helo_access hash:/etc/postfix/access_helo,
reject_rhsbl_helo multi.surbl.orgpermit_my_networks permite que todas las máquinas en la red local se presenten libremente. Esto es importante ya que algunos programas de correo no respetan esta parte del protocolo SMTP de forma suficientemente correcta y pueden presentarse a sí mismos con nombres sin sentido.
reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
reject_rhsbl_helo permite especificar una lista negra para comprobar el nombre del equipo en una RHSBL.
permit_mynetworks como la primera regla tiene un efecto secundario interesante: las reglas siguientes sólo serán aplicadas a los equipos fuera de la red local. Esto permite rechazar todos los equipos que se anuncien a sí mismos como parte de la red falcot.com, por ejemplo agregando una línea falcot.com REJECT ¡No es parte de nuestra red! en el archivo /etc/postfix/access_helo.
MAIL FROM del protocolo SMTP; nuevamente, puede validar esta información de varias formas.
Ejemplo 11.4. Verificación de remitente
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_non_fqdn_sender,
reject_rhsbl_sender rhsbl.sorbs.net/etc/postfix/access_sender asocia algún tratamiento especial a algunos remitentes. Esto generalmente significa enumerar algunos remitentes en una lista negra o blanca.
reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from [email protected] are only accepted if such an address really exists.
reject_non_fqdn_sender rechaza los correos que dicen provenir de direcciones sin un nombre de dominio completamente calificado. En la práctica significa rechazar correos que provienen de usuario@equipo: la dirección debe anunciarse como [email protected] o [email protected].
reject_rhsbl_sender rechaza remitentes en base al servicio (basado en dominios) RHSBL.
RCPT TO en el protocolo SMTP. Estas direcciones también requieren validación, aún si pueden ser menos relevantes que las verificaciones realizadas en la dirección del remitente.
Ejemplo 11.5. Verificación de receptor
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
reject_non_fqdn_recipient,
permitreject_unauth_destination es la regla básica que requiere que los mensajes externos estén destinados a nosotros; se rechazarán los mensajes que sean enviados a una dirección que no sea gestionada por este servidor. Sin esta regla, el servidor se convierte en una forma abierta de reenvío que permite que los spammers envíen correos no solicitados; por lo tanto esta regla es obligatoria y preferentemente debe estar ubicada cerca del principio de la lista para evitar que otras reglas autoricen el mensaje antes que se verifique su destino.
reject_unlisted_recipient rechaza los mensajes enviados a usuarios locales que no existen, lo que tiene sentido. Finalmente, la regla reject_non_fqdn_recipient rechaza direcciones que no sean completamente calificadas; esto hace imposible enviar un correo a jean o jean@equipo y necesita, en cambio, utilizar la dirección completa como [email protected] o [email protected].
permit al final no es necesaria. Pero puede ser útil al final de una lista de restricciones para hacer la explícita la política predeterminada.
DATA en SMTP antes del contenido del mensaje. No provee ninguna información en sí misma además de anunciar lo que seguirá. Todavía puede ser sujeta a verificación.
reject_unauth_pipelining causa que se rechace el mensaje si el remitente envía una orden antes que se envía la respuesta a la orden anterior. Esto previene una optimización común utilizada por los robots de spammers ya que no tienen el menor interés en las respuestas y sólo están interesados en enviar tantos correos como sea posible en el menor tiempo posible.
RCPT TO por defecto.
EHLO no válida, Postfix conoce el remitente y el receptor cuando anuncia un rechazo. Luego puede registrar un mensaje más explícito de lo que podría si se hubiera interrumpido la transacción al comienzo. Además, una cantidad de clientes SMTP no esperan fallos en las primeras órdenes de SMTP y estos clientes no se molestarán tanto por este rechazo tardío.
smtpd_delay_reject controla el comportamiento por defecto.
Ejemplo 11.7. Habilitación de filtros basados en contenido
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
Ejemplo 11.8. Archivo /etc/postfix/header_checks de ejemplo
/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Su email contiene VIRUS/ DESCARTAR notificación de virus
GOTO Sarbacane (un software en correo masivo), el mensaje es rechazado. La segunda expresión revisa el asunto del mensaje; si menciona una notificación de virus podemos decidir no rechazar el mensaje sino, en cambio, descartarlo inmediatamente.
check_policy_service como una restricción adicional:
smtpd_recipient_restrictions =
permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.
smtpd_restriction_classes de la misma forma que smtpd_recipient_restrictions. La directiva check_recipient_access define luego una tabla que asocia un receptor dado con el conjunto de restricciones apropiadas.
Ejemplo 11.9. Definición de clases de restricción en main.cf
smtpd_restriction_classes = greylisting, aggressive, permissive
greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:10023
permissive = permit
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/recipient_accessEjemplo 11.10. El archivo /etc/postfix/recipient_access
# Direcciones sin filtro [email protected] permissive [email protected] permissive [email protected] permissive # Filtros agresivos para algunos usuarios privilegiados [email protected] aggressive # Regla especial para el administrador de la lista de correos [email protected] reject_unverified_sender # Listas grises de forma predeterminada falcot.com greylisting
clamav from the homonymous package.
clamav-milter. Un «milter» (apócope de «filtro de correo»: «mail filter») es un programa de filtrado diseñado especialmente para interactuar con servidores de correo. Un milter utiliza una interfaz de programación de aplicaciones (API: «Application Programming Interface») que provee un rendimiento mucho mejor que los filtros ajenos a los servidores de correo. Sendmail introdujo inicialmente a los milters, pero Postfix los implementó poco después.
dpkg-reconfigure clamav-milter. Cuando se le pregunte por la «Interfaz de comunicación con Sendmail», responda «inet:[email protected]».
dpkg-reconfigure clamav-base.
/etc/postfix/main.cf:
# Revisión de virus con clamav-milter smtpd_milters = inet:[127.0.0.1]:10002
systemctl reload postfix para que se tenga en cuenta el cambio.
include directive it must have one.
Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all
falcot.org.
#host -t TXT falcot.orgfalcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
postfix puede comprobar el registro SPF para correos entrantes usando el paquete postfix-policyd-spf-python, un intermediario de normas escrito en Python. El archivo /usr/share/doc/postfix-policyd-spf-python/README.Debian describe los pasos necesarios para integrar en postfix el intermediario, así que no lo repetiremos aquí.
/etc/postfix-policyd-spf-python/policyd-spf.conf, que está documentado de forma completa en policyd-spf.conf(5) y /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Los parámetros de configuración principales son HELO_reject y Mail_From_reject, que configuran si los correos deberían ser rechazados (Fail) o aceptados precediendo una cabecera (False), si las comprobaciones fallan. Lo último es muchas veces útil cuando el mensaje todavía se procesará por un filtro de spam.
Header_Type el valor AR.
postfix, añade una firma digital asociada con el nombre de dominio a la cabecera de los correos salientes. La parte receptora puede validar el cuerpo del mensaje y los archivos de cabecera comprobando la firma con una clave pública, que se recibe de los registros de los DNS de los remitentes.
opendkim-genkey -s SELECTOR -d DOMINIO. SELECTOR debe ser un nombre único para la clave. Puede ser tan simple como «correo» o la fecha de creación, si tiene pensado alternar las claves.
Ejemplo 11.11. Crear una clave privada para firmar los correos de falcot.com
#opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys#chown opendkim.opendkim /etc/dkimkeys/mail.*
/etc/dkimkeys/mail.private y /etc/dkimkeys/mail.txt y asignará la propiedad apropiada. El primer archivo contiene la clave privada, y el último la clave pública que necesita añadirse al DNS:
Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
-b 1024 para elegir un tamaño de clave más pequeño. Si opendkim-testkey tiene éxito, la entrada se ha ajustado correctamente. Aquí se explica la sintaxis de la entrada:
SOCKET y RUNDIR en /etc/default/opendkim. Tenga en cuenta que SOCKET debe ser accesible desde postfix en su entorno con chroot. La configuración adicional se realiza en /etc/opendkim.conf. Lo que sigue es un extracto de configuración, que se asegura de que Domain "falcot.com" y todos los subdominios (SubDomain) están firmados por el Selector "mail" y la única clave privada (KeyFile) /etc/dkimkeys/mail.private. La Canonicalization "relaxed" para tanto la cabecera como el cuerpo tolera una modificación ligera (por el software de una lista de correo, por ejemplo). El filtro se ejecuta tanto en modo (Mode) de firmado ("s" de signing) como de verificación ("v"). Si una firma falla al validar (On-BadSignature), el correo debería ponerse en cuarentena ("q" de quarantine).
[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim
KeyTable), dominios (SigningTable) y especificar equipos internos o de confianza (InternalHosts, ExternalIgnoreList), lo que puede enviar correo mediante el servidor como uno de los dominios que firman sin credenciales.
/etc/postfix/main.cf hacen que postfix use el filtro:
milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345
/etc/postfix/master.cf.
/usr/share/doc/opendkim/ y en las páginas de manual opendkim(8) y opendkim.conf(5).
_dmarc y la acción que se debería tomar cuando los correos que contienen su dominio como el equipo remitente fallen al validar usando DKIM y SPF.
#host -t TXT _dmarc.gmail.com_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"#host -t TXT _dmarc.yahoo.com_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"
reject) todos los correos que aparentan enviarse desde Yahoo, pero fallan las comprobaciones DKIM y SPF. Google Mail (Gmail) propaga una política muy relajada en la que tales mensajes del dominio principal aún deben aceptarse (p=none). Para subdominios deben marcarse como spam (sp=quarantine). A las direcciones dadas en la clave rua se les puede enviar informes agregados DMARC. La sintaxis completa se explica aquí:
postfix puede usar también esta información. El paquete opendmarc contiene el filtro de correo necesario. De forma similar a opendkim, SOCKET y RUNDIR deben elegirse en /etc/default/opendmarc (para zócalos de Unix debe asegurarse de que se pueden encontrar dentro del chroot de postfix). El archivo de configuración /etc/opendmarc.conf contiene comentarios detallados, y también se explica en opendmarc.conf(5). Por defecto, los correos que fallan la validación DMARC no se rechazan, sino se marcan añadiendo un campo de cabecera apropiado. Para cambiar esto, use RejectFailures true.
smtpd_milters y non_smtpd_milters. Si configuramos los filtros de correo opendkim y opendmarc para funcionar en los puertos 12345 y 54321, la entrada en /etc/postfix/main.cf tiene este aspecto:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321
/etc/postfix/master.cf.
saslpasswd2 que toma varios parámetros. La opción -u define el dominio de autenticación, que debe coincidir con el parámetro smtpd_sasl_local_domain en la configuración de Postfix. La opción -c permite crear un usuario y la opción -f permite especificar el archivo a utilizar si necesita almacenar la base de datos SALS en una ubicación diferente a la predeterminada (/etc/sasldb2).
#saslpasswd2 -u `postconf -h myservidor` -f /var/spool/postfix/etc/sasldb2 -c jean[... ingrese la contraseña de jean dos veces ...]
/etc/sasldb2 en un enlace simbólico que apunta a la base de datos utilizada por Postfix con ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
postfix al grupo sasl para que pueda acceder a la base de datos SASL. También necesitará agregar algunos parámetros nuevos para activar SASL y necesita configurar el parámetro smtpd_recipient_restrictions para permitir que los clientes autenticados por SASL puedan enviar correos libremente.
Ejemplo 11.12. Activación de SASL en /etc/postfix/main.cf
# Activar autenticación SASL
smtpd_sasl_auth_enable = yes
# Definir el dominio de autenticación SASL
smtpd_sasl_local_domain = $myhostname
[...]
# Agregar permit_sasl_authenticated antes de reject_unauth_destination
# permite reenviar correos enviados por usuarios autenticados por SASL
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
[...]/etc/postfix/master.cf. Para desactivar la autentificación por completo para el puerto 25 (servicio smtpd) añada la siguiente directiva:
smtp inet n - y - - smtpd
[..]
-o smtpd_sasl_auth_enable=no
[..]
AUTH desactualizada (algunos clientes de correo muy viejos lo hacen), se puede habilitar la interoperabilidad con estos usando la directiva broken_sasl_auth_clients.