Hasta ahora he estado usando qmail. Perfecto, estupendo, pero cuando lo tienes en producción y quieres hacer algun cambio implica, casi siempre, aplicar un parche, recompilar e instalar. Se puede hacer claro está, pero no mola. Así que voy a probar la competencia, Postfix.
Lo que quiero probar es:
ahora accediendo a http://server/webmail (o en este caso http://server) se accede al webmail.
Nota: para ponerlo en español:
FETCHMAIL
Nota 2: me he encontrado de que si fetchmail recibe un email de tamaño superior a lo que acepta postfix, no entrega el correo, pero no lo borra de la cuenta externa. Para que lo borre hace falta poner las directivas:
REDIRECCION MAILS RECIBIDOS
Lo que quiero probar es:
- Gestión de usuarios lo mas facil = /etc/passwd
- Ver como funcionan los alias, ver que un alias puede enviar a varios destinatarios
- Acceso a pop3 / imap = Dovecot
- Uso de webmail -> squirrelmail (en caso de usar mysql se podría optar por horde)
- ver como usar el fetchmail para recoger mails externos y distribuirlos en las cuentas locales
- Redireccion 1: mail que recibe un usuario se reenvíe a otro
- Redirección 2: mail que envia un usuario se reenvíe a la vez a otro
- Antivirus
- Uso de un smarthost o relay y relay segun destino
- smtp auth
- TLS
- Firewall
- Otros
apt-get install postfix
dpkg-reconfigure postfix
postconf -e 'home_mailbox=Maildir/'
El archivo de configuración principal es el /etc/postfix/main.cf:
#cosas por defecto
smtpd_banner = Mailserver
biff = no
append_dot_mydomain = no
readme_directory = no
#TLS
...
#config
myhostname = testsrv
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = example.com, testsrv, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8, 10.0.0.0/16, 10.1.0.0/24, [::ffff:127.0.0.0]/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
home_mailbox = Maildir/
disable_vrfy_command = yes
ALIAS
estan en /etc/aliases, se retocan con un editor y después se ejecuta newaliases para que se refresque. Ejemplo:
postmaster: root
pepito: user1
grupo: user1, user2, user3
Los usuarios del sistema son user1, user2, user3. Un mail dirigido a pepito@example.org lo recibe user1.
fácil.
DOVECOT
Para permitir el acceso en pop3 instalo el dovecot:
apt-get install dovecot-pop3 dovecot-imap
los archivos de configuración estan en /etc/dovecot i hay que tener presente los siguientes parámetros:
protocols = pop3 pop3s imap imaps (aunque no hace falta especificarlo porque lo incluye de /usr/share/dovecot/protocols.d/*)
mail_location = maildir:~/Maildir (en /etc/dovecot/conf.d/10-mail.conf)
con doveconf -n vemos la configuración activa que es:
login_greeting = ready.
mail_location = maildir:~/Maildir
passdb {
driver = pam
}
protocols = pop3 imap
ssl_cert = blabla (los genera el apt-get)
ssl_key = blalba
userdb {
driver = passwd
}
WEBMAIL
Primero instalar servidor apache y php5
apt-get install apache2 php5
Probamos squirrelmail
apt-get install squirrelmail php-pear
squirrelmail-configure
Configuramos apache para el webmail
cp /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrel.confEl fichero de configuración:
ln -s /etc/apache2/sites-available/squirrel.conf /etc/apache2/sites-enables/000-squirrel
Alias /webmail /usr/share/squirrelmail
#Directory /usr/share/squirrelmail#
Options FollowSymLinks
#IfModule mod_php5.c#
php_flag register_globals off
#/IfModule#
#IfModule mod_dir.c#
DirectoryIndex index.php
#/IfModule#
# access to configtest is limited by default to prevent information leak
#Files configtest.php#
order deny,allow
deny from all
allow from 127.0.0.1
#/Files#
#/Directory#
# users will prefer a simple URL like http://webmail.example.com
#VirtualHost *#
DocumentRoot /usr/share/squirrelmail
ServerName webmail.example.com
#/VirtualHost#
ahora accediendo a http://server/webmail (o en este caso http://server) se accede al webmail.
Nota: para ponerlo en español:
dpkg-reconfigure localesEl webmail seria bueno ponerlo bajo SSL para encriptar la comunicación ya que se envían passwords. Por tanto tenemos que generar un certificado con su clave etc.
locale-gen es_ES
reiniciar apache y seleccionar el idioma en las opciones
- directorio de trabajo: mkdir /root/ssl
- generar una clave privada: openssl genrsa -out http.key
- generar un CSR para que nos lo firme una Autoridad: openssl req -new -key http.key -out http.csr
- crearnos nosotros mismos el certificado firmado por nosotros: openssl x509 -req -days 3650 -in http.csr -signkey http.key -out http.crt
- mkdir /etc/apache2/ssl
- cp http.crt http.key /etc/apache2/ssl
- chmod 400 /etc/apache2/ssl/*.key
- ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf
- ln -s /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/ssl.load
- /etc/init.d/apache2 restart
- antes del restart añadir la activación del ssl en el site (/etc/apache2/sites-enabled/000-squirrel)
# users will prefer a simple URL like http://webmail.example.com
#VirtualHost *:443#
DocumentRoot /usr/share/squirrelmail
ServerName webmail.example.com
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
SSLCertificateFile /etc/apache2/ssl/http.crt
SSLCertificateKeyFile /etc/apache2/ssl/http.key
SSLEngine on
#/VirtualHost#
Si quiero recoger el mail de un servidor externo uso fetchmail:
/home/user/.fetchmailrc (modos 700)
poll _server_Nota 1: me he encontrado que si no pongo el dropdelivered los emails que pilla fetchmail y entrega en postfix hacen un LOOP en aquellas cuentas que tengan un .forwardprotocol POP3 :
username "user"
password "password" dropdelivered
is "user_local" here
options fetchall forcecr
Nota 2: me he encontrado de que si fetchmail recibe un email de tamaño superior a lo que acepta postfix, no entrega el correo, pero no lo borra de la cuenta externa. Para que lo borre hace falta poner las directivas:
limit 10230000
limitflush
REDIRECCION MAILS RECIBIDOS
Si quiero que los mails que recibe el user1 los reciba también el user2 hacemos lo siguiente:
- creamos el fichero /home/user1/.forward
- ponemos el usuario a que se tiene que reenviar, uno por linia. OJO! si queremos que el destinatario original lo reciba no hay que olvidarlo incluirlo en el fichero.
Por tanto el fichero sería
user1
user2
Otra manera de hacerlo sería
- Crear un archivo de mapeado (/etc/postfix/rec_bcc)
- en ese archivo poner por linia
(ejemplo: user1@ejemplo.com user2@ejemplo.com) - ejecutar postmap /etc/postfix/rec_bcc
- en el main.cf poner la directiva "recipient_bcc_maps = hash:/etc/postfix/rec_bcc"
- reiniciar postfix
REDIRECCION EMAILS ENVIADOS
En postfix también tenemos la directiva sender_bcc_maps para lograrlo. El fichero se crea igual, se hace el postmap y se aplica la directiva en el main.cf de postfix.
ANTIVIRUS
- apt-get install clamav clamsmtp
- editar /etc/clamsmtpd.conf y cambiar OutAddress: 10025 a OutAddress: 10026. También cambiar Listen: 127.0.0.1:10026 a Listen: 127.0.0.1:10025. Con esto hacemos que el proxy clamsmtp escuche el puerto 10025 que sera donde postfix le enviará el mail y escupira el resultado por el puerto 10026
- editamos main.cf y ponemos
- content_filter = scan:127.0.0.1:10025
- receive_override_options = no_address_mappings
- editamos master.cf y ponemos
- # AV scan filter (used by content_filter)
- scan unix - - n - 16 smtp -o smtp_send_xforward_command=yes
- # For injecting mail back into postfix from the filter
- 127.0.0.1:10026 inet n - n - 16 smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o smtpd_helo_restrictions= -o smtpd_client_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks_style=host -o smtpd_authorized_xforward_hosts=127.0.0.0/8
Ahora nos quedaría acabar de configurar el clamsmtp para que cuando pille un virus haga algo, como enviar un mail al administrador.
- apt-get install procmail (el script uso el programa formail) mailutils
- Activar la opcion Quarantine del /etc/clamsmtpd.conf, sino la variable $EMAIL que recibe el script esta vacía y por tanto el formail no chuta
- en /etc/clamsmtpd.conf ponemos la directiva VirusAction: /usr/local/sbin/virus.sh (o el fichero que sea). + chmod 755.
- creamos el script:
LOGFILE=/var/log/virus.log
echo "`date +%b' '%d' '%T` Virus=$VIRUS To=$RECIPIENTS From=$SENDER File=$EMAIL" >> $LOGFILE
echo "An email sent to $RECIPIENTS was blocked by the anti-virus system.
If you believe this was in error please forward this email to your system administrator.
--------------------------------------------------------------------
Sender: $SENDER
`grep 'Subject:' $EMAIL`
Recipient: $RECIPIENTS
Virus Found: $VIRUS
File: $EMAIL
Here is the header of the offending message:
--------------------------------------------------------------------
`formail -X "" < $EMAIL`
--------------------------------------------------------------------
" |mail -s 'A Virus was Blocked' admin@ejemplo.com
Nota: instalar compresores para que el antivirus sea capaz de descomprimir los archivos (rar, 7z, zip, arj, etc).
Tambien nos interesa bloquear que se envien emails con adjuntos que sean .exe, .com, .bat, .vbs, etc. Para hacerlo podemos utilizar la directiva mime_header_checks:
Otra opción es que según el destino se use un relay. Por ejemplo por si algun servidor tiene un super-anti-spam que hace resoluciones inversas de tu ip y si ve que no coincide con el EHLO o mx del dominio te diga que tienes un BAD PTR, cosa que si usas una adsl no puedas controlar (pues los ptr los mete el que controla las ip's, usease, el isp). En este caso uso el transport_maps
SMTP AUTH
Tambien nos interesa bloquear que se envien emails con adjuntos que sean .exe, .com, .bat, .vbs, etc. Para hacerlo podemos utilizar la directiva mime_header_checks:
- editar /etc/postfix/main.cf y añadir mime_header_checks = regexp:/etc/postfix/badmime
- creamos el /etc/postfix/badmime:
# This entry will reject messages with attachments that could be dangerous,
# and will inform the sender of what type of attachemnt was rejected.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(ad[ep]|asd|ba[st]|c[ho]m|cmd|cpl|crt|dbx|dll|exe|hlp|hta|in[fs]|isp|js|jse|lnk|md[etw]|ms[cipt]|nws|ocx|ops|pcd|pi|pif|prf|reg|scf|scr|sct|sh[bms]|swf|uue|vb|vb[esx]|vxd|wab|ws[cfh]))"?\s*$/ REJECT ADJUNTO NO VALID "$3"..
# This will filter our certain types of attachments that can be considered
# dangerous.
/name=[^>]*your_details.zip/ REJECT Mail filters have determined that your email appears to be infected with the Sobig virus.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?((Attach|Information|TextDocument|Readme|Msg|Msginfo|Document|Info|Attachedfile|Attacheddocument|TextDocument|Text|TextFile|Letter|MoreInfo|Message)\.zip)"?\s*$/ REJECT Mail filters have determined that your email appears to be infected with the Bagle virus.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?((Patch|MS-Security|MS-UD|UpDate|sys-patch|MS-Q).*\.zip)"?\s*$/ REJECT Mail filters have determined that your email appears to be infected with the Sober virus.
/^\s*Content-(Disposition|Type).*name\s*=\s*"?((doc_word3_|document_all_|part01_|product_|letter_|information_|document_|details_|screensaver_|website_|data_|text_|file_|prod_info_).*\.zip)"?\s*$/ REJECT Mail filters have determined that your email appears to be infected with the Netsky virus.
# Facil
#/name=[^>]*\.(bat|com|exe|dll|vbs)/ REJECT adjunto no valido
NOTA: aparte del REJECT hay otras opciones como el DISCARD(lo descarta y no avisa a nadie), IGNORE, WARN, HOLD,...
NOTA2: tambien disponemos del header_checks para revisar algun campo de la cabecera del mail, como el subject por ejemplo, o el body_checks que lo mira todo.
SMARTHOST
Un smarthost es otro servidor de correo al que usaremos para enviar nuestros emails. Es decir, mi postfix recibira los envíos que quieren hacer sus usuarios y utilizará el smarthost para hacer el envío, así pues, el mail tiene un hop mas (remitente -> postfix -> smarthost -> destinatario). Para configurarlo hacemos los siguiente:
- Creamos el fichero con la autentificacion smtp del smarthost, si tiene. Por ejemplo en /etc/postfix/sasl/smarthost
- el formato es "servidor user:pass". Por ejemplo yo pongo "smtp.server.com:587 user:pass"
- chmod 0600 /etc/postfix/sasl/smarthost
- postmap hash:/etc/postfix/sasl/smarhost
- editamos /etc/postfix/main.cf
#envio por smarthost
relayhost = smtp.server.com:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/smarthost
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CAfile = /etc/postfix/sasl/cacert.pem (copiado de /etc/ssl/certs/thawte_premium.pem)
Otra opción es que según el destino se use un relay. Por ejemplo por si algun servidor tiene un super-anti-spam que hace resoluciones inversas de tu ip y si ve que no coincide con el EHLO o mx del dominio te diga que tienes un BAD PTR, cosa que si usas una adsl no puedas controlar (pues los ptr los mete el que controla las ip's, usease, el isp). En este caso uso el transport_maps
- crear fichero auth del relay, p.e. /etc/postfix/transport
- formato es "destino.com smtp:relay.com:587"
- postmap hash:/etc/postfix/transport
- se sigue necesitando el fichero de auth smarthost como antes
- main.cf:
transport_maps = hash:/etc/postfix/transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/smarthost
smtp_sasl_security_options = noanonymous
smtp_always_send_ehlo = yes
smtp_use_tls = yes
smtp_tls_CAfile = /etc/postfix/sasl/cacert.pem (copiado de /etc/ssl/certs/thawte_premium.pem)
La idea del auth para el smtp es permitir que algunos clientes FUERA de mi red puedan conectarse al postfix para enviar correos a destinatarios que no son locales. Ejemplo: un smartphone conectado por algun sitio en internet pueda enviar emails desde mi servidor.
- apt-get install libsasl2-2 sasl2-bin libsasl2-modules
- editamos /etc/default/saslauthd. Lo activamos (start=yes) y seleccionamos un metodo de authentificación (para mi caso pam o shadow -aunque ojo con los permisos entonces-).
- OJO! si postfix esta en chroot (mirar master.cf) entonces tenemos que cambiar el path de la opción de saslauth -m para que el proceso lo pueda leer. Por ejemplo /var/spool/postfix/var/run/saslauthd
- Creamos el directorio /var/spool/postfix/var/run/ + chown root.sasl + chmod 755
- /etc/init.d/saslauthd start y vemos como crea en ese directorio sus archivos.
- Creamos el fichero /etc/postfix/sasl/smtpd.conf (asi limitamos los tipos de authentificacion)
pwcheck_method: saslauthd
mech_list: plain login
- Configuramos /etc/postfix/main.cf para que use sasl
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
- Activamos la auth con sasl
- ponemos noanonymous para que obligue al cliente a authentificarse y no salte a otro tipo de auth
- la mas interesante es smtpd_recipient_restrictions:
- permit_sasl_authenticated = si se conecta uno al puerto 25 y se autentifica por sasl le deja enviar a donde sea
- permit_mynetwords = si se conecta una maquina con IP dentro de mynetworks, le deja hacer relay. Aunque con thunderbird, pide password igualmente, jarl! así que en el config de thunderbird hay que informar del usuario para el smtp (que como sera el mismo que pop3 y tiene el pass guardado, es transparente), aunque no debería! pero supongo que es porque hay clientes que cuando ven auth available lo interpretan como auth required :(.
- reject_unauth_destination = si se conecta uno (externo y sin autentificar) solo le deja enviar mails LOCALES, es decir, dirigidos a $mydestination, así permito que servidores externos envíen emails A mis usuarios mientras que mi servidor SOLO enviará emails a externos si el que lo envia es una maquina de mi red o si esta autentificado (smarthpone?)
Ahora si entro por telnet al servidor y haciendo un ehlo pepe veo que me escupe las opciones que tiene disponibles, entre ellas el 250-AUTH. Perfect. Hora de testearlo:
- Generamos la string AUTH: echo -ne '\000user\000password' | openssl base64
- telnet 127.0.0.1 25 y despues de hacer el ehlo ponemos AUTH PLAIN stringbase64
- nos debe aceptar
- Me he encontrado con un problema que no me autentificaba y resulta que era porque el usuario postfix no estaba dentro del grupo de sasl...
TLS
Bien, una vez tenemos el auth vemos que los clientes internos pueden hacer relay (o no...), los usuarios autentificados pueden hacer relay y los servidores del mundo pueden enviar emails a los destinatarios de nuestras redes. Lo único que queda es encriptar la comunicación.
- Creamos los certificados y claves como hicimos para el http
- mkdir /etc/postfix/tls; cd /etc/postfix/tls
- openssl genrsa -rand /etc/hosts -out mail.key 1024
- openssl req -new -key mail.key -out mail.csr
- openssl x509 -req -days 3650 -in mail.csr -signkey mail.key -out mail.crt
- chmod 400 mail.key
- editamos /etc/postfix/main.cf
# TLS parameters
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtpd_tls_auth_only = no
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/tls/mail.key
smtpd_tls_cert_file = /etc/postfix/tls/mail.crt
smtpd_tls_log_level = 1
tls_random_source = dev:/dev/urandom
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
En los thunderbird configuramos que la constraseña va por STARTTLS para que cifre el email. Con tcpdump -nn -X -i eth0 dst port 25 vemos como al recibir los emails estan totalmente cifrados.
Para cambiar el puerto de envio cifrado podemos modificar el /etc/postfix/master.cf:
Si descomentamos el submission:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
Se abre el puerto 587 que obliga a usar encriptación para enviar el mail, ya que si desactivamos el STARTTLS del cliente, el servidor te dará un error.
O bien también podemos descomentar del /etc/postfix/master.cf la parte de smtps:
#smtps inet n - - - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
entonces abre el puerto 465 y el envío tambien sera encriptado.
En ambos casos, y para el caso de thunderbird, para poder enviar emails hay que aceptar los certificados que hemos creado para la encriptación.
Observaciones
Para mi caso adjunto un ejemplo de firewall
OTROS
Ahora podemos mirar los siguientes artículos para ver como clasificar los emails o enviar notificaciones de 'vacaciones' de forma automática:
http://beavies.blogspot.com.es/2012/06/reclasificar-emails-con-dovecot-sieve.html
http://beavies.blogspot.com.es/2012/07/mail-de-ausencia-automatico-con-dovecot.html
También puede ser necesario limitar el nº de conexiones smtp que pueda hacer nuestro servidor, sobretodo si tenemos una subida a internet un poco churra. Para hacerlo hay que modificar el archivo master.cf y poner un nº de procesos en la linea "smtp unix -........ smtp". Esto limita el nº de procesos de smtp y por tanto el nº de conexiones simultaneas.
- Abrir el puerto 587 creo que es recomendable si se quiere que los smarthpones se puedan autentificar de forma segura con el servidor y tener relay.
- Si los clientes internos de $mynetworks los configuramos también para que se autentifiquen (se ve que el thunderbird lo quiere así al activar el smtp auth) podemos hacer que usen el puerto 587 también, así seguro que se encripta la comunicación. Si nos fijamos, vemos que el puerto 587 (submission) hace una directiva de smtpd_client_restrictions que podríamos aplicar sobre el main.cf y así evitar que clientes "desconocidos" de nuestra red puedan hacer relay (permit_mynetworks que pusimos en smtpd_recipient_restrictions).
- Por tanto tenemos que pensar si este servidor va a recibir correo directamente de Internet, pues entonces se necesitaría por una parte tener el puerto 25 abierto y disponible con el reject_unauth_destination para poder recibir los correos del mundo destinados a nuestras redes. Curiosamente, podríamos bloquear vía iptables el uso del puerto 25 de la red interna por si se cuela un virus y empieza a enviar spam. El puerto 25 pues solo seria necesario para los servidores externos que nos envían mail y el propio servidor desde el squirrelmail.
- También podemos pensar de que ya que todo cliente interno va a usar el puerto 587 para enviar emails, estará por tanto autentificado y por tanto podríamos eliminar el permit_mynetworks. Pero no lo podemos eliminar porque sino localhost no podrá hacer relay -> cagada en el webmail. Lo que si se puede es quitar la red interna de mynetworks ya que la red interna se autentificará (como las otras)
- Con los servicios de pop3 / imap podemos pensar igual, solamente habilitar el pop3s y el imaps (y reconfigurar correctamente el squirrelmail para que use imaps (993 y tls))
Para mi caso adjunto un ejemplo de firewall
#!/bin/bash # CONFIGURACIO VARIABLES # LAN_IFACE="eth0" LAN_IP="10.0.0.4" LAN_IP_RANGE="10.0.0.0/16" VPN_IP_RANGE="10.1.0.0/16" LO_IFACE="lo" LO_IP="127.0.0.1" IPTABLES="/sbin/iptables" ####################################################### # FILTER ####################################################### # Politiques $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F # # Chains # $IPTABLES -N bad_tcp_packets $IPTABLES -N icmp_packets # bad_tcp_paquets $IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP # icmp_paquets $IPTABLES -A icmp_packets -p icmp --icmp-type 8 -j ACCEPT $IPTABLES -A icmp_packets -p icmp --icmp-type 11 -j ACCEPT # # INPUT # $IPTABLES -A INPUT -p tcp -j bad_tcp_packets $IPTABLES -A INPUT -p icmp -j icmp_packets $IPTABLES -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT # control access de la xarxa interna # SSH $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $LAN_IP_RANGE --dport 22 -j ACCEPT $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $VPN_IP_RANGE --dport 22 -j ACCEPT # Postgres $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $LAN_IP_RANGE --dport 5432 -j ACCEPT # SMTP con TLS $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $LAN_IP_RANGE --dport 587 -j ACCEPT $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $VPN_IP_RANGE --dport 587 -j ACCEPT # Pop3s $IPTABLES -A INPUT -p tcp -i $LAN_IFACE -s $LAN_IP_RANGE --dport 995 -j ACCEPT # serveis globals # HTTP $IPTABLES -A INPUT -p tcp -i $LAN_IFACE --dport 80 -j ACCEPT # HTTPs $IPTABLES -A INPUT -p tcp -i $LAN_IFACE --dport 443 -j ACCEPT # IMAPs $IPTABLES -A INPUT -p tcp -i $LAN_IFACE --dport 993 -j ACCEPT # algunos dispositivos envian emails sin autentificarse # (scanners u otros) $IPTABLES -A INPUT -p tcp -s 10.0.0.13 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.0.11 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.0.15 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.1.11 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.3.11 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.3.12 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.4.10 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.1.2 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.0.3 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.3.2 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.3.3 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.4.3 --dport 25 -j ACCEPT $IPTABLES -A INPUT -p tcp -s 10.0.2.3 --dport 25 -j ACCEPT # lo $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
OTROS
Ahora podemos mirar los siguientes artículos para ver como clasificar los emails o enviar notificaciones de 'vacaciones' de forma automática:
http://beavies.blogspot.com.es/2012/06/reclasificar-emails-con-dovecot-sieve.html
http://beavies.blogspot.com.es/2012/07/mail-de-ausencia-automatico-con-dovecot.html
También puede ser necesario limitar el nº de conexiones smtp que pueda hacer nuestro servidor, sobretodo si tenemos una subida a internet un poco churra. Para hacerlo hay que modificar el archivo master.cf y poner un nº de procesos en la linea "smtp unix -........ smtp". Esto limita el nº de procesos de smtp y por tanto el nº de conexiones simultaneas.
Comentarios