Come posso consentire il pop3 locale ma applicare i pop3 remoti sul mio Ubuntu / Postfix / dovecot OS / MTA / MDA

Question

Come posso consentire il pop3 locale ma applicare i pop3 remoti sul mio Ubuntu / Postfix / dovecot OS / MTA / MDA

#1 da (0 voti)

1

Vorrei consentire ai client locali di accedere alle e-mail tramite qualsiasi pop3, pop3s, imap o imaps se lo fanno, ma limitano i client remoti solo a pop3 e imap, similmente a quello che faccio già per smtp usando la direttiva postfix :

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

La funzionalità più adatta che riesco a trovare in Dovecot è forzare tutti i client a utilizzare l'autenticazione sicura con la direttiva disable_plaintext_auth = yes .

Come soluzione temporanea, posso impostare disable_plaintext_auth = no e aggiungere linee al mio firewall usando iptables per consentire un accesso specifico alla porta in questo modo:

sudo iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 --dport 143 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --dport 993 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 --dport 110 -j ACCEPT
sudo iptables -A INPUT -i eth0 -p tcp --dport 995 -j ACCEPT

Ma questo sembra piuttosto hacky e introduce più problemi, ad esempio: questo non consentirà STARTTLS sulla porta 110 da un client remoto.

Esiste un altro modo per consentire ai client locali di autenticarsi con il mio sistema postfix / dovecot su una connessione protetta o non protetta, mentre impone ancora ai client remoti di utilizzare solo un'autenticazione sicura?

authentication email

posta Mr Purple 10.04.2013 - 00:48

fonte

1 risposta

Leggi altre domande sui tag authentication email

autorizzazione vs federazione vs diritto Triturazione gratuita dello spazio

score 0 · Accepted Answer

Non si desidera inviare password su testo non crittografato indipendentemente dal fatto che si tratti di un utente locale o non locale. È solo una cattiva pratica e gli argomenti del tipo "ma sta attraversando il mio interruttore fidato" inevitabilmente portano a una trappola. Farai un errore, o qualcun altro commetterà un errore, e improvvisamente scoprirai mesi dopo che in qualche modo gli aggressori sono stati in grado di annusare la password dell'account del tuo CEO e divulgare email riservate ai tuoi concorrenti. Basta non farlo.

Inoltre, parte della tua premessa non è corretta. Che cosa sta facendo postfix tramite permit_mynetworks non è la stessa cosa che farebbe imap in chiaro. Questa opzione di configurazione indica a postfix di accettare messaggi per l'inoltro da qualsiasi rete locale senza richiedere l'autenticazione - in modo che nessuna password attraversi la connessione non crittografata. Tuttavia, se si consente ai client locali di parlare direttamente con imap o pop3, invierà le password in chiaro tramite la rete. Altrimenti come sarebbe il server imap a distinguere l'utente bob da user alice.

Se la tua preoccupazione è il sovraccarico della crittografia, in realtà non è qualcosa di cui preoccuparsi in questi giorni. AES è molto veloce, specialmente se si sta utilizzando un sistema con supporto AES-NI nel processore (e un SO relativamente recente che lo utilizza in openssl). Il successo in termini di prestazioni non vale la pena di preoccuparsi delle password degli utenti che attraversano la rete in forma non crittografata.