139 battute, spazi inclusi, per descrivere in modo dettagliato Postfix: nemmeno con la compressione LZMA riuscirei a far di meglio
Scherzi a parte, a mio parere, bisogna cercare la "via di mezzo", perché l'interazione tra molti programmi prevedono molte e distinte varianti, pertanto in un'unica guida ci si troverebbere a fare tutte le varie ipotesi; sempre nell'esempio di Postfix, bisognerebbe fare i capitoli per:
- usare Amavisd-new
- usare Mailcscanner
- usare procmail
- interfacciare direttamente clamav
- interfacciare direttamente spamassassin
- ecc..
(come ho dovuto fare [--brr, terribile--] per Amavisd-new nella guida di Pyzor e Razor, ma per fortuna questi due pacchetti non prevedono la moltitudine di variante come nel caso di Postfix)
la lista risulterebbe più lunga che scrivere delle guide complete, inoltre si averebbe la "scomodità" di lettura per l'utente il quale dovrebbe capire quali capitoli saltare e quali seguire, donando una bella dose di confusione per quelli meno esperti. Secondo me andrebbe fatta, sempre nell'esempio di Posfix, una guida approfondita che non include alcuna interazione con altri software, poi in fondo si citerebbero tutte le guide che riportano un uso specifico di Postfix con altri pacchetti, in queste ultime si scriverebbero solo le configurazioni minime necessarie allo scopo prefissato es: postfix->Procmail, Postfix->Amavisd-new, Postfix->Mailscanner ,ecc..
Infatti delle mia guide, stavo già pensando di separare, oltre a Fetchmail, pizor, Razor, le webmail, la parte di Dovecot. Inoltre , sono in stand-by con la scrittura della variante MailScanner (
http://guide.debianizzati.org/index.php/Server_mail:_Postfix_MailScanner_Dovecot_e_MySql) perché con mm-barabba sto vedendo la possibilità di splittare ed ottimizzare parti della sua documentazione in modo che io non debba riscrivere, e creando doppioni dei contenuti, cose già scritte da lui.
Sono dell'idea di tirar fuori dal wiki tutte quelle parti, alcune nascoste, dove si parla della medesima cosa (o una variante) per splittarle, fonderle, riordinarle e pulirle dagli errori. Però, prima di procedere dobbiamo pensare bene come impostare un'architettura che ci permetta riutilizzare parte dei testi evitando il continuo duplicarsi di informazioni che poi risulterebbero non mantenibili, in particolare per guide complesse e piene di varianti come quelle dei Server Mail. Inoltre, in quest'ottica, rivedrei i titoli di molte guide, ad esempio "Mail server" (di mm-barabba) perché "impone" la sua scelta come se fosse quella universale, bisognerebbe, imho, dargli un titolo più specifico tipo "Mail server: postfix, MailSCanner, Procmail, Courier". mentre il titolo generico andrebbe benissimo per una "lezione" più teorica su server mail (MTA, MDA, MUA cosa sono, quali sofware ci sono nei repositori, ecc..) e come aggregatore di tutte le guide pratiche delle varie varianti presenti nel wiki.
Risca ha scritto:Invece con il transculsion è cose se ci fosse, nella pagina stessa, una finestra aperta sul riferimento di cui si ha bisogno.
Interessante
More+
PS: ho appena scoperto questa fantastica ma elefantina guida
http://guide.debianizzati.org/index.php/Internet_Service_Provider_con_Debian#Installazione_del_server_di_posta che si sovrappone a quella che ho appena scritto, (SEGNALAZIONE: nella guida citata si fa riferimento all'uso del demone spamd con Amavisd-new: il demone non va abilitato in quahnto è ottimale usare le API come segnalatao nella guida di Amavis. Qui una discussione:
http://mail-archives.apache.org/mod_mbox/spamassassin-users/201001.mbox/%3C4B43FA52.40401@verizon.net%3E) a mio giudizio, questa guida sarebbe da separare in più parti e fonderla,la sezione mail, con la mia, ecc..
PS2: Insomma, mi sembra che con la mia "collaborazione" stia creando uno tsunami nel wiki. Forse, per la prossima volta, è meglio che a questo thread diate un titolo che vi salvaguardi maggiormente: "Collabora al wiki (non per tutti) "