Di default Postfix accetta esclusivamente connessioni dal network locale e dai domini che ospita ma in situazioni di rete complesse può essere necessario assumere un maggiore controllo sulle connessioni al server.
Per questo vengono incontro numerosi parametri del file main.cf con cui è possibile effettuare diversi controlli sul traffico di posta del server.
Attraverso il main.cf si può:
Stabilire il comportamento del server al momento della connessione del client.
Si lavora a livello del protocollo SMTP andando a modificare il comportamento del server.
Ad esempio costringendo il server ad accettare connessioni strettamente aderenti allo standard stabilito nella rfc 821 o modificandone il comportamento in concomitanza con alcuni comandi SMTP.
I parametri per queste operazioni riguardano comandi interni al protocollo SMTP, è consigliabile leggere le RFC sull'argomento e fare riferimento alla documentazione ufficiale del pacchetto.
Un parametro tra questi che può essere importante è
smtpd_helo_restrictions = valori
che permette di definire diverse regole di comportamento del server in relazione a quali host possono inviare un comando HELO
, l'inizio di norma di qualunque connessione SMTP. Questo parametro è equivalente e viceversa ad altri utilizzabili nel main.cf, come restringere i nomi dei client o i loro indirizzi IP con il parametro
smtpd_client_restrictions = valori
oppure agire sul campo sender
smtpd_sender_restrictions = valori
o sul comportamento del relay della posta
smtpd_recipient_restrictions = valori
Effettuare controlli sugli header di un messaggio e sul corpo dei messaggi.
Stabilendo delle regole di filtraggio delle intestazioni di un messaggio contenenti informazioni sul tipo di programma client e sulle macchine attraverso cui il messaggio è passato dando la possibilità in questo modo di implementare delle liste nere di server da cui non accettare mai la posta e filtrando i contenuti di un messaggio stabilendo delle liste di termini non permessi. Per i parametri e il metodo da usare per implementare questo tipo di controlli fare riferimento alla documentazione ufficiale di Postfix
Restringere l'inoltro della posta per quanto riguarda l'utente specificato nel campo "sender".
In questo modo si può stabilire che il server non accetti posta da client che non specificano un nome di dominio FDQN oppure accettare l'inoltro solo da utenti definiti.
Il parametro che si occupa di questa operazione è
smtpd_sender_restrictions = valori
La sua sintassi, simile nei parametri complementari visti in precedenza, permette di restringere l'uso del server di posta agendo sul campo sender. Opzioni possibili per questo sono
reject_unknown_sender_domain
reject_non_fqdn_sender
oppure un file database con le specifiche per i sender autorizzati con l'utilizzo di una sintassi particolare tipo_file:percorso_file
hash = /etc/postfix/access
Agire sui recipient di inoltro della posta.
Stabilendo regole sulla funzione di relay del server e agendo in sostanza sugli indirizzi concessi nel campo SMTP RCPT TO
di modo da limitare o dare accesso per il relay della posta a client non appartenenti alla sotto-rete del server. Questo metodo è consigliato quando si utilizzano controlli di accesso tipo pop-before-smtp
che permette l'uso del relay solo a client che si sono autenticati via pop precedentemente.
Il parametro principale è
smtpd_recipient_restrictions = valori
le cui opzioni impongono che sia presente sempre una voce tipo reject, defer, defer_if_permit o reject_unauth_destination altrimenti il server rifiuterà comunque la ricezione di posta.
Per esempio quindi si userà
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
Questo parametro è utilizzabile anche specificando un'opzione di controllo sui client
check_client_access = tipo_file:percorso_file
Le combinazioni di parametri e opzioni possono rendere una configurazione molto complessa e le possibilità offerte sono innumerevoli, è consigliabile prima di approfondire con la configurazione accertarsi di aver compreso come funziona il protocollo SMTP visitando il sito delle request for comments http://www.rfc-editor.org e cercando le rfc 821 e 2821.
McAfee 8.0 è COLPEVOLE
Viruscan 8.0 per windows fa un blocco sulleporte... se disabilito l'antivirus allora mi connetto!
Spargete voce...
Prove...
Postfix effettivamente è in ascolto su ogni porta:
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
e sul server il firewall sembra effettivamente disattivato (eventualmente prova un iptables -L -n -v -t nat per verificare che non ci siano inopportuni nat).
Non è necessario che esista un reverse nel DNS per i client (al limite rallenta, ma non impedisce, il login alla porta 25, se Postfix è configurato per fare un reverse lookup e va in timeout ).
Il fatte che alcune prove vadano a buon fine altre no, può essere dovuto a vari problemi, da verificare:
- Routing fra client e server;
- Firewall fra client e server (compresi eventuali personal firewall)
- Interfacce del server collegate allo stesso dominio di broadcast (lo stesso swicth o vlan): questo potrebbe dare problemi con arp reply dal server al client: verifica sul client, con arp -a che il mac address dell'ip che cerchi di contattare sia effettivamente quello dell'interfaccia relativa sul server. Dalle macchine che nin riescono a contattare il server sulla porta 25, riesci a pingarlo, usando lo stesso IP?
- Tutte quelle cose che è difficile elencare a voce ma che "vengono fuori" facendo un po' di troubleshooting (per esempio prova "tcpdump -n -i eth0" per sniffare i pacchetti che il server riceve sull'interfaccia eth0 )
good luck
SMTP Il mistero si infittisce...
Ringrazio AL per avermi indicato queisti utilissimi comandi di diagnostica...
Fino a Giovedì non posso mettere mano al server di cui parlavo, ho messo su di una seconda partizione del PC che ho al lavoro un altro fedora3 e Postfix mi da lo stesso problema!!! Dai diagnostici sembrerebbe tutto OK.
[root@networkman0 ~]# netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
...
Firewall apertissimo:
[root@networkman0 ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2003 2225K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1998 2213K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
In realtà da qualche PC la connesiione avviene correttamente, da altri no. L'ambiente in cui sono non ha un DNS (winNT4), ne ho montato io uno di fortuna, ma non ho messo le registrazioni dei client. A volte va, a volte no. Riavviando un pc, a volte va, a volte no. Il DNS serve a qualcosa? è importante registrare i nomi dei client e relativi PTR?
Grazie ancora.
Diagnostica....
Per capire la situazione meglio sarebbero utili gli output dei seguenti comandi:
- netstat -nat
- /etc/init.d/iptables status (o iptables -L -n -v )
Non basta...
inet_interface=all è già di default, in più ho provato a forzarlo ed a provare le varie "combinazioni". Niente da fare!!!!! La cosa buffa e che se faccio dalla macchina stessa "TELNET 25" e metto come ip uno consentito, funziona, se metto uno non consentito (altra scheda di rete) non funziona. Così dovrebbe essere anche se fo telnet da un altro PC, invece dagli altri PC non va!!!!! Non è che cerca un DNS col puntatore inverso? Mi prendono 1000 dubbi...
Grazie ancora!
simple
inet_interfaces = all
SMTP su interfacce non loopback
Sto cercando come un forsennato il parametro che dice a Postfix di ascoltare sulla 25 di tutte le interfacce: ho un server "3 homed" (fedora3) che adopererò come firewall fra: rete in produzione - aula corsi - internet su cui vorrei mettere anche un bel server di posta. Ma non mi si connette sulla 25 se non dall'indirizzo suo!!! Sono sicurissimo che il firewall non ha colpe. Ci sto diventando scemo...
Ringrazio in anticipo coloro che risponderanno.