User Tools

Site Tools


doc:appunti:linux:sa:exim

Exim 4

Autenticazione SMTP

Come attivare il supporto AUTH LOGIN oppure AUTH PLAIN, la password passa in chiaro con comandi SMTP del tipo:

AUTH LOGIN

EHLO ulisse.texnet.org
AUTH LOGIN
bmljY29sbw==
c2NlbW9jaGlsZWdnZQ==
MAIL FROM: ...

Login e password sono in chiaro, semplicemente codificati in base64 (senza il newline in fondo):

# echo -n niccolo | base64
bmljY29sbw==

AUTH PLAIN

EHLO ulisse.texnet.org
AUTH PLAIN bmljY29sbwBuaWNjb2xvAHNjZW1vY2hpbGVnZ2U=
MAIL FROM:...

Anche in questo caso username e password sono in chiaro codificate in base64:

echo -ne "\000username\000password" | base64

Attenzione, all'inizio della stringa (prima del carattere \000) potrebbe esserci il prefisso login oppure user.

In Exim4 si può attivare l'autenticazione basata sul Courier authdaemond, ad esempio aggiungendo il file conf.d/auth/25_local-courier_authdaemon (ricavato da 30_exim4-config_examples) con:

### auth/25_local-courier_authdaemon
#################################

# Authenticate against courier authdaemon

# This is now the (working!) example from
# http://www.exim.org/eximwiki/FAQ/Policy_controls/Q0730
# Possible pitfall: access rights on /var/run/courier/authdaemon/socket.

# SMTP authenticator "AUTH PLAIN"
plain_courier_authdaemon:
  driver = plaintext
  public_name = PLAIN
  server_condition = \
  ${extract {ADDRESS} \
           {${readsocket{/var/run/courier/authdaemon/socket} \
           {AUTH ${strlen:exim\nlogin\n$auth2\n$auth3\n}\nexim\nlogin\n$auth2\n$auth3\n} }} \
           {yes} \
           fail}
  server_set_id = $auth2
  .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
  server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
  .endif

# SMTP authenticator "AUTH LOGIN
login_courier_authdaemon:
  driver = plaintext
  public_name = LOGIN
  server_prompts = Username:: : Password::
  server_condition = \
  ${extract {ADDRESS} \
           {${readsocket{/var/run/courier/authdaemon/socket} \
           {AUTH ${strlen:exim\nlogin\n$auth1\n$auth2\n}\nexim\nlogin\n$auth1\n$auth2\n} }} \
           {yes} \
           fail}
  server_set_id = $auth1
  .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
  server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
  .endif

Per le versioni più vecchie di Exim (es. la 3?) sostituire le variabili consigliate $auth1, $auth2 e $auth3 con le obsolete $1, $2 e $3. Vedere anche questa pagina per un problema del Courier authdaemon.

Attenzione che in questo caso Exim deve accedere al socket /var/run/courier/authdaemon/socket, rispetto ad una installazione Debian 8 (Jessie) standard ci sono i seguenti permessi che impediscono ad Exim di accedere al socket:

drwxr-x--- 2 daemon daemon 100 Mar  8 15:38 /var/run/courier/authdaemon/

La soluzione suggerita è aggiungere l'utente Debian-exim al gruppo daemon. Verificare che la directory /var/run/courier/ abbia mode 0755, nelle precedenti release era 0750, non sufficiente.

Per abilitare l'autenticazione in chiaro (senza TLS) basta definire la macro in conf.d/main/00_local:

AUTH_SERVER_ALLOW_NOTLS_PASSWORDS = true

Cifratura TLS

Per abilitare la cifratura TLS su autenticazione e trsporto mail si deve anzitutto creare il certificato autofirmato per Exim, eseguire exim-gencert contenuto in /usr/share/doc/exim4-base/examples/ per ottenere i due file /etc/exim4/exim.crt e /etc/exim4/exim.key.

Per vedere il contenuto del certificato (scadenza, ecc.) e della chiave privata:

openssl x509 -noout -text -in /etc/exim4/exim.crt
openssl rsa -noout -text -in /etc/exim4/exim.key

Per abilitare l'uso di TLS e avvertire i client della sua disponibilità è sufficiente aggiungere la macro in /etc/exim4/conf.d/main/00_local:

MAIN_TLS_ENABLE = true

:!: ATTENZIONE: Se il certificato è scaduto il messaggio di errore potrebbe essere poco esplicito, del tipo:

TLS error on connection from [151.83.218.64] (recv): A TLS packet with unexpected length was received.
TLS error on connection from [151.83.218.64] (send): The specified session has been invalidated for some reason.
TLS error on connection from [151.83.218.64] (recv): A record packet with illegal version was received.
TLS error on connection from [151.83.218.64] (send): The specified session has been invalidated for some reason.

Questa configurazione abilita la cifratura con STARTTLS, cioè la porta di comunicazione è la tradizionale TCP/25 e la cifratura inizia dopo il comando STARTTLS.

Cifratura SSL su porta TCP/465

Questo metodo sarebbe obsoleto rispetto al TLS su porta TCP/25 (con uso del comando STARTTLS), tuttavia la pessima abitudine di alcuni provider di filtrare la porta 25 in uscita, lo rende ancora interessante.

Anzitutto si deve dire al demone di stare in ascolto sulle due porte: 25 e 465, in /etc/default/exim4 si mette (l'opzione -oP è necessaria quando si specifica l'opzione -oX):

SMTPLISTENEROPTIONS='-oX 465:25 -oP /var/run/exim4/exim.pid'

Quindi si deve indicare che sulla porta 465 si vuole usare la cifratura SSL (non il comando STARTTLS come si fa sulla tradizionale porta 25), in /etc/exim4/conf.d/main/03_exim4-config_tlsoptions si mette:

tls_on_connect_ports=465

Utilizzo dei system filter

Per testare un system filter usare la sintassi:

exim4 -bF system_filter < msg.txt

Per utilizzare un system filter (Exim 3) aggiungere una direttiva:

message_filter = /etc/exim/system_filter

Con Exim4 invece la sintassi è:

system_filter = /etc/exim4/system_filter

Blacklist basata su DNS

Supponiamo che esista una zona DNS (rbl.texnet.it) che contiene un record di tipo A per ogni host che non deve spedire posta. Per verificare l'indirizzo 88.38.109.50 Exim fa una richiesta di tipo: 50.109.38.88.rbl.texnet.it, se viene restituito un valore, la connessione è rifiutata.

Nel caso nostro il valore restituito contiene uno pseudo timestamp di quando l'host è stato blacklistato.

In Exim4, per aggiungere un controllo subito dopo il RCPT TO: basta mettere queste righe in conf.d/acl/30_exim4-config_check_rcpt, in mezzo agli altri deny:

  # Deny bad sites (IP address in rbl.texnet.it)
  deny
    message = ATTENZIONE: Il vostro indirizzo IP e' nella blacklist.\
        \nWARNING: Your IP address is blacklisted.\
        \nVisit http://rbl.texnet.it/?check_ip=$sender_host_address
    log_message = $sender_host_address is listed at $dnslist_domain ($dnslist_value: $dnslist_text)
    dnslists = rbl.texnet.it

Se vogliamo usare la blacklist solo per alcuni domini (ad esempio solo per quelli di cui facciamo il relay), si potrebbe usare una ACL del genere:

  # Deny relay to blacklisted hosts.
  deny
    message = WARNING: Your IP address is blacklisted: http://www.spamhaus.org/query/bl?ip=$sender_host_address
    log_message = $sender_host_address is listed at $dnslist_domain ($dnslist_value: $dnslist_text)
    domains = +relay_to_domains
    dnslists = zen.spamhaus.org

Anche questa inserita in 30_exim4-config_check_rcpt, prima della ACL che esegue l'accept.

Maildir vs Unix mbox

Per una configurazione completa del sistema per utilizzare le Maildir vedere Gestione posta con Maildir.

Per attivare le Maildir con Debian Etch basta verificare che in /etc/exim4/update-exim4.conf.conf sia presente l'opzione

dc_localdelivery='maildir_home'

Si deve verificare che la variabile d'ambiente MAIL degli utenti sia impostata correttamente in modo che mutt e programmi simili funzionino. Ecco alcuni consigli:

Console login

Per il login da console potrebbe essere necessario modificare il file /etc/pam.d/login, nelle precedenti release Debian si doveva agire sulla configurazione del modulo pam_mail.so di PAM in questo modo:

session optional pam_mail.so standard dir=~/Maildir

Riga di comando

Alcuni comandi utili:

exim4 -bP timeout_frozen_after Write to the standard output the value of Exim’s main configuration option.
exim4 -Mrm <message_id> Remove the given messages from the queue.
exim4 -v -M <message_id> Run a delivery attempt on each message in turn.
exim4 -bP Print the values of all Exim’s main configuration options.

Bounce messages

In those days of increasing spam messages, returning a bounce message including the mail body exposes to the risk to become a spam relay to the (forged) sender.

To avoid this, include the following rule in the Exim4 configuration file (main section):

# The default setting (true) causes the entire message,
# both header and body, to be returned in a bounce message.
bounce_return_body = false

:!: Beware of the trap: the bounce message can be generated by the target host or by your SMTP server, check the headers of the buonce message to understand who is generating it. I spent several minutes figuring out why my Exim4 ignored any of the bounce_* directives, just to realize that the bounce was generated on a different host!

Helo DNS lookup delay

Some broken mail clients sends an HELO or EHLO command with the IP address instead of the host name:

EHLO [127.0.0.1]

This can cause a DNS lookup delay of some seconds and the following warning message in Exim log:

2009-04-17 12:49:55 no host name found for IP address 192.168.100.63

I suggest you to use better mail clients or to arrange the DNS reverse resolution for that network.

Otherwise you can disable the reverse lookup for bad clients on your network. Add the following snippet into /etc/exim4/conf.d/main/00_local:

# Some clients sends this broken command: EHLO [127.0.0.1]
# Disable DNS lookup for broken clients on the local network.
#
MAIN_HOST_LOOKUP = !192.168.100.0/24
helo_lookup_domains = @

Backscatter SPAM through a secondary MX

The problem: a secondary MX server does not generally know if a mailbox is valid, so it will always accept a mail for a non-existent address. Then it passes the mail to the primary MX, which rejects the message at the SMPT level. So an error message should be generated.

If the original message was SPAM, a fake error message will be received by the forged From address. The message will contain the error message and - may be - a copy of the original SPAM.

This is why spmmers target secondary MXs: to get the so-called backscatter SPAM.

If we want to suppress those error messages, we can configure an Exim router, which intercepts the message from the primary MX and silently discards it:

### router/020_local-drop_backscatter_spam
#################################

drop_backscatter_spam:
    debug_print = "R: drop_backscatter_spam for $local_part@$domain"
    driver = redirect
    senders = :
    # The message is not for local and not for relay domains.
    domains = ! +local_domains : ! +relay_to_domains
    # To avoid loop: forward only to local or relay domains.
    #data = postmaster@example.com
    # Forward to /dev/null.
    data = :blackhole:
    condition = "${if and{ \
       {match{$message_body}{host mx1.example.com}} \
       {match{$message_body}{User unknown in local recipient table}}} \
    {true}}"
    allow_defer
    allow_fail

The only drawback is when a legitimate sender send a mail to a non-existent address. If in that moment the primary MX server is unreachable, the secondary MX will get the mail and will drop the subsequent error message.

Smarthost

In Debian configurare Exim per utilizzare uno smarthost è semplice, basta modificare il file /etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_smarthost='10.0.1.205'

Se non è necessario gestire posta localmente, è più indicata la configurazione satellite. È ovviamente possibile indicare uno hostname e una porta TCP (ad esempio la submission invece che la smtp):

dc_eximconfig_configtype='satellite'
dc_smarthost='mail.rigacci.org::587'

Dopo la modifica fare un reload di Exim e controllare che il file /var/lib/exim4/config.autogenerated contenga:

DCsmarthost=10.0.1.205

Per fare un test su quale transport viene usato si può usare il comando:

exim -bt "niccolo@rigacci.org"
R: smarthost for niccolo@rigacci.org
niccolo@rigacci.org
  router = smarthost, transport = remote_smtp_smarthost
  host smarthost.texnet.it [62.48.51.128] 

In assenza di smarthost invece si ha:

exim -bt "niccolo@rigacci.org"
R: dnslookup for niccolo@rigacci.org
niccolo@rigacci.org
  router = dnslookup, transport = remote_smtp
  host mail.rigacci.org [78.47.114.234] MX=10

Se lo smarthost richiede autenticazione, è possibile aggiungere le credenziali nel file /etc/exim4/passwd.client:

smarthost.domain.org:login:password

È necessario proteggere il file con permessi root:Debian-exim e mode 0640.

Se un messaggio non è partito (è rimasto in coda, il suo ID è visibile con mailq), è possibile chiedere un nuovo invio e tracciare la sessione con:

exim -v -M 1glXAU-0000Ig-1n

In questo modo è possibile verificare che lo smarthost annunci correttamente l'AUTH PLAIN LOGIN, magari solo dopo lo STARTTLS, e che Exim effettui tutta la sessione correttamente.

Smarthost per domini privati

Configurare uno smarthost per un dominio privato presenta qualche problema; anzitutto non è detto che si voglia pubblicare sul DNS un'informazione come il record MX per un dominio di posta privato. Inoltre se lo smarthost in questione è su un indirizzo IP privato (ad esempio raggiungibile tramite una VPN), Exim fallisce con il router dnslookup, generando messaggi di errore del tipo:

all relevant MX records point to non-existent hosts
lowest numbered MX record points to local host

In effetti Exim ha nella configurazione Debian l'opzione ignore_target_hosts con la quale esclude gli indirizzi IP RFC1918.

La soluzione più semplice è aggiungere un router del tipo:

### router/015_private_domains
#################################

# Private domains routed manually to a specific smarthost.
# We can use private IP addresses, otherwise prohibited.

private_smarthost:
  driver = manualroute
  domains = naxos.rigacci.org : naxos.my.rigacci.org
  transport = remote_smtp
  route_list = \
    naxos.rigacci.org    172.16.3.78 ; \
    naxos.my.rigacci.org 172.16.3.78

Address rewrite

Uno dei casi più utilizzati di address rewrite è modificare l'indirizzo mittente dei messaggi di sistema, che altrimenti risultano provenienti da qualcosa del genere: root@host.dominio.it. Per un server che non gestisce un dominio di posta tale indirizzo è quasi certamente inesistente, e il destinatario può facilmente rifiutarlo.

Exim onora il file /etc/email-addresses nel quale si inseriscono righe del tipo:

root: support@domain.it

in questo modo tutte le mail generate dall'utente locale root avranno il mittente indicato.

Fare attenzione alle informazioni SPF: il messaggio potrebbe essere rifiutato se il dominio email dichiara che gli host di origine dei messaggi sono altri.

Il metodo visto sopra consente di riscrivere solo gli indirizzi locali (cioè senza la parte @dominio). Per riscrivere anche gli indirizzi in messaggi ricevuti via SMTP si può aggiungere un pezzetto di configurazione, in Debian basta creare un file /etc/exim4/conf.d/rewrite/32_local-rewriting con qualcosa del genere:

### rewrite/32_local-rewriting
#################################

# Rewrite the headers: From, Sender, Reply-To and the envelope From
# Test it with:
#     exim -brw NAS@192.168.1.254

NAS@192.168.1.254  info@domain.org  fsrF
doc/appunti/linux/sa/exim.txt · Last modified: 2019/01/21 12:08 by niccolo