Newsgroup: it.comp.os.linux.sys
Titolo: [wu-ftpd] Problemi di sicurezza su RedHat 6.x e 7.x

Ciao a tutti, per chi non lo sapesse gia' ....
vi informo che e' stato scoperto un baco di sicurezza nel server wu-ftpd
utilizzato da alcune distro, per esempio RedHat.
Quindi.... meglio aggiornare!
# links 
http://www.wu-ftpd.org/
# ncftpget -v '
ftp://updates.redhat.com/?.?/en/os/i386/wu-ftpd-2.6.1-*.rpm
'
Saluti
-------
Dario Lesca (
d.l...@osra.it
)

Quindi.... meglio aggiornare!
Idea migliore: proftpd :)
Non per altro, ma il wu va aggiornato troppo spesso :(
-- 
           ~~ ICQ#: 8761263 ~~ 
http://www.delymyth.net/
 ~~
            E-Mail Addy: DElyMyth [at] delymyth [dot] net
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=
Chi lavora avvelena anche te, digli di smettere - DElyMyth@work

 Non per altro, ma il wu va aggiornato troppo spesso :(
Concordo ....
Ma xche le distro non lo utilizzano di default?
Saluti
Dario Lesca

Ma xche le distro non lo utilizzano di default?
Slackware lo fa :P


 Non per altro, ma il wu va aggiornato troppo spesso :(
Interessante concetto, ma rovesciabile.
Se non ha aggiornamenti, puo` essere che conservi
un sacco di bug, no?
Cioe` il fatto di aggiornare spesso potrebbe essere
visto come un segno di continua evoluzione e
miglioramento, mentre il fatto di essere aggiornato
raramente potrebbe essere visto come segno di
staticita` ed indice di obsolescenza.
Ma e` vero anche il contrario, cioe` frequenti
aggiornamenti possono denotare molti problemi,
radi aggiornamenti possono denotare un design
ed implementazione robusti...
Chi puo` dirlo?
bye,
-- 
  Piergiorgio Sartor

Chi puo` dirlo?
La storia di Sendmail puo' dirlo.

 per esempio RedHat.
Bhe inutile dire che oltre che tenere al sicuro la porta ftp, up2date è
praticamente eseguito ogni giorno! :)))
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://digilander.iol.it/kbytesystem
ICQ: 40872731 - C6: andreakbyte

 La storia di Sendmail puo' dirlo.
Una rondine non fa primavera.
E poi c'e` anche il sito (o quello che e`)
"dontblamesendmail"... :-)
bye,
-- 
  Piergiorgio Sartor

Chi puo` dirlo?
None
*** Marco Tizzoni   /// Business Gate SpA - 
www.businessgate.com
 /// *
* Microsoft Certified Professional x3 ID#: 2244986		     *
* SCOUT TAG: Marco Tizzoni CT 5° (AGESCI) Capo Reparto		     *
* Linux User Group Catania Member - 
http://lug.linuxsicilia.it
	     *
* ICQ UIN: 128671461 // **********************************************

 un sacco di bug, no?
Ni. Nel senso che potrebbe avere un sacco di bug, ma non si scoprono.
Del resto pero' non si sta parlando di bug qualsiasi, ma di problemi 
alla sicurezza del programma. Quindi il fatto che proftd debba essere 
aggiornato meno spesso per quella ragione, significa che ne ha di meno 
(o in alternativa nessuno li ha ancora scoperti)
Proftpd e' attivamente sviluppato, ma le distribuzioni distribuiscono 
solo gli advisory che riguardano la sicurezza.
bye
Gianluca
-- 
We are the opensource. Existence as you know it is over. We will add
your proprietary features and technological distinctiveness to own
opensource project. Resistence is futile. Windows is closed.

 bye,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> CLIP HERE < =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 nuove features!
Only features!
It's not a bug, it's a feature.
This feature will be fixed with the next relase.
:-)
Scherzi a parte, certo.
In sostanza la frequenza degli aggiornamenti
puo` essere causata da vari fattori.
Pero` se guardiamo proprio il capello, il
kernel di Linux e` aggiornato piu` spesso
di we-ftp e sendmail messi assieme...
bye,
-- 
  Piergiorgio Sartor

 ed e' per questo che bisognerebbe passare a qmail o Postfix.
Vabbe`, non sto mica dicendo il contrario.
Pero` il discorso e` sempre il solito, cioe`
sendmail e` anche diffusissimo, mi pare qualcosa
come il 90% dei server usa sendmail, quindi e`
estremamente probabile che venga bucato per primo...
bye,
-- 
  Piergiorgio Sartor

estremamente probabile che venga bucato per primo...
Ammetti pero' che ci mette anche del suo...
Eppure e' il SMTP di default per penso tutte le distribuzioni :(


 estremamente probabile che venga bucato per primo...
Il problema di sendmail non e' la diffusione ma una serie di concetti
sbagliati nel progetto sin dal principio, per esempio essere un unico
grosso eseguibile SUID root a differenza di qmail e Postfix che hanno
invece una serie di eseguibili che girano come utenti non privilegiati.
Pare che nelle ultime release l'abbiano capito ma non del tutto visto
che di exploit continuano a vedersene.


> un sacco di bug, no?
GM> Ni. Nel senso che potrebbe avere un sacco di bug, ma non si scoprono.
Esattamente quello che intendeva dire quel bricconcello di Red!
GM> Del resto pero' non si sta parlando di bug qualsiasi, ma di problemi
GM> alla sicurezza del programma. 
Che piu`  che bug sono scoperta  di tecniche di  programmazione che ne
rendono deboli altre. Alcune sono  stranote e un auditing sui sorgenti
(anche banale  come fare  un grep) puo`  individuarne molte,  ma altre
sono meno note o ancora da scoprire. 
Ci sono casi in cui si  tratta di rendere falso un "assioma" (peraltro
ragionevole)  sul quale  si basa  il ragionamento  di  correttezza del
programma. E in questo caso nel  99% dei casi ci vuole una persona che
non sia coinvolta nello sviluppo.
Ovvio che verra` trovata prima se e` su un programma molto usato.
GM> Quindi il fatto che proftd debba essere aggiornato meno spesso per
GM> quella  ragione, significa  che ne  ha di  meno (o  in alternativa
GM> nessuno li ha ancora scoperti)
Una risposta  definitiva forse la  si puo` dare dopo  essersi smazzato
tutto il codice riga per riga. Forse. 
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

 Eppure e' il SMTP di default per penso tutte le distribuzioni :(
Perche` e` diffuso e tanta gente sa come usarlo e
configurarlo (si fa per dire...).
E` sempre il solito discorso, che si potrebbe applicare
anche ad X (non per la sicurezza, ovviamente), cioe`
e` piu` "conveniente" fornire un tool noto, magari
zoppicante, ma noto, piuttosto che un tool "robusto",
ma sconosciuto...
bye,
-- 
  Piergiorgio Sartor

 che di exploit continuano a vedersene.
Certo, certo, ripeto ancora, non difendo sendmail,
solo che vi sono alcune cose che vanno dette.
Poi so anche io che il design non e` dei migliori,
e non lo e` stato fin dall'inizio...
bye,
-- 
  Piergiorgio Sartor

>>>>> "PS" == Piergiorgio Sartor <sar...@sony.de.REMOVE.THIS> writes:
PS> Il primo internet worm (20 anni fa?) usava una
PS> "feature" di sendmail.
PS> Praticamente collegandosi all'host, con telnet o simili,
PS> sulla porta 25, era possibile eseguire il debug di
PS> sendmail tramite comandi del daemon.
PS> Il che includeva il download e l'esecuzione di codice...
E questa era una debolezza  legata alla configurazione.  O meglio, era
una cosa  sicura sotto l'assunzione  che nessuno rompesse le  balle ed
anzi, fino  al worm, aveva  funzionato in quanto la  gente gentilmente
sistemava i  server altrui... Reso  falso l'assioma, il fatto  che per
default il debug  fosse attivo e` diventato un  security hole anche se
non e` un bug vero e proprio (il programma e` corretto).
Idem  per l'altro modo  che Internet  Worm usava,  ovvero fare  un bel
buffero overflow a  fingerd sui macchine con HW  vax. Il programmatore
aveva  agito  sulla  convinzione  piu` che  ragionevole  (salvo  prova
maliziosa   e  contraria)   che  c'era   una  lunghezza   massima  per
l'interrogazione  inviata  a   fingerd.  Convinzione  sensata  finche'
qualcuno  non penso`  1) di  rendere falso  l'assioma 2)  sfruttare la
cosa.
BTW,  Emacs si  aggiorna  con una  certa  frequenza, e  spesso e`  per
aggiunta di feature (anche se ci sono le bug fixes :) ).


 non e` un bug vero e proprio (il programma e` corretto).
Infatti, e` realmente una feature, pericolosa, ma
sempre una feature.
bye,
-- 
  Piergiorgio Sartor

"dontblamesendmail"... :-)
Chi ha dei buoni motivi per usare sendmail lo sa, e lo usa. Chi non e'
consapevole di questi motivi farebbe molto bene a non usarlo. 
-- 
"La coerenza e' la virtu' degli imbecilli."
(Ciccillo su it.fan.startrek quando filosofeggia)

 di root, e cosi' via.
Ma si, ma si, chi ha mai detto il contrario...
bye,
-- 
  Piergiorgio Sartor

ed e' per questo che bisognerebbe passare a qmail o Postfix.
Cheddire....proprio oggi leggevo di un bug grave su postfix :-)
Ritorno sempre a dire che e' il manico quello che conta e Sendmail e'
il miglior e piu' completo MTA che io abbia mai utilizzato.

 il miglior e piu' completo MTA che io abbia mai utilizzato.
Se ti riferisci al memory exhaustion non e' mica cosi' grave visto che
Venema ha postato anche il codice per fixarlo e poi sendmail e' da
decenni che e' buggato, direi che una bella differenza c'e'.


 Eppure e' il SMTP di default per penso tutte le distribuzioni :(
tutte tranne una, che non è ne Debian , ne Slack ne *BSD.
L'unica distro che usa postfix è  Mandrake ... me ne accorsi tanto tempo
fa quando la provai un po'.
-- 
~Massimiliano ADAMO
  ICQ# 103417788

 Slackware lo fa :P
ecco perché era l'unica distro immune! ... l'ho scoperto su
securityfocus


> Una rondine non fa primavera.
ZC> Pero' e' strano, per cosi' dire, che nessuno faccia piu' server
ZC> monolitici, cerchi di scrivere server che non necessitino di privilegi
ZC> di root, e cosi' via. 
Non e`  affatto strano.  Se  ci pensi un  attimo su quello  che scrive
Piergiorgio  "Red" Sartor  o  scrivo io,  ci  sono cose  che non  sono
"errori" ma si  sono dimostrate come tecniche che  con l'esperienza di
oggi si etichettano con "cio` e` male". 
Una volta c'erano paradigmi  diversi, forse meno evoluti, forse legati
al fatto  che su un  VAX 11/780 con  BSD o su un  3b2 le exec  di vari
moduli pesavano piu` dello swap di un molosso.
ZC> Per il resto e in termini piu' generali, la tua impostazione e'
ZC> sbagliata per due distinti ordini di motivi:
ZC> 1) Esiste la possibilita' di scrivere software ragionevolmente
ZC>    sicuro. Se X non e' sicuro, e Y non mostra problemi, questo potrebbe
ZC>    proprio dipendere dal fatto che Y NON HA problemi (di
ZC>    sicurezza), non dal fatto "non ce ne siamo ancora accorti".
Non ne puoi  _mai_ essere sicuro. Qui sei tu che  fa un errore grosso.
Secondo. Il tuo ragionevolmente sicuro di oggi puo` essere lo zimbello
dei cracker di domani.
"L'unico  calcolatore sicuro e`  quello spento,  chiuso in  una camera
blindata e guardati a vista da guardie armate. Ed ho ancora dei dubbi"
(E. Spafford, citato a memoria)
ZC> 2) Se X e' un prodotto molto diffuso, usare Y che e' meno diffuso e' un
ZC>    modo semplice ma efficace per togliersi di torno gli interessi di
ZC>    hacker, cracker e simili. Chi cerca vulnerabilita' le cerca nei sw
ZC>    diffusi. 
Puo` esserlo  come no.  L'unica cosa che  ti difende  dalle intrusioni
(nel senso che ne avrai poche) e` essere paranoico.


decenni che e' buggato, direi che una bella differenza c'e'.
Sendmail gode di cattiva fama perche' e' stato il primo MTA e perche'
e' molto diffuso ma negli ultimi 3 anni i bugs riscontrati sono al
livello di tutti gli altri applicativi server side. 
Dalla versione 8.12.x non e' piu' legato a root come processo,
l'ultimo exploit trovato funzionava solo sulla macchina locale.
Quanto alle funzionalita' non lo cambierei con nulla sopratutto forse
perche' lo conosco abbastanza bene :-)

 perche' lo conosco abbastanza bene :-)
Sicuramente cio' incide parecchio, non c'e' dubbio :-)


dei cracker di domani.
Appunto parlo di problemi strutturali e non di problemi incidentali. X
potra' avere un baco di sicurezza, ma se X e' scritto in un certo modo,
a) il baco e' sanabile facilmente e b) sanando il baco, e' molto
probabile che non vengano introdotti altri bachi di sicurezza, per cui
ci sia una evoluzione virtuosa del programma. 


 altri che non ne soffrono.
Ma la discussione partiva dal numero "eccessivo"
di update, come misura di problemi.
Il mio punto era che non e` una buona misura, per
vari motivi.
E ripeto, se avere frequenti upgrade e` una misura
di scarsa architettura o di problemi strutturali,
allora il kernel di Linux e` un disastro, dato che
e` aggiornato e modificato con un frequenza paurosa.
Quindi il numero di upgrade puo` essere (non e` detto,
che lo sia) un indice positivo, poiche` dimostra che
il SW e` "vivo", e` seguito, aggiornato e forse meno
buggato di altri che sono meno veloci nei cambiamenti.
Che poi lo stesso SW soffra di exploit piu` frequenti
puo` anche essere causato dalla larga diffusione, per
cui uno che volesse far danni ad un sistema e-mail,
avrebbe da scegliere tra sendmail ed exchange, non
avrebbe senso attaccare postfix o qmail, dato che
forzerebbe 4 server in croce (senza offesa).
Il che suggerirebbe di usare uno tra questi due.
Potrebbe quindi succedere un'inversione di tendenza,
tra gli installati, ed allora, forse, le cose
potrebbero rovesciarsi ed andremo a lamentarci
che postfix o qmail sono disastrati solo perche`
(in questo ipotetico contesto) sono molto piu`
diffusi ed attaccati (di conseguenza).
Allora prima di dare un giudizio di qualita`, bisogna
un attimo riflettere sulla situazione, con un punto
di vista un po' piu` allargato, a mio modesto parere.
Il che non e` un invito ad usare sendmail o wu-ftp,
usate quello che vi pare e che considerate meglio.
bye,
-- 
  Piergiorgio Sartor

> dei cracker di domani.
ZC> Appunto parlo di problemi strutturali e non di problemi incidentali.
Anche io. Quella che tu (tu generico!!!) ritieni una struttura robusta
puo` essere  resa traballante  da una operazione  che, in  maniera non
prevista,  sovverte quelli  che erano  i presupposti  della robustezza
originaria.


originaria.
Se il kernel funziona correttamente questo non puo' avvenire, i
privilegi di root/le capabilities non vanno in giro in modo liberale, e
se la parte di demone con privilegi di root/le capabilities non le
concede, gli altri pezzi di server non possono averle, a meno di
compromettere il pezzo di server privilegiato. Ma un pezzo di server
sicuro e' estremamente piu' facile a scriversi di un intero server.

diffusi ed attaccati (di conseguenza).
Questo e' ipotetico, allo stato attuale. Prescindendo dal ricco premio
per chi viola qmail, che attende ancora di essere riscosso e che
dovrebbe essere uno stimolo sufficiente, rimane il fatto che dire "la
sicurezza assoluta non esiste" e' una banalita'. 
Perche' e' vero anzi verissimo, ma poi esiste un mondo reale in cui
occorre installare ed usare software, e pensare che il software sia una
scatola nera dal punto di vista della sicurezza (=la sicurezza assoluta
non esiste, quindi fanno tutti schifo in modo piu' o meno palese) e'
sbagliato da un punto di vista *operativo*. 
Se Sendmail ha un bug grave in media ogni N settimane, e Postfix e Qmail
0 bug gravi in due anni e piu', io sono autorizzato a concludere che
sono piu' sicuri. NON mi interessa se siano i server smtp di dio, se in
Paradiso usano questi due prodotti o meno, mi interessa che i fatti gli
danno ragione. Quando i fatti gli daranno torto, allora mi porro' il
problema.

 problema.
Beh, ma potrebbe essere troppo tardi...
bye,
-- 
  Piergiorgio Sartor

Beh, ma potrebbe essere troppo tardi...
Non vedo alternative. Vedo invece che chi ha fatto questo ragionamento
due anni fa quando usci' Postfix si e' fatto due anni di pace. 


> strutturali". Lo so, e` paranoia. Ed e` l'unica cosa che funziona.
ZC> No, non funziona perche' tu _devi_ installare un server per la posta.
E se stai abbastanza paranoico avrai poche intrusioni nel tuo sistema.
Tempo fa lessi un articolo dove si diceva "diffida molto di quelli che
dicono di  non aver mai  avuto intrusioni e  dai rispetta chi  dice di
averne avute poche".
Devi installare un server della posta (cosa vera solo se devi gestire
degli utenti di posta) ? Fallo e si paranoico.
ZC> Se il kernel funziona correttamente questo non puo' avvenire, i
Mai stare su  queste posizioni. C'e` da qualche  parte qualcuno che ha
scoperto qualcosa  di nuovo e  che tu non  conosci e che  potra` farti
fesso.
ZC> compromettere il pezzo di server privilegiato. Ma un pezzo di server
ZC> sicuro e' estremamente piu' facile a scriversi di un intero server.
Che sia  piu` facile scrivere  un programma corto corretto  (in questo
caso la correttezza include anche la sicurezza) che un programma lungo
e corretto va bene, sono d'accordo.
Ma se il fare pezzi e` la panacea non ne sono convinto. Tu devi fidare
di  un programma  esterno (puo`  anche essere  il kernel)  oppure fare
moduli che non  si fidano di loro. Perche' una  catena e` forte quanto
il suo anello piu` debole. 
Non sto dicento "a moduli non e` sicuro". Sto dicendo "occhio, pensaci
bene, e continua a essere paranoico".
Anni fa leggevo bugtraq (poi ha smesso di arrivarmi), e anche il buon
Venema vedeva il suo prodotto messo sotto accusa per debolezze.


 meraviglia, ha scoperto che e' sicuro.
Non dubito di questo, anzi, questo e` un _ottimo_
argomento a favore di postfix e, sinceramente, stavo
solo aspettando quando lo tirassi fuori.
Sendmail soffre del fatto che il suo design fu fatto
con requisiti diversi da quelli di postfix.
All'epoca non era un problema la sicurezza.
Potrei elencarti una decina di buchi di sicurezza
dovuti alla "leggerezza" con cui i _kernel_ di 10
anni fa trattavano gli esguibili suid, per esempio.
Adesso le cose stanno un po' meglio, dopo parecchie
revisioni e` cambiamenti radicali di questi kernel.
Postix e` progettato tenendo conto della sicurezza,
questo e` un _ottimo_ motivo per usare postfix, ma
non perche` ha pochi bug report, questa e` una
sciocchezza, una falsa sicurezza.
bye,
-- 
  Piergiorgio Sartor

 writes:
ZC> scatola nera dal punto di vista della sicurezza (=la sicurezza assoluta
ZC> non esiste, quindi fanno tutti schifo in modo piu' o meno palese) e'
ZC> sbagliato da un punto di vista *operativo*. 
E qui  siamo concordi. Esattamente quello che  penso io, probabilmente
usiamo parole diverse.
ZC> Se Sendmail ha un bug grave in media ogni N settimane, e Postfix e Qmail
ZC> 0 bug gravi in due anni e piu', io sono autorizzato a concludere che
ZC> sono piu' sicuri.
Sei autorizzato a supporre che Postfix  e Qmail siano piu` sicuri ed a
sceglierli, ma se  non hai una prova provante non  puoi arrivare ad un
punto conclusivo e quindi devi sempre essere paranoico.


messi meglio, pero'.
Non li conosco come prodotti ma mi fido xche' ne parlate tutti molto
bene. Il problema e' che qui dove lavoro faccio tutto io.....mi
piacerebbe avere il tempo di imparare ancora ma le giornate sono
composte di 24 ore :-))

 composte di 24 ore :-))
Chiedi a chi di competenza di allungarti le giornate :-P


fesso.
Io ho scritto "se". Ovviamente se il kernel e' bucabile buonanotte a
tutti e' stato un piacere :)


 writes:
taw> Chiedi a chi di competenza di allungarti le giornate :-P
Cheafrittolademao!  L'ufficio   competente  deve  essere   gestito  da
burocrati italiani... Ho mandato la domanda anni fa e non hanno ancora
fatto nulla!!!


 Cheafrittolademao!  [cut]
tipica espressione veneta... mi pare... di dove sei?
Saluti
Stefano
P.S. chiedo scusa per l'intrusione

fa quando la provai un po'.
Debian non ha come smtp default sendmail, bensi` exim.
-- 
Maurizio - Tannoiser - Lemmo
STIGE Srl Servizi Informatici
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 fatto nulla!!!
Beh arriva a P.zza San Pietro, li' c'e' il mausoleo di un suo agente di
fiducia, se con una seduta spiritica riesci a parlare con lui sei a
posto.


Chiedi a chi di competenza di allungarti le giornate :-P
Si ma non quella lavorativa.....per favore ;-))

 Debian non ha come smtp default sendmail, bensi` exim.
Non lo  sapevo ...  ho isntallato  Debian per poco  tempo e  non ricordo
quasi nulla.
Cmq  io lo  faccio per  far crollare  il  mito di  *BSD :)  ... che  poi
se  ci vogliamo  allargare un  po', anche  molti unix  commerciali usano
sendmail.
Solaris 8 lo usa come mta di default.
SCO, nello skunkware, ti fornisce sendmail.
e così via.


 Si ma non quella lavorativa.....per favore ;-))
Deh ma mi credi cosi' masochista?


Non c'e' storia sorry.
Parli per i bugs o per le features del prodotto?
ciao

sciocchezza, una falsa sicurezza.
E' una sicurezza statistica, per continuare ad usare questa
terminologia, ed e' sempre meglio di niente.


 due anni fa quando usci' Postfix si e' fatto due anni di pace. 
Secondo me, se e' intelligente, si e' fatto due anni di paranoia
ingiustificata.
Se se li e' fatti di pace, e' comunque un incosciente.:-)
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

Oltre ad essere decisamente MOLTO piu' sicuro
Conosco bene Sendmail e tanto mi basta :-)
Gia' scrivevo che vorrei avere delle giornate superiori alle H24 per
poter imparare...imparare....imparare. Mi piacerebbe davvero
utilizzare e conoscere prodotti diversi dal buon SMail. 

Se se li e' fatti di pace, e' comunque un incosciente.:-)
Per due anni di pace intendevo il non doversi precipitare a fare un
upgrade per questioni di sicurezza, non il fregarsene amabilmente di
quello che succede su bugtraq :)


utilizzare e conoscere prodotti diversi dal buon SMail. 
Per Postfix posso dire che ci vogliono dei minuti per capire come
si configura ;)


 sicurezza; prova ne sia che 2.2.20 e' sicuro (e forse anche 2.2.19) e
No, viene upgradato per tante questioni, il che cosa
mi significa? Che e` fatto male?
Non credo, significa e` molto revisionato, IMHO.
Lo stesso potrei dire per sendmail, e` molto revisionato.
Nota: _potrei_ dire, non lo dico, sto solo facendo
notare come punti diversi di osservazione possano
portare a risultati diversi e persino ragionevoli.
bye,
-- 
piergiorgio

> Parli per i bugs o per le features del prodotto?
D> Ma..
D> Considerato che configurare bene sendmail e' un vero incubo, tutte le
D> features non sono facili da usare,
E' vero che Sendmail ha un file di configurazione in aramaico antico e
nella  maggior   parte  dei  file  di   configurazione  stabili  trovi
l'indicazione "quieta non movere! It works, why fix it ?" ma una volta
ho  avuto bisogno  di  fare  una cosina  banale  (user deve  diventare
us...@that.domain.it
 salvo che per un paio di nomi in cui deve rimanere
user -  @
this.domain.it
 sottinteso) e, bat  book alla mano,  non ci ho
messo molto.
D> qmail invece ha tutta la sua bella
D> serie di microbici add-on, che lo rendono molto ma MOLTO flessibile :)
D> Oltre ad essere decisamente MOLTO piu' sicuro
Tu ti ci giocheresti la tua  carriera professionale (se la cosa non va
il collo sul  ceppo e` il tuo) per mettere Qmail  al posto di sendmail
dovendo:
        gestire almeno 2000 utenti 
        gestire un tot di alias (almeno uno ad utente o piu`)
        antivirus
        filtri antispam
O terresti sendmail mettendogli davanti un firewall con SSMTP ?


 O terresti sendmail mettendogli davanti un firewall con SSMTP ?
Con qmail non c'e' nemmeno bisogno di firewall, e' gia' sicuro di suo.


> O terresti sendmail mettendogli davanti un firewall con SSMTP ?
taw> Con qmail non c'e' nemmeno bisogno di firewall, e' gia' sicuro di suo.
Un firewall  serve sempre,  anche se a  volte il  fatto che ci  sia fa
agire in modo poco sensato gli utenti.


 agire in modo poco sensato gli utenti.
Guarda sul sito, leggi le caratteristiche di qmail e capirai perche'
sbagli visto che qmail non ha bisogno di firewall per non far fare da
relay per lo spam a tutto il mondo.



Io ne uso uno commerciale !
Alessandro

la sabbia nel deserto.
Hai indicato un'altro punto fondamentale per SendMail....la vedo come
te anche perche' non ho mai potuto sperimentare soluzioni diverse dal
suddetto.....chissa sperimentando e lavorando duramente si puo' poi
pensare di implementare cose diverse...
ciao

 pensare di implementare cose diverse...
Il punto e' che come obiezione non serve a niente visto che di esempi di
gente che usa qmail (anche esempi grossi) se ne possono leggere a
carrettate sul sito e non credo sia stato questo il problema che si sono
posti (quello del rischiare o meno il posto) visto che a mettere un
altro MTA piu' sicuro di sendmail tutto si puo' dire ma non che si
rischia il posto. Almeno usate obiezioni piu' convincenti tipo "lo
conosco meglio" ma non questa che fa un po' ridere.


conosco meglio" ma non questa che fa un po' ridere.
Sendmail e' standard su Solaris e molti utilizzano la versione
commerciale pero' mi sembra che in parte si sia frainteso il senso
dell'ultima parte del tread. 
Personalmente non credo che Sendmail sia meglio di altri o che altri
siano migliori di Sendmail credo solo che Sendmail sia uno standard
de-facto e molto spesso, chi ha la responsabilita' di decidere non si
trova nel modificare una strada che funziona per altra che rimane a
lui sconosciuta. 
Se ci pensi e' lo stesso approccio che si aveva anni fa con Linux in
genere e la stessa cosa accade con dei prodotti nuovi. Io, e forse mi
hai franteso in questo caso, ho solo detto che uso Sendmail xche' lo
trovo completo e funzionale ma ho anche sempre detto che non esprimo
giudizi su prodotti concorrenti visto che non li conosco. 
Posso parlare per quello che so ma mai potrei riferire di quello che
'aime' non conosco.
Ciao

 'aime' non conosco.
E questo e' sacrosanto: ti invito a provarlo (che sia qmail o Postfix)
ma provalo, vedrai che offrono le medesime funzionalita' (qmail mediante
numerosi add-on che si trovano sul sito) di sendmail con in piu' una
garanzia di sicurezza che sendmail da' e non da' (nel senso che per ora
la versione attuale puo' considerarsi sicura ma per quanto?). Come
scrisse Marco nel suo articolo del '97 usare sendmail a meno di esigenze
*molto* particolari non ha piu' tanto senso perche' e' un ottimo MTA,
per carita', ma ha una infelice storia che si porta dietro da quando e'
nato purtroppo e non c'e' motivo di continuare ad avere grattacapi
quando con altri MTA piu' moderni tanti problemi si possono evitare alla
radice.


> agire in modo poco sensato gli utenti.
taw> Guarda sul sito,
A volte sei piu` testardo di un nano e ci esci come un pirla.
Il firewall serve  sempre (ovvero non limitatamente a  SMTP).  E' vero
VOLENDO  si  puo`  sofistare  sul  significato  di  quella  frase,  ma
facendolo si fa il trollslayer  fanatico che vede troll anche dove non
ce ne sono.


 ce ne sono.
Peccato che i troll qui non c'entrino niente e la stai facendo fuori dal
vasino. Su una macchina che offre solo servizi POP3 e SMTP, che si trova
in una rete non visibile su Internet e riceve la posta da una macchina
posta in DMZ (per fare un esempio) a che cazzo gli serve un firewall.
Poi se tu sulla stessa macchina metti anche altri servizi e' un problema
tuo non certo di qmail.


No ? Scusa, ma sei uscito dall'Universita` ? 
<flame>
Perche', se fosse? 
</flame>