Newsgroup: it.comp.os.linux.sys
Titolo: Consiglio su server di posta

salve a tutti,
ho l'esigenza di metter su un server di posta basato su software open 
source. poichè non ho alcuna esperienza in merito desideravo chiedere 
qualche consiglio circa il server da utilizzare (postfix, exim, 
sendmail, ...) e qualche indicazione circa la documentazione da leggere.
grazie a tutti

 Il mail-administrator-howto e' la' su 
www.tldp.org
 che ti aspetta.
io vorrei fare il chirurgo estetico, senza aver mai tenuto in
mano un bisturi beninteso, dici che un howto in giro c'e`? =)

 grazie a tutti
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0};printf("%s",c);return 0;}

Peppe ha scritto:

Allora, sendmail lo scarterei a priori, qmail non lo conosco ma me ne
hanno detto bene, postfix e exim li conosco e su quelli ti parlo...
Postfix:
DOCUMENTAZIONE: presso 
http://www.postfix.org/
PRO: abbastanza semplice da installare e configurare, robusto e abbastanza
sicuro, configurazione di nuovi utenti/nuovi domini abbastanza facile e
intuitiva, estensioni del programma via PlugIns
CONTRA: Non hai la possibilita' di scrivere filtri personalizzati (devi
usare procmail), non hai la possibilita' di seguire direttamente il corso
dell'E-Mail, non ho mai provato, ma penso che tu abbia problemi a creare
utenti virtuali (non in /etc/passwd) e non so bene come puoi fare per
avere gli utenti su DB. Esperienza personale di SMTP-Auth: fallita perche'
Postfix si rifiutava categoricamente di usare Cyrus-SASL (unica
possibilita' offerta per SMTP-Auth), in ogni caso estremamente macchinosa
la configurazione di SMTP-Auth essendo questa sparsa in piu' programmi,
log relativamente difficili da interpretare e con poche informazioni, per
quanto ne so non gestisce le Maildir, estensioni del programma via PlugIns
(NO! Non ho sbagliato! Per me e' sia un pro che un contro)
Exim:
DOCUMENTAZIONE: presso 
http://www.exim.org/
PRO: **ESTREMAMENTE** versatile nella configurazione che assomiglia piu'
ad un linguaggio ad alto livello che ad una configurazione, SMTP-Auth
completamente integrato (Plain, Login, Cram-MD5, NTLM, Pop-Before-SMTP via
Whoson), puoi definire Router per fare tutto cio' che vuoi con l'E-Mail a
seconda di condizioni definite da te con un mini-linguaggio, gestibile
senza problemi via DB (MySQL, Postgres, etc.), ideale per grandi traffici,
log molto semplici e intuitivi, integrati nel pacchetto anche ottimi
programmi di statistiche sul traffico, possibilita' di sapere attraverso
che router viene instradata un'E-Mail e di verificare al volo la validita'
di un indirizzo, ha un sistemi di filtri tipo procmail gia' integrato (e i
filtri possono essere letti da DB), gestione delle caselle come MBOX o
Maildir, consente di usare Script PERL per gestire situazioni complesse,
puo' comunicare via Unix-Socket con altri programmi in caso le
informazioni sia gestite da terzi, gestione integrata del controllo SPF
(
http://www.openspf.org/
), estrema facilita' di implementazione delle
Greylist
CONTRA: relativamente complesso da installare, occorre impararsi la
sintassi relativamente complessa del file di configurazione e dei filtri,
estensioni del programma da studiarsi a tavolino (puo' comunque richiamare
Script PERL)
MIO CONSIGLIO PERSONALE: installati Exim! Fatichi un po' di piu'
all'inizio, ma poi vai felice!
CONSIGLIO AGGIUNTIVO: se ti serve anche un Server POP/IMAP, installati
Dovecot. Se ti prepari bene il DB, puoi usare la stessa tabella per
l'autenticazione e la gestione delle caselle sia sotto Exim che sotto
Dovecot. Io ho fatto cosi' e ora ho finito di tirar madonne...
Spero di essere stato abbastanza dettagliato!
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 quanto ne so non gestisce le Maildir, estensioni del programma via PlugIns
Negativo pure questo.
In conclusione.
Apprezzo l'impegno ma il tuo contributo è di parte.
Si capisce che sai usare bene exim (io no) ma di postfix hai una esperienza
radente il suolo.
altra cosa da correggere: IMHO qmail (CulMail) fa cagare.
Max

 altra cosa da correggere: IMHO qmail (CulMail) fa cagare.
Beh, io non l'ho mai provato. Ripeto cio' che dissi prima: "me ne hanno
detto bene"


 Negativo pure questo.
Io uso maildir. Mi pare (non vorrei dire una stronzata) che lo faccia 
anche da solo senza plugin se non si hanno esigenze particolari.

 utilizzando user e pass di posta elettronica) ma vorrei farlo più selettivo.
sql_select: select pass from mailbox where username='%u@%r' and saslok=1
analogamente a saslok ho anche imapok, popok, webmailok etccc
MAx

 CONTRA: Non hai la possibilita'[cut]
Forse sarebbe il caso di evitare di parlare di ciò che non si conosce.
Non ne hai azzeccato uno che sia uno.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

> sql_select: select pass from mailbox where username='%u@%r' and saslok=1
ma con authdaemon?
il mio smtpd.conf è cosi:
pwcheck_method:authdaemond
log_level: 10
mech_list: LOGIN PLAIN
# chroot di postfix
authdaemond_path:/authdaemon/socket
L'autenticazione la fa tramite authdaemon non direttamente sasl.... non 
credo (non sono sicuro) che si possa usare la sql_select.
 > analogamente a saslok ho anche imapok, popok, webmailok etccc
si quelli li ho anche io. (anche se uso una versione personalizzata di 
webmailok dato che non uso quella di courier)

 Non ne hai azzeccato uno che sia uno.
Tutto quanto ho scritto e' riportato dalla mia esperienza personale...
Poi io non obbligo nessuno! Volete Postfix? E tenetevi Postfix!
Io, dopo aver smadonnato a raffica, son stato piu' che felice di passare
ad Exim...


 detto bene"
Te ne hanno detto bene perchè un 4/5 anni fa era veramente buono.
Poi peccato che è rimasto al palo.
Ed è un accrocchio che a me, solo per installarlo, fa venire il latte alle
cipolle.
(non parliamo della licenza molto fantasiosa con cui è distribuito)
Max

 ma con authdaemon?
No
io ho (copio dal server di test qui accanto su cui sminchietto
giornalmente. non è pubblico)
pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain login
allowanonymouslogin: no
allowplaintext: yes
password_format: crypt
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_database: <nome>
sql_user: <user>
sql_passwd: <pass>


 Poi io non obbligo nessuno! Volete Postfix? E tenetevi Postfix!
Neanche io obbligo nessuno, ma se il sottoscritto deve, ad esempio,
muovere delle critiche a qmail ritiene di poterlo fare con una certa
qual cognizione di causa, essendo stato "costretto" ad amministrare
una serie di mta qmail per qualche annetto.
Tu hai detto una lunga sequela di inesattezze a proposito di postfix,
tutto qui.


 sql_select: select pass from mailbox where username='%u@%r' and saslok=1
Ora faccio cut & paste sul server.
Tanto sasl lo uso solo io se non va piu poco importa.
Proviamo.....

 sql_select: select pass from mailbox where username='%u@%r' and saslok=1
Rinuncio.
Dicono che bisogna patchare sasl per l'uso dell'md5 di postfixadmin (con 
il salt in testa alla stringa)

 il salt in testa alla stringa)
Infatti io non uso postfix admin.
Ad ogni modo puoi fottertene.
Se vuoi essere l'unico a usare sasl, aggiungi una colonna "saslpass",
mettici qualcosa di tuo in chiaro o non crittata con mysql e sei apposto.
Non credo che sia un problema, no ?
Max

 Max
No, non è un problema (però non ci avevo pensato)
Volevo fare la suddivisione sasl_ok sasl_non_ok perchè in futuro potrei 
dare l'accesso sasl solo a determinati utenti e non a tutti come adesso.
Come faresti, aggiungendo il campo saslpass, a farla modificabile via 
php? usare l'encrypt di mysql non mi pare una buona idea...Troppo 
'leggero' come metodo di criptazione.

 'leggero' come metodo di criptazione.
se usi postfixadmin puoi moddare il codice e usare delle funzioni del php
per metterci l'hash che preferisci.
Anche metterla in chiaro non è una cattiva idea però.
Dopotutto se riescono a leggerti il DB e la password, sono già sulla
macchina e possono fare quello che vogliono...
Max

 il salt in testa alla stringa)
Una alternativa è usare SASL per autenticare su PAM, e usare pam_mysql
per il lookup su DB.
Non è altrettanto prestante, ma funziona dignitosamente...

 Max

 Non è altrettanto prestante, ma funziona dignitosamente...
Le prestazioni non sono fondamentali. In pochissimi usano sasl.

 Mmmmm dovrei installare mezzo mondo....
Ovvero?
Oltre a SASL (che devi installare ugualmente, indipendentemente dal
meccanismo di auth che scegli di usare) per il resto hai solo pam_mysql.
E ovviamente le librerie client per mysql, ma quelle le hai già, dato
che postfix si appoggia al DB...

 che postfix si appoggia al DB...
Sasl è già installato.
devo installare pam con supporto mysql.

 grazie a tutti
http://www.qmailrocks.org/
.. io lo trovo ottimo ... apparte qmailscanner che secondo me lo rallenta 
troppo.
( ma lo puoi eliminare configurandoti a dovere maildrop e vpopmail )
                                -- Yena -- 


Architecture: i386
Source: pam-mysql
Version: 0.5.0-6
Depends: libc6 (>= 2.3.2.ds1-4), libmysqlclient10, libpam0g (>= 0.76),
zlib1g (>= 1:1.2.1)
Filename: pool/main/p/pam-mysql/libpam-mysql_0.5.0-6_i386.deb
Size: 12356
MD5sum: 03f8531d61d7166112513ad017bbb1ac
Description: PAM module allowing authentication from a MySQL server
 This module lets you use a MySQL database as a source of
 authentication (but not session or other) information for PAM-enabled
 apps.

 backend (e ovviamente configurare pam come adeguato).
Ni.
Perchè io pam non ce lo.

 backend (e ovviamente configurare pam come adeguato).
M'è venuto un flash.
Usi Slack?!?
Auguri...

 Usi Slack?!?
Bravissimo!!!!!!!!!!!!
:))
Grazie per gli auguri. Capisci perchč (NON VOGLIO|NON POSSO|NON MI VA <- 
soprattutto questo) di installare pam?

 troppo.
quoto , a parte la licenza io mi trovo benissimo con qmail , date per
scontato che non mi sono mai addentrato nella cfg di exim o postfix , ma
per quel che serve seguendo la guida in mezz'ora hai un server di posta
configurato e abbastanza sicuro e non è poco.
ciao.
-- 
Motto di Nixon:
        Se due torti non fanno una ragione, prova con tre.

 password complesse utenti di mysql... etc etc etc
il conto è lo stesso.
Tu devi prevenire ste cose.
Se uno entra può fare tutto, qualunque cosa tu abbia predisposto per
bloccarlo, se ha la root è completamente inutile.
Se riesce a fare query arbitrarie e leggerti il DB, può comunque anche
cambiarti le password.
Comunque siamo in un ambiente "delicato", la sicurezza è una filosofia.
Le mie paranoie (grsec, chroot, vserver per isolare le cose pericolose,
certificati e chiavi) le faccio di default.
Ogni misura di prevenzione (perchè la sicurezza è fondamentalmente
prevenzione) deve essere commisurata al danno che eventualmente uno ti può
fare. Mettere una SINGOLA password per sasl in chiaro non pregiudica nulla,
se non il fatto che uno se la conosce può usreti come open relay (e non è
poco) ma te ne accorgeresti nel giro di 1h.
Se uno la ottiene ha avuto la possibilità di fare danni ben maggiori.
Max

 poco) ma te ne accorgeresti nel giro di 1h.
Come una singola password? io devo far inviare posta X clienti quindi le 
password diventano X. e diventano anche X le possibilità che uno riesca 
a leggere la password in chiaro.
Immaginati un codice php fatto male.
Se per qualche motivo dovesse fare un echo $password_sasl; tu 
stamperesti (magari senza accorgertene) la password e dal momento che è 
in chiaro......
mentre invece un echo $password; con md5 darebbe:
$1$ed3fainf32r$vfqw34tr2g3tg43
che il 99.9% delle persone scambierebbe per un errore e l'altro 0.1% 
dovrebbe perdere giorni se non mesi con john the ripper.
Diciamo che io sono per complicare al massimo la vita ai birbanti che 
vogliono farmi visita.

 cambiarti le password.
Quindi, seguendo la stessa filosofia, è assolutamente inutile che
/etc/shadow contenga le passord hashate o crittate.
Tanto è leggibile solo da root...:-)


 Tanto è leggibile solo da root...:-)
E quello che dico anche io accipicchia.

 
Però è ben diverso dire:
per un malintenzionato che HA OTTENUTO accesso come root le password 
crittate dello shadow non hanno alcuna importanza.
Allora qui sono concorde.
Tanto poi se le cambia tutte (a che pro?!) o cmq fa ugualmente quello 
che vuole sul sistema.

 crittate dello shadow non hanno alcuna importanza.
Non sono d'accordo neanche su questo.
Ammettendo che shadow contenga password in chiaro, se 'get root' su
una certa macchina con exploit remoto e posso bellamente leggere
le password degli utenti, avrò buone possibilità di loggarmi con
credenziali legittime su altre macchine adiacenti a quella exploitata,
perchè è ben noto che statisticamente, non dico root (e neanche questo è
sempre vero...), ma gli utenti tendono a riutlizzare le password su
più sistemi.
E un exploit locale è sempre più probabile di uno remoto, quindi
lasciare le pass in chiaro apre le porte ad una possbile excalation
su una serie di altri sistemi che, magari, non sono vulnerabili da remoto.


 
Cmq, non mi riferivo ad un attacco su piu sistemi (è vero, gli utenti 
tendono ad usare la stessa password su piu posti, quindi vedere una 
password potrebbe aiutare ad accedere ad altri server) ma sulla singola 
macchina. Una volta root ti importa poco delle password degli utenti.

 Non sono d'accordo neanche su questo.
Spè. Agguanta.
Prima cosa stiamo divagando quindi una premessa e poi la
ricontestualizzazione:
la premessa è che io di default sono paranoico e non penso che le shadow
non servono ad una cippa. Se mi complico la vita mettendo mysql in un
vserver, apache in un altro e chrooto il mondo ci sarà un motivo.
Contestualizzando, stiamo parlando di aggiungere un campo in una tabella di
mysql, per UN (dico UNO) utente che deve fare smtp relay.
In questa ottica, secondo me, la password in chiaro nel DB conta poco o
nulla. Se serve solo per sasl, ovviamente.
Tornando alla tua divagazione, non servono exploit remoti o locali per
sgamare una pass di mail.
Visto che (per esempio) un utente tipo 
alb...@dominio.it
 usa come pass
alberto75 come riferimento al suo anno di nascita.
Ricapitolando, non facciamo confusione: la sicurezza del sistema è una
cosa; la sicurezza di un account di posta è un'altra.
La prima dipende al 90% dal sysadmin. La seconda dall'utente.
E' in questa ottica che devi leggere il mio suggerimento di lasciarla in
chiaro (insieme al suggerimento di modificare i codici di ppostfixadmin che
invece permetterebbero di crittarla).
Max

 invece permetterebbero di crittarla).
Modificare i codici potrebbe essere una soluzione. Stavo appunto 
cercando un algoritmo per criptare la password in modo che sia:
1- difficilmente decrittabile (stile MD5)
2- utilizzabile da sasl senza troppe storie (pam+pam_mysql)
3- generabile via php
Il massimo sarebbe usare lo stesso md5 generato da postfixadmin in modo 
da avere una singola funzione di generazione password anzichè 2 
procedure distinte.
Ho letto che è necessaria una patch. Ho anche letto che questa patch è 
su un sito che non va piu.

 O al max alberto00
Ottimista... normalmente è alberto e basta
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
L'America e' un Paese che e' passato dalla barbarie alla decadenza senza
passare per la civilizzazione.
		-- John O'Hara

 Proviamo.....
E' facile fare il frocio kokkulodeglyaltrj (cit).
Sella serie... se lo devi usare solo tu č una cosa, altrimenti č ovvio che
il discorso cambia!
Non rigiriamo le carte in tavola eh!
Max

 Spè. Agguanta.
Ehi, nel mio post di risposta a te ho messo una faccina...:-)
Poi ho divagato, ma il senso dei due interventi era ovviamente
differente.


 Ehi, nel mio post di risposta a te ho messo una faccina...:-)
Prrrrrrrrrrrrrrrr :-)

 Non rigiriamo le carte in tavola eh!
Volevo vedere se eri attento..
Scherzo. A dire il vero volevo dire: "lo uso solo io ed un cliente di 
cui non mi importa pressoche nulla quindi se sasl durante la prova che 
sto per fare non va più non me ne frega un tubo".
Dai su un po di immaginazione....... :)