Storie dalla Sala Macchine

Talebano Bernstein? Lui ha insegnato a Maometto.... E quello che qmail è fermo alla 1.3.qualchecosa perché _non ha bug_, poi ci sono centinaia di patch per fargli parlare con il resto del monto smtp

-- Palin

Ho avuto un caso del genere di recente, fortunatamente il CL di turno ha capito e accettato i consigli ricevuti. Riscrivendo l'email "offensiva" via webmail ha aggirato il problema.

Altro caso simpatico e' quando il buon qmail trova un smtp server che accetta TLS ma ha il concetto di "certificato" meno stabile di una foglia nel pieno della tempesta.

Avere dalla propria un smtp server talebano ha i propri vantaggi, ad esempio riesce a far capire a molti personaggi che 2xclick su "setup" non e' sufficiente a garantire loro un server di posta

Omaggi.

Sandman.

-- Sandman

Non si poteva semplicemente mettere in white list?

-- Dotnette

>l'Oggetto Inamovibile contro La Forza Irresistibile!

Tu quoque, eh... Non ti ci vedevo come appassionato di Wrestling!

-- Thomas

Ho incominciato ad usare qmail nel 1998, dopo che "qualcuno" mi aveva sderenato sendmail con l'ultima falla 0-day ed ero finito nella RBL (LA rbl, l'UNICA black list via DNS esistente allora..).

Dovendo trovare una pur minima soluzione, mi ero imbattuto in questo strano software. Scritto in C. Senza usare le funzioni di libc. Progettato a compartimenti stagni, mentre sendmail era (è) un monolite con dentro mail server, mail client, interfaccia utente, ravanatore di file di testo, smandruppatore di MIME parts eccetera eccetera eccetera.

Il server che ho fatto allora sta ancora funzionando, nel data center di quello che era una volta ISP e ha cambiato nel frattempo vari padroni e varie ragioni sociali.

Il PHPtroto che ne ha ereditato la gestione credo non sappia neppure che su quella macchina giri il mail server della sua e-mail aziendale...

-- SIGLAZY

 

Qui perdiamo i colpi D.!

Ci pieghiamo alla dura realtà dei compromessi cliente/fornitore. Eheh

Quando capitano queste situazioni mi chiedo sempre se vale la pena di acquisire il cliente X quando il rapporto guadagno/tempo perso, si sa già dalle prime avvisaglie, sarà sempre sbilanciato sul denominatore.

Sono considerazioni sempre più commerciali e non tecniche, ma, scusate la domanda retorica, qual'é quel commerciale che ti ascolta veramente quali sono i pro e i contro di una situazione tecnica ed implicitamente di gestione corretta del cliente?

Ci si piega, quindi, verso un qualcosa di meno standard, consapevole di perdere una gestione corretta per acquisire un cliente X che non mi darà mai soddisfazioni. Consapevole che, comunque sia, il problema di comunicazione non è dato dalla gestione dell'e-mail in sé, ma dal fatto che si ha a che fare con persone che non vogliono impegnarsi, pensare o semplicemente lavorare.

Mi verrebbe però da dire: "Una tua mancanza non può essere una mia gastrite!"

Buon inizio settimana

Chris

-- Anonymous coward

Io invece devo dire che ho appena vinto una battaglia simile con un firewall (a layer applicativo, pare) che cercava di connettersi al server smtp del mio cliente con un

HELO macchina_xxx.dominio.it

E il mio mail server gli rispondeva "malformed HELO", perche` nell'hostname non ci puo` essere un underscore. Scritta una mail che spiega il problema, e riportato il pezzo di RFC in questione, incredibilmente non ho ricevuto risposte del tipo "arrangiati e mettila a posto tu dalla tua parte".

-- Il massimo danno con il minimo sforzo

Libero di utilizzare l'atteggiamento che credi più opportuno, ma IMHO un approccio diverso alla questione avrebbe salvato capra e cavoli: la ragione non basta averla, bisogna anche dimostrarla e farla capire (anche a chi non è un tecnico)... purtroppo questi ultimi due aspetti sono quelli che spesso mancano agli "estremisti" Linux

-- Anonymous coward

>Libero di utilizzare l'atteggiamento che credi più opportuno, ma IMHO un approccio diverso alla questione avrebbe salvato capra e cavoli: la ragione non basta averla, bisogna anche dimostrarla e farla capire (anche a chi non è un tecnico)... purtroppo questi ultimi due aspetti sono quelli che spesso mancano agli "estremisti" Linux

Qua' c'e' poco da dimostrare e far capire. D. ha perfettamente e completamente ragione, gli standard esistono e vanno rispettati e la roba che non rispetta gli standard dovrebbe essere rasa al suolo. Tuttavia non c'e' modo di spiegare a un cliente una cosa di questo tipo.

-- Riccardo Cagnasso

 

>>Libero di utilizzare l'atteggiamento che credi più opportuno, ma IMHO un approccio diverso alla questione avrebbe salvato capra e cavoli: la ragione non basta averla, bisogna anche dimostrarla e farla capire (anche a chi non è un tecnico)... purtroppo questi ultimi due aspetti sono quelli che spesso mancano agli "estremisti" Linux

>Qua' c'e' poco da dimostrare e far capire. D. ha perfettamente e completamente ragione,

Come ho già scritto, la ragione non basta averla... è una questione di "relazione" e di approccio con chi sta dall'altra parte. Spesso (mi spiace dirlo) chi utilizza Linux ha un atteggiamento troppo estremista, e spesso (guardacaso) non è lui a comandare o a decidere...

D. avrebbe potuto usare un approccio più morbido: anziché dire a chi sta cercando di portare a casa un cliente (che pagherà anche il suo stipendio) che il mailserver del cliente è rotto, e che entrambi non capiscono nulla di come dovrebbe funzionare un mailserver, poteva seguire uno dei consigli che sono stati dati qui, e mostrarsi "propositivo" nel risolvere la situazione. Dire "la colpa è dall'altra parte quindi sono fatti suoi" non porta a nulla di buono, e il finale di questa storia è qui a dimostrarlo... Dopotutto se è vero che CL riceve la posta da tutti tranne che da CL2 (e ciò dimostrerebbe che è CL2 ad essere rotto), è anche vero che CL2 spedisce la posta a molte altre persone che la ricevono...

-- Anonymous coward

Sei tu che non capisci il mercato.

Se tutto fosse standard , funzionante e compatibile , i consulenti (e la networkgestapo che ripara i casini e cura il funzionamento sincronizzato di tutto l'ambaradan) chi li paga? E se i consulenti si estinguono , a chi venderebbero i certificati microsoft e simili?

E senza idioti che credono di sapere ma non sanno una cippa il mercato crollerebbe...e torneremmo nelle caverne (ma con i computer funzionanti , pero'....)

-- Messer Franz

Beh dire che avevi visto giusto immaginando che ci fosse di mezzo un sExchange, e' ovvio..;-)

Ma c'e' anche da dire che mi chiedo come mai QMail per un errore come questo emetta un errore di categoria 4**, ossia un errore temporaneo/transiente (per i quali e' previsto ritentare la distribuzione dopo un certo tempo), e non un 5** che sono gli errori fatali (se il messaggio e' malformato, e' malformato, inutile fargli ritentare l'invio!).

E forse e' questo il motivo per cui CL2 non ha ricevuto risposta, i suoi messaggi sono in "pancia" a sExchange (uh, ma prima o poi dovrebbe dare una qualche risposta al SUO mittente, quanto meno per dire quale errore ha riscontrato, mah forse hanno impostato sEchange per riprovare per un anno...).

-- --
AP

E il tutto per un cliente....

-- Chronicles of a Broken Heart

Ricordati George Bernard Shaw: La regola aurea è che non ci sono regole auree. Purtroppo a volte bisogna piegarsi alla realtà che nessuno standard o regola o procedura sarà mai omnicomprensivo. Senza scomodare Godel e il suo teorema dell'incompletezza.. Non ha nessuna importanza quanti CL hai impalato in sala server, ce ne sarà sempre un altro pronto a entrare con simpatica noncuranza e chiederti "ho spedito delle foto via mail ma mi torna indietro" e farti scoprire (successo oggi) che tentava di mandare 128 mega di foto RAW. Alle ovvie spiegazioni, proteste in risposta. 

E io ho sempre meno assi, e sempre meno chiodi. 

Col pattex non è la stessa cosa. Non rende, non so se mi spiego.

-- Automatic Jack

> Il server di posta di CL fu' installato un po' di tempo fa' dal mio ex-collega (si', quello che tirava le tastiere dalla finestra), il quale era pure lui un talebano, ma fino ad ora ha funzionato regolarmente e, dato che pare che sia solo la mail di CL2 che non viene ricevuta, io comincio a sentire puzza di un grosso, peloso e fetente Exchange in giro.

Ma era un talebano il tuo collega o il server di posta installato?

-- Massimiliano

Solo un piccolo appunto...
Taliban e' il duale (forma grammaticale usata in alcune lingue per indicare due e solo due entita') di Talib che significa semplicemente "studente".
Il termine deriva dal verbo "Talaba" (chiedere, domandare, per estensione studiare) che e', teoricamente, l'azione dello studente, che "chiede" all'insegnante (mu'allim, derivato da 'allama, insegnare).

Taliban significa quindi "due studenti", oppure, per le stranezze della lingua araba, "piu' di cento studenti".

Giusto per mettere i puntini sulle I, le O, le U e, tanto per, anche la A.

Assalamu 'alaykum! -- Luca Bertoncello

Solo un piccolo appunto... Taliban e' il duale [taglio] oppure, per le stranezze della lingua araba, [taglio]

 

Giusto per togliere i puntini dalla `A', dalle `O' e dalle `U', "talebano" non è derivato dall'arabo ma dal persiano

-- Mallin Shetland

Giusto per togliere i puntini dalla `A', dalle `O' e dalle `U', "talebano" non è derivato dall'arabo ma dal persiano

Il farsi e' derivato dall'arabo. E comunque, resta il fatto che Taliban e' arabo. Se non ti fidi, chiedi al mio Prof di Arabo, oppure a una qualsiasi altra persona che parli questa splendida lingua.
E ora fine con le puntualizzazioni altrimenti Davide mi puntualizza un nuovo BackOrifice...

-- Luca Bertoncello

> l farsi e' derivato dall'arabo.

Puttanata galattica. Il farsi è una lingua indoeuriopea di ceppo iranico come il pashtu.

È PIÙ AFFINE ALL'ITALIANO CHE ALL'ARABO.

 

 

> E comunque, resta il fatto che Taliban e' arabo.

È dato di fatto come il sole gira attorno alla terra.

"Taliban" può essere farsi come può esserte pashtu. Dal punto di vista del farsi è un prestito arabo, dal punto di vista del pashtu è un prestito farsi ma comunque "talebani" è penetrato in italiano dall'Afghanistan e comunque "taliban" è una parola corretta in farsi e pashto mentree, come hai detto tu stesso, in arabo è il duale mente la forma corretta è "tullāb"

 

 

> Se non ti fidi, chiedi al mio Prof di Arabo,

Si proprio

 

 

> oppure a una qualsiasi altra persona che parli questa splendida lingua.

Meglio chiedere ad una persona che parli il farsi, il pashtu e l'urdu e che, soprattutto, se ne intenda di filologia e non confonda le lingue semitiche con le lingue indoeuropee.

 

 

> E ora fine con le puntualizzazioni altrimenti Davide mi puntualizza un nuovo BackOrifice...

Soprattutto che sia un back orifice ariano: (visto il tema)

 

-- Anonymous coward

Mmmmh, pare ben strano che il problema sia Exhcnage, visto che in Windows il terminatore standard di linea è CRLF, non LF... mi sa che è più probabile che sia il client che CL2 usa a far casino.

A proposito di QMail: un programmatore talebano brucerebbe il programma ed il suo autore. Il concetto di "sicurezza" nel codice di QMail è piuttosto particolare, come l'idea "per evitare i buffer overflow basta moltiplicare per n la dimensione di qualsiasi buffer" (invece di controllare che 'azzo ci scrivi dentro). Senza contare l'idea "l'ho scritto una volta come la bibbia/corano/talmud/ecc. e non ho bisogno di aggiornarlo"...

-- Anonymous coward

>A proposito di QMail: un programmatore talebano brucerebbe il programma ed il suo autore. Il concetto di "sicurezza" nel codice di QMail è

>piuttosto particolare, come l'idea "per evitare i buffer overflow basta moltiplicare per n la dimensione di qualsiasi buffer" (invece di controllare

>che 'azzo ci scrivi dentro).

Non hai la più pallida idea della cavolata che hai appena scritto.

Nel codice di qmail non c'è quasi mai il concetto "scrivere in un buffer", dato che praticamente tutte le stringhe sono allocate dinamicamente. Anzi direi proprio il contrario: i buffer  per le stringhe vengono allocati prima di essere usati, riallocati quando c'è bisogno di più spazio, rituilizzati quando non servono più - e il tutto usando specifiche funzioni che controllano sempre quanto spazio hanno a disposizione prima di scrivere ogni singolo byte. Tanto è vero che l'unico vero bug si può exploitare solo su macchine con interi di 64bit (che quando è stato scritto il codice non esistevano ancora) e con memoria RAM oltre i 2048 GB (che non ho ancora visto)- e il fix consiste nell'aggiungere tre righe di codice per controllare l'overflow, nella funzione che alloca lo spazio...

>Senza contare l'idea "l'ho scritto una volta come la bibbia/corano/talmud/ecc. e non ho bisogno di aggiornarlo"...

L'idea è diversa: è "l'ho scritto una volta sola bene, perchè ne avevo bisogno io" e " se non è rotto, non lo aggiusto".

Sono ottime idee, che andrebbero applicate è più spesso. Invece, molti so-tutto-io che ci sono in giro rilasciano ciofeche che stanno in piedi con lo sputo, e quando poi succede qualche disastro raccolgono in giro qualche calcinaccio, risputano, e tutto ritorna in piedi.

Ne ho visto tanto, di codice che a volte non nasconde neppure i bug (tipo: "leggo un file in un buffer di 1024 byte, tanto di solito non è più lungo e se è più lungo il programma crasha e non fa altri danni"...), a volte ho pure dovuto postare le patch con nuove funzionalità rispettando lo stile (ovvero lasciandoci dentro apposta lo stesso bug-salvavita, per evitare che qualche pezzo di codice successivo andasse in crisi perchè io avevo corretto il bug).

Quella roba c'è un po' dappertutto (io ho trovato bug del genere in BIND, Apache, bacula, vpopmail, Sendmail, perfino nella libc ...) e sono contento che qualcuno invece prende spunto da DJB per evitare di combinare guai sul software di base che usiamo tutti i giorni.

P.S.: il problema "Stray LineFeed" viene dai bei tempi andati, quando in Sun avevano deciso di risparmiare i carriage return nelle e-mail e i sendmail dei sistemi Solaris erano soliti terminare i datastream SMTP con LF.LF, mettendo in crisi i sistemi RFC-compliant che si aspettavano CRLF.CRLF (e se lo aspettavano all'infinito, ovvero fino al timeout). Ma quelli erano tempi eroici: i postmaster sapevano che se un processo sendmail era fermo da più di otto ore, dall'altra parte della connessione c'era un server Solaris bacato, così spulciavano le mille-duemila e-mail di errore recapitate nell'ultima settimana alla casella postmaster@ e chiamavano l'amministratore dei server dall'altro lato della connessione per spiegare il problema e proporre la soluzione. Oggi non sarebbe più possibile, e senza la scelta talebana di DJB il mondo delle e-mail sarebbe diviso in due: quelli che usano Solaris, e quelli che usano qualcos'altro e non possono ricevere posta dai server Solaris...

 

-- SIGLAZY

>Mmmmh, pare ben strano che il problema sia Exhcnage, visto che in Windows il terminatore standard di linea è CRLF, non LF... mi sa che è più probabile che sia il client che CL2 usa a far casino.

>A proposito di QMail: un programmatore talebano brucerebbe il programma ed il suo autore. Il concetto di "sicurezza" nel codice di QMail è piuttosto particolare, come l'idea "per evitare i buffer overflow basta moltiplicare per n la dimensione di qualsiasi buffer" (invece di controllare che 'azzo ci scrivi dentro). Senza contare l'idea "l'ho scritto una volta come la bibbia/corano/talmud/ecc. e non ho bisogno di aggiornarlo"...

 

Uh-uuuh, megauberflame incoming

-- Riccardo Cagnasso

 

Il concetto di "sicurezza" nel codice di QMail è piuttosto particolare, [...]

 

E in particolare differisce da quello di sendmail. In casa sendmail, "se qualcuno mette / a 777 noi non ce ne accorgiamo" viene considerato un baco di security di sendmail, ma scommetto che se riporti lo stesso problema in casa qmail, ti viene risposto che il baco non è nella loro applicazione ma nella testa del sysadm.

Entrambe le posizioni hanno meriti, quello che è sbagliato è confrontare il numero di bachi di security tra i due quando usano chiaramente definizioni molto diverse...

 

-- .TM.

 

Mmmmh, pare ben strano che il problema sia Exhcnage, visto che in Windows il terminatore standard di linea è CRLF, non LF... mi sa che è più probabile che sia il client che CL2 usa a far casino

Credo anche io, è probabile che il client sia roba del mondo *nix (anche se ormai non dovrebbe esserci in giro roba del genere) o forse qualche applicazione scritta ad hoc.

Il loro server però non doveva accettare un messaggio così formattato, al limite doveva trasformare i LF in CRLF anche se ciò è espressamente proibito dall RFC.

-- Andrea Ballarati

Il buon Jon Postel scrisse, in tempi in cui DJB era ancora piccolo e inoffensivo:

(da RFC 793)

2.10.  Robustness Principle



TCP implementations will follow a general principle of robustness: 

be conservative in what you do, be liberal in what you accept from others.

-- maxxfi

 

Il buon Jon Postel scrisse, in tempi in cui DJB era ancora piccolo e inoffensivo:

(da RFC 793)

2.10.  Robustness Principle



TCP implementations will follow a general principle of robustness: 

be conservative in what you do, be liberal in what you accept from others.





Purtroppo però molti lo hanno tradotto così:





2.10.  Principio di trascuratezza



Scrivi il client col culo, tanto poi ci penserà chi scrive il server a rimediare

alle tue cazzate.



Ho conosciuto il caro buon Jon Postel, e nei pochi minuti nei quali ci ho

chiacchierato mi sono convinto che di sicuro non voleva dire quello.

Però oggi non possiamo spedirci un eseguibile via e-mail sic et simpliciter,

perchè i byte 10 e 13 verrebbero cambiati/cancellati/aggiunti casualmente a

seconda dei mail server che attraversano...

E intanto noi sysadmin continuiamo a ricevere immagini screenshot incollate

in document Word di un messaggio di errore composto da una riga di testo

preso dall'email..

-- SIGLAZY

>TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

MOLTO saggio

-- Riccardo Cagnasso

> MOLTO saggio

C'è chi pensa che questo sia stato il più grosso errore di Postel. Le RFC avrebbero dovuto essere molto più restrittive, in molti altri settori gli standard sono standard e non puoi fare quello che vuoi. Capisco allora cercare di salvare il "pregresso", ma la stessa idea è quella che danna Windows che deve far funzionare gli applicativi scritti male già sedici anni fa.

E sarebbe stato più facile imporre gli standard ai tempi delle prime RFC che anni dopo man mano che il software diventava più complesso e la "compatibilità all'indietro" essenziale.

 

-- Anonymous coward

/****

C'è chi pensa che questo sia stato il più grosso errore di Postel. Le RFC avrebbero dovuto essere molto più restrittive, in molti altri settori gli standard sono standard e non puoi fare quello che vuoi.

****/

Count me in.

Credo nella bonta' del principio su piccola scala (aka: sto scrivendo un server, quasi automaticamente mi comportero' come dice Postel), ma sono convinto che "assolvere" in qualche modo chi scrive porcherie non sia una grande idea.

Penso che la troppo frequente implementazione "creativa" degli standard o i cosiddetti "standard de facto" (non di rado, una stronzata pazzesca sorretta da un enorme reparto marketing) siano tra le cause che rendono il nostro settore  più simile alla magia nera di quanto non dovrebbe essere.

Aggiungiamo la frequente tendenza dei soggetti commerciali a imporre in qualche modo standard "chiusi" o ad appropriarsi di quelli "aperti" (EEE anyone?) per creare ad arte meccanismi di lock-in e/o forzare l'utenza all'aggiornamento alla nuova-e-piu'-fighetta-versione e... ecco perche' ci ritroviamo a ballare intorno a un calderone con i CL che sbraitano perche' vogliono la pioggia sulle colture.

--
"Don't worry about people stealing your ideas.
If your ideas are any good, you'll have to ram them
down people's throats."
-- Howard Aiken

E intanto noi sysadmin continuiamo a ricevere immagini screenshot incollate in document Word di un messaggio di errore composto da una riga di testo preso dall'email..

Vero, ma spesso l'immagine e' pure ridimensionata male in modo che il messaggio di errore risulti illeggibile!

-- ringo

Ciao,

seguo sempre il tuo forum. Ho trovato molto interessante la citazione di Bernstein e Qmail... io studio alla University of Illinois at Chicago, quella dove insegna lui, non lo conosco di persona, ma ne ho sentito parlare... e ho sentito parlare anche di Qmail in un corso di sicurezza un paio di anni fa

-- Simone