Newsgroup: it.comp.os.linux.sys
Titolo: Postfix ETRN o Relay?

Ciao a tutti.
La situazione è questa:
Server A connesso ad una linea dati affidabile, ip pubblico, 5 domini 
configurati
Server B connesso ad una linea adsl non stabile (down anche per 1 o 2 
giorni), ip pubblico.
La mia necessità è quella di 'spostare' un dominio dal server A al 
server B, demandando agli utilizzatori di tale server la gestione delle 
proprie caselle di posta e delle proprie policy di antispam. (questo 
significa che devono creare,modificare,eliminare le proprie caselle, il 
come fare me la vedo io).
Il sistema deve essere il più affidabile possibile, quindi niente 
accrocci tipo (sparo a caso) sincronia delle caselle con rsync o 
workaround vari come 'scaricatore di posta' tramite fetchmail + jolly su 
server A etc etc.
Pensavo ad una soluzione basata su uno di questi due sistemi
a) ETRN
b) Semplice relay dal server A verso il server B.
In primo luogo, i due sistemi sono molto simili, ovvero il server A 
appena riceve una mail per il dominio "
prova.com
" che è presente sul 
server B, inoltra tutto al server B. (ovviamente sul server A dico che 
il dominio "prova" è gestito in remoto)
Le differenze vengono fuori quando il server B è down.
Tramite relay (ed anche tramite ETRN) postfix ogni tanto scansiona la 
queue e cerca di consegnare le mail, ma con il metodo ETRN è possibile, 
in aggiunta, dire al server A "Hey, io sono raggiungibile adesso, 
mandami le mie mail" cosa non possibile tramite semplice relay.
In questo modo non bisogna aspettare ore o giorni prima che postfix 
reinvii le mail al server corretto. (e non voglio abbassare la scansione 
della queue perchè sarebbe un workaround)
Che soluzione consigliate di adottare?
Da quanto ho letto postfix non può funzionare da client ETRN (cioè 
inviare periodicamente delle richieste ETRN per farsi inviare i 
messaggi) in quanto è una soluzione adottata da client come fetchmail 
(che vorrei evitare).
Altrimenti sarebbe perfetto...
La premessa iniziale (linea dati affidabile e linea dati non stabile) 
serve ad indicare che non posso/non voglio far puntare il server B 
direttamente a livello di MX sul dns perchè il caso di server down, solo 
dio sa che fine fanno i messaggi non recapitati da telecom..... facendo 
da 'ponte' i messaggi non recapitati si fermano nella mia macchina.

 Altrimenti sarebbe perfetto...
Non e' che serva avere un MTA che funzioni come client ETRN...
Basta che, quando la linea e' su venga lanciato uno scriptino (DUE RIGHE
DUE in SH) che dica al Server A di spedire le E-Mail.
In fondo, basta una roba del tipo:
  echo -e "ETRN dominio.tld\n\QUIT\n" | nc serverA 25
niente di piu'! Il Server A sa gia' a che IP inviare le E-Mails!
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

 /dev/null tutta l'immondizia non consegnabile...
Questa invece la sconsiglierei vivamente. Piuttosto, un indirizzo di
catchall che venga consultato su base periodica (settimanale?) a caccia
di eventuali typo da parte di qualcuno. Purchè la rumenta che ci finisce
dentro non sia troppa, o diviene ingestibile...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGTDEl8THo01J+SBERAqC4AJwKFUtJPP6EXRMwl/oxW7IGZWMbEwCfTBUr
77ekLfgnbGPvPvakfdL5xvU=
=0Kk6
-----END PGP SIGNATURE-----

 niente di piu'! Il Server A sa gia' a che IP inviare le E-Mails!
Ottimo, in questo caso sarebbe perfetto. Non volevo usare fetchmail per 
intenderci.
Posso metterlo in cron ogni 15-30 minuti.....Se la linea è giù il 
comando non sarà eseguito (per ovvi motivi)

 dentro non sia troppa, o diviene ingestibile...
Niente catchall per cortesia.
Ci ho messo 1 anno a debellarli e non voglio essere io a reintrodurli.
(Altrimenti, che figura ci faccio, suvvia.....)
Possibile che non ci sia un metodo trasparente per 'rigirare' le mail da 
un server ad un altro senza interventi da parte mia oltre a quello di 
configurare il redirect?
Mi pare di capire che le problematiche siano le stesse sia tra ETRN che 
semplice relay in transport.....
Un qualcosa stile 'smart-host' al contrario.
Però, in caso di smarthost non ho mai verificato dove vanno a finire 
eventuali bounce, se a me, o al mio smarthost....devo verificare.

 eventuali bounce, se a me, o al mio smarthost....devo verificare.
All'envelope-sender usato per l'invio, dove altro... :-P
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGTDa/8THo01J+SBERAvjHAJ4vopFthHfAvFrECH2Jtm5UhSzouQCghA4C
A9g1ACJJuFRHfOcXmvRjRwU=
=0oqe
-----END PGP SIGNATURE-----

 non lo voglio nemmeno sapere!)
Guarda, se non vuoi assolutamente sapere NIENTE del Server B e
contemporaneamente evitare di caricare monnezza su tale Server B, che mi
risulta c'e' una sola possibilita': Server B come MX primario e Server A
come secondario!
Quando il Server B e' su, riceve le E-Mail e se le smazza da solo
(rifiutando eventualmente il ciarpame), quando e' giu' vengono ricevute da
A (senza filtri! Le mette in coda) e appena il Server B e' su le rigira a
lui. Ovvio che l'MTA del Server A deve avere un Retry abbastanza rapido
per le E-Mail @serverB (non so dire se e come si possa fare con Postfix.
So che con Exim e' una configurazione banale).
In questo modo hai un buon controllo dell'immondizia e nessuna necessita'
di Catchall.
Quando il Server B e' down, le E-Mail rimangono sul Server A e appena B e'
su gli vengono rigirate.
Tutte le E-Mail non consegnabili, tornano indietro al mittente (con
ritardo e, ovviamente, senza nessun modo di spedire direttamente un errore
5XX all'MTA "vero mittente").
E' un po' brutta come soluzione, visto che sai a priori che il Server B e'
una chiavica, ma se non vuoi Catchall (e fai TANTO BENE!), non e' che ci
siano tante altre possibilita'...


 lui.
Il che non impedisce affatto di farti carico della rumenta di B, però:
gran parte dello spamware legge le priorità MX al contrario, e troverai
anche che son B vivo e vegeto una discreta quantità di mail cercherà di
passare per A.
Provare per credere...
E poichè la gran parte della rumenta diretta ad utenti inesistenti è,
neanche a dirlo, spam, ti ritrovi sempre e comunque con il problema
degli utenti inesistenti da gestire, altrimenti sei (di nuovo) un grosso
emettitore di backscatter...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGTEqF8THo01J+SBERAtvHAKC02MwtojhO3mLEMF7AvX1DHK/UOgCfWDak
qkaVVQr48wxBDo1onxeB7BE=
=k3JF
-----END PGP SIGNATURE-----

 Luca Bertoncello wrote:
Quoto tutto di tutti e due
Io so a priori che il server B è una ciofeca perchè ho estremizzato 
l'esempio. Il server B è gestito da me a livello sistemistico, ma poi 
gli utenti di tale rete si creano le proprie caselle.
La linea del server B è una ADSL tradizionale o una HDSL 'standard' da 
PMI quindi niente backup, niente ridondanze o robe simili.
Il mio scopo è posizionare un server di posta nella sede del cliente.
Ora, utilizzando esclusivamente gli MX, se '
cirip...@telecom.it
' 
invia mail a '
serv...@server-b.com
' quando la linea xDSL remota è giù, 
nessuno sa che fine faccia il messaggio. Verra consegnato prima o poi? 
viene segato via da telecom? Non sono mai riuscito a capire (a secondo 
del SMTP del mittente ovviamente).
L'80% dei provider consegna il messaggio dopo qualche ora/giorno, ma 
telecom booooo.
Il cliente quindi si ritroverebbe con degli svantaggi aggiuntivi 
rispetto alla soluzione attuale dove la posta elettronica è sui nostri 
server.
La soluzione MX di backup potrebbe essere ottimale da un certo punto di 
vista.
Il traffico 'buono' passa solo per B, in caso di down arriva ad A dove 
se ne sta buono buono in coda a prescindere dalle email configurate o 
meno sul server A. Però non ho ben capito il lati negativi che mi avete 
esposto a parte quello dello spam. (come risolverlo? qualche hint? 
ovviamente mi riferisco a quella precisa casistica e non allo spam in 
generale)
Diciamo che è impossibile, per me, sapere quali caselle sono state 
create su B e quindi sincronizzare A a dovere.
Fare transport mi pare di aver capito che non sia il massimo in quanto 
mi ritroverei un carretto di backscatter generato da B in caso di reject 
causa policy antispam o robe varie. O sbaglio?
E la stessa cosa accadrebbe con ETRN il cui funzionamento, da un certo 
punto di vista, è identico (A invia messaggi a B, il quale li rifiuta)
O se no housing a manetta qui in sede anzichè server di posta dal 
cliente. Alla fine il server che il cliente deve acquistare è lo stesso, 
cambia solo la linea e l'affidabilità del datacenter. In questo modo 
posso permettermi un MX diretto perchè so già che la linea non va giù. 
(non va giù con la stessa frequenza di una xDSL residenziale con la 
donna delle pulizie che stacca tutto)

 cambia solo la linea e l'affidabilità del datacenter.
Sicuro, ma dipende anche da "perchè l'utente vuole un mailserver tutto suo".
Oltre al fatto di avere autonomia nella gestione degli utenti, intendo,
che con il SW e la struttura adeguata puoi darglielo anche senza
dedicargli tutto un server (di oggetti che lo permettono ce n'è più
d'uno...).
Se -ad esempio- è una realtà che produce un traffico mail interno
"importante" (gente che si scambia tanti allegati di dimensione
abbastanza significativa), allora il fatto di avere il mailserver
all'esterno (non importa dove) non aiuta di un penny, dato che tanto
tutto continua a fare avanti-indietro sulla linea pubblica...
Se invece è un cliente con l'amico sistemista particolarmente figo, di
quelli che "sa lui", allora li lascerei nel loro brodo con l'unico MX in
casa sua... :-P
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGTFRs8THo01J+SBERAleyAJ0UFv0C7AogabaEZGGLZiyEexTl6QCeOXcM
Ip2JxHn3TD/s0APXXOa1ld8=
=GKmm
-----END PGP SIGNATURE-----

 casa sua... :-P
Da un certo punto di vista si, infatti non voglio dare servizio smtp a 
loro. Proponiamo una soluzione più 'professionale' con server di posta 
dedicato che invia dalla loro linea (come è giusto che sia).