Newsgroup: it.comp.os.linux.sys
Titolo: [OT] gestione domini con Aruba e MX secondario

Scusate l'OT. Qualcuno di voi usa Aruba come hosting dei propri domini?
Ho acquistato un servizio di sola gestione DNS, come MX primario uso uno
 dei miei host, cosa posso usare come MX secondario? Ho cercato in lungo
e in largo sul sito di Aruba e mi sembra che questo servizio non sia
previsto.
Grazie
	Y.


Il concetto stesso di MX secondario non ha pi� senso da anni...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Il concetto stesso di MX secondario non ha pi� senso da anni...
Ops, sono rimasto indietro...
Riesci a spiegarmi il perch�?
Grazie
	Y.

 Il concetto stesso di MX secondario non ha più senso da anni...
Primario e 1/2? Terziario?
Ovvero se MX primario cade e si fa male, un altro che almeno per un
tempo limitato 7-10 giorni, riesca a gestire la posta in arrivo in
vece sua piuttosto che perderla, come si chiama?

 vece sua piuttosto che perderla, come si chiama?
Si chiama "code del mittente".
Se una qualsiasi entit� fa uso dell'email in modo sufficientemente
critico perch� lo scenario che dipingi sia un problema ma non � in grado
di (far?) rimettere in piedi il mailserver in capo ad un paio di giorni,
ha una infrastruttura IT inadatta.
O si adegua l'infrastruttura, o si individua un fornitore che dia le
garanzie di continuit� di servizio del caso.
L'MX secondario � di fatto solamente un pessimo palliativo: a meno che
non sia gestito e curato direttamente dall'entit� che mantiene il
mailserver aziendale e abbia pertanto una gestione di filtri e database
utenti allineata con quest'ultimo (e si ricade quindi nella
"infrastruttura IT") la sua sola esistenza causa pi� problemi (spam,
backscatter, ecc) di quanti ne risolva.


 vece sua piuttosto che perderla, come si chiama?
vice?

 ha una infrastruttura IT inadatta.
E se Uragano (l'amico di Terremoto, piu` autoctono qui da noi) oltre
ad MXUnico si porta via anche Salaced come la mettiamo?
Andrea

 ad MXUnico si porta via anche Salaced come la mettiamo?
O hai un un piano di disaster recovery (nel qual caso sei un pirla se il
tuo mailserver � vitale e non ce lo hai inserito) o non ce l'hai.
E se non ce l'hai, del mailserver non so cosa te ne fai, mancando tutto
il resto di Salaced.
Se invece non hai nemmeno Salaced e il tuo mailserver critico � un PC
con Ubuntu nello scantinato, allora hai un problema. Ma non � l'assenza
di un secondo MX.


 di un secondo MX.
Hummm.... la tua logica non fa una grinza Skull (come molte altre volte direi) 
pero' mi associo agli altri per cui un semplice MX secondario, magari appoggiato 
in una sede remota che sta li' a collezionare spam non fa male a nessuno e 
magari ti permette di tirare giu' per manutenzione l'MX principale senza doverti 
crucciare troppo di perdere mail importanti.
IMHO in sunto non e' poi cosi' male, pur rimanendo vero tutto quello che hai 
detto qui sopra. E' che mi suona un po' tanto "teutonico" come approccio 
(nell'accezione rigida dell'appellativo)
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verit� � 
che non avere nulla da perdere significa essere pronti a rischiare tutto ci� che 
si possiede.

 Si chiama "code del mittente".
forse non ho capito bene...
vuoi dire che la non disponibilità di un MX (destinazione) deve essere 
gestita tramite una coda dell'MX mittente?

 gestita tramite una coda dell'MX mittente?
E' quello che succede quotidianamente, direi.

 tuo mailserver è vitale e non ce lo hai inserito) o non ce l'hai.
Un MX TerziarioMenoUno non potrebbe far parte di quel piano?

 backscatter, ecc) di quanti ne risolva.
Non posso far altro che concordare.
un MX nel 2010 è un pessimo oggetto quando non è gestito e configurato 
bene. Ed il 90% degli MX secondari ricade in questa categoria.
Nessuno ti vieta di installarlo, ma se non lo sai configurare e 
manutenere, evita e delega al mittente.
Fai meno danni a te e agli altri.

Piuttosto un MXQuaternarioMenoDue non potrebbe anche rendere
accessibile le emails che gli sono arrivate ai destinatari (pop3/imap/
webmail)? Mi rendo conto che non e` propriamente il suo compito, ma
non potrebbe essere un buon valore aggiunto?

CtRiX ha scritto:

lo so... ogni bravo MX dovrebbe comportarsi così. Ma se dovesse 
verificarsi un problema sul mio MX (offline per tot ore), per evitare di 
perdere posta preferirei risolvere "in casa" con un MX secondario, 
piuttosto che confidare nella correttezza (e nelle code) degli n MX che 
cercano di spedirmi posta..
Per me, l'MX secondario ha ancora il suo perché...



Complicare le cose semplici è un tuo punto forte!
pop3/imap/webmail per funzionare hanno bisogno di mailbox.
Per funzionare le mailbox hanno bisogno che la mail esca dalle code del 
server SMTP.
Quando l'MX primario torna online, chi le rimette in coda per 
ripristinare le mailbox come dovrebbero essere ?

 Per me, l'MX secondario ha ancora il suo perché...
Punti di vista.

 l'MX principale senza doverti crucciare troppo di perdere mail importanti.
Fintantoch� lo spam se lo tiene in panza, non vedo problemi.
Il punto per� � che l'approccio "classico" con un MX secondario su una
entit� terza (Aruba, nel caso dell'OP) implica una cosa di questo genere:
1) ${BOT} invia spam con mittente ${INDIRIZZO_FALSIFICATO} a
${UTENTE_INESISTENTE} e la consegna a ${MX_SECONDARIO} su Aruba (o
chicchessia)
2) ${MX_SECONDARIO} � solo quel che �: un MX secondario. Accetta tutto e
rigira a ${MX_PRIMARIO}, perch� � il suo mestiere: non ha idea se un
destinatario esiste o no. Quando lo fa per la mail ricevuta da ${BOT},
cerca di consegnare a ${UTENTE_INESISTENTE}, ottentendo per� un 554 da
${MX_PRIMARIO}, che invece gli utenti li conosce.
3) ${MX_SECONDARIO} genera quindi un bounce e lo invia a
${INDIRIZZO_FALSIFICATO}, il quale riceve immondizia senza alcuna colpa
tranne che l'essere una vittima *indiretta* dello spam inviato da ${BOT}
e vittima *diretta* di una configurazione *tua*.
Si chiama basckscatter.
Una variante la hai quando i filtri che "proteggono" gli account su
${MX_PRIMARIO} sono disallineati rispetto a quelli (se ci sono) che
stanno su ${MX_SECONDARIO}: ${MX_SECONDARIO} accetta la mail e la
consegna a ${MX_PRIMARIO}. La mail � per� considerata spam e rigettata,
e ${MX_SECONDARIO} si trova di nuovo a generare un bounce.
Oppure istruisci ${MX_PRIMARIO} affinch� accetti bovinamente tutto quel
che giunge da ${MX_SECONDARIO}, e prendi atto che un TOT si rumenta
arriver� agli utenti per quella via
L'unica soluzione percorribile senza riversare il problema su altri �
far s� che (appunto) sia i filtri che le liste di utenti siano allineate
su entrambi gli MX, il che implica anche che siano -in linea di massima-
sotto il controllo della stessa entit�.
Quindi o il fornitore di servizio (se lo dai in outsourcing; il che non
implica necessariamente che anche le mailbox stiano dal fornitore:
l'importante � che questi sia in condzione di conoscere l'esistenza o
meno dei vari indirizzi, ma dovr� gestire *tutti* gli MX consegnando poi
al tuo mailserver) oppure direttamente tu (e quindi anche quel
secondario entra a far parte della tua infrastruttura IT).


 manutenere, evita e delega al mittente.
Io parto dal presupposto, come mi sembra facciano altri che sostengono questa 
tesi, che se uno si tiene un MX primario in casa magari e' in grado di 
manutenerselo (in maniera piu' o meno maniacale) percio' metterne su anche uno 
secondario e' una cosa che va da se. Tutto li'.
Ti da la sicurezza di essere comunque raggiungibile a dei costi accettabili e 
senza complicarti magistralmente la vita.
Poi se dobbiamo fare il processo alle intenzioni e mettiamo a priori in dubbio 
la capacita' di gestione di ogni sistemista allora possiamo proseguire con le 
polemiche inutili ma di fatto, per quanto mi riguarda, la pratica di avere un MX 
secondario e' tutt'ora praticabile.
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verità è 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciò che 
si possiede.

 ripristinare le mailbox come dovrebbero essere ?
Perdona loro che non sanno quello che dicono (quindi anche me), ma
concettualmente non mi sembra proprio un problema, nel senso che basta
un proxy che una la mette nella mailbox di la` e la stessa nella coda
di qua.
Certamente sarebbe piu` impegnativo per l'MX che non farebbe solo piu`
il suo lavoro ma non mi sembra una cosa trascendente.

 di qua.
Se la fai in questa modalit�, certamente, ma tende a creare confusione
nel flusso: la mail potrebbe avere N destinatari finali, ma chi ha la ha
letta?


 secondario entra a far parte della tua infrastruttura IT).
Come dicevo anche a Ctrix io parto dal presupposto che tutto sia gestito e 
manutenuto secondo un minimo di criteri decenti, poi ci sta che si sbagli una 
configurazione per disattenzione o inesperienza (le mie in testa, lo ammetto).
Io cercavo di capire proprio il motivo per cui escludevi l'utilizzo dell'MX 
secondario a priori. In caso di misconfigurazione non posso che essere d'accordo 
con te e Ctrix


 secondario entra a far parte della tua infrastruttura IT).
Grazie, mi sembra che spiegata cosi`, per esteso, la cosa abbia senso,
quindi se si vuole un MX2 e` meglio gestirselo o che comunque lo
gestisca chi gestisce anche MX0.

 la pratica di avere un MX secondario e' tutt'ora praticabile.
...certamente vero.
Anche se mi vien da domandarmi perchè, invece, non ci si implementi un
cluster, piuttosto: con un banale DRBD + Heartbeat si possono gestire
anche dimensionamenti considerevoli, e il costo in HW è lo stesso...


 utenti (in un'entita' aziendale che non fornisce servizi esterni) ?
Dipende solo da come gestisci gli indirizzi.
Anche una banale esportazione + rsync pu� essere sufficiente.
Al resto ci pensa relay_recipient_maps (o la equivalente dell'MTA in uso).


 Al resto ci pensa relay_recipient_maps (o la equivalente dell'MTA in uso).
Avendo un servizio active directory lo useresti con ldap o eviteresti 
l'interazione tra MX in DMZ e domain-server interni ?
Perche' il metodo di cui parli tu mi sembra valido per degli indirizzi non 
gestiti da sistemi non MS, o sbaglio ?


 essere d'accordo con te e Ctrix
Il problema � che quella che ho descritto non � una "misconfigurazione".
E' la normale configurazione di un MX secondario.
Se te lo gestisci tu e fai quel che si diceva (relay_recipient_maps etc)
hai di fatto un sistema a 2 tier, con il tier1 a far relay verso il tier2.
La configurazione dei record MX sul DNS potr� anche essere la stessa
[1], ma la configurazione dell'MTA � tutt'altra roba...
[1]...ma anche no: tutti i miei sistemi sono a 2 tier, quando non a 3
(ed in passato anche a 4 :-P): 
http://www.spin.it/?TYPE=2&ID=90
Tuttavia non ho alcun MX secondario in DNS...


 non gestiti da sistemi non MS, o sbaglio ?
E perch� mai?
http://bit.ly/9AZiqF


 la pratica di avere un MX secondario e' tutt'ora praticabile.
Non è un processo alle intenzioni.
La gente non ha idea di come configurare decentemente un MX2.

 Tuttavia non ho alcun MX secondario in DNS...
Hemmm.... ma e' per quello che tu sei Skull ;)
Scherzi a parte, quella e' una configurazione da isp fatta come Dio comanda.


 
http://bit.ly/9AZiqF
Uhmmm... slurp.... pappa per il mio bookmark (sempr ein attesa di avere tempo 
per finire il lavoro iniziato tempo fa)
Grazie dello scambio


 Hemmm.... ma e' per quello che tu sei Skull ;)
In realt�, per la cronaca, la struttura attuale non � molto diversa da
quella che realizz� Furio nel '98.
Uniche differenze sostanziali il fatto che allora
- era tutto su freebsd (irrilevante)
- tutte le transport erano esportate in modo asincrono come file .db e
non -come ora- su SQL.
- i tier erano 3 (fare scansione AV in pre-queue all'epoca era
computazionalmente quasi impensabile, quindi c'era un tier AV dietro i
sistemi antispam).
- gli MTA erano sistemi unici e non il cluster di pi� sistemi
- i sistemi del flusso di uscita (che comunque in quello schema non sono
rappresentati) coincidevano con quelli di ingresso, cosa che non � pi� vera
Per il resto, non � poi cambiata molto.
E, d'altra parte, non ci son poi molte topologie possibili per far
scalare un sistema con le medesime finalit� (e infatti sono
sostanzialmente tutti simili)...


 non -come ora- su SQL.
sorry, curiosità OT: che DBMS, e come è ridondato?
(dove lavoro io il sistema è asincrono esportando su file)
grazie :)
ciao,
stefano

 sorry, curiosit� OT: che DBMS, e come � ridondato?
Banalissimo MySQL, con replica e master in HA.


 
Toh ... era parecchio tempo che mysql non veniva qui citato per un uso utile 
amichevole  ... ma era solo accusato di ogni nefandezza ...

 ad MXUnico si porta via anche Salaced come la mettiamo?
Stappiamo lo Champagne!
Si perch� si fa richiesta di "calamit� naturale" ed automaticamente non 
possono pi� essere fatti controlli fiscali per gli anni passati n'� per 
i 2 anni a venire!
Fanculo il Disaster Recoveri! Viva il terremoto!

 i 2 anni a venire!
Te quindi vorresti pagare l'ici anche per due anni a seguire
dalla distruzione della tua casa? Paghi l'ici su cosa?


hint: L'aquila
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu