Newsgroup: it.comp.os.linux.sys
Titolo: Reject su MX

Se ne era già discusso in passato, mi pare, ma non trovo il thread.
Supponiamo di avere una rete di server fatta cosi':
cliente -> server smtp cliente -> server MX -> server di destinazione
Se cliente invia una mail con contenuto non accettato (rbl e così via)
dal server MX, il server MX la rifiuta e "qualcuno", penso il server
SMTP, genera un bounce.
Credo che il comportamento sia normale.
E' possibile evitare o quantomeno limitare questi bounce?

 E' possibile evitare o quantomeno limitare questi bounce?
Cattiva idea: un bounce è il risultato di una mancata consegna. Se
limiti la generazione dei bounce, qualcuno non sa che la sua mail non è
andata da nessuna parte, e ciò è sempre *male*.
Anche perchè cerchi la soluzione al problema sbagliato. Nello scenario
che dipingi il problema è che "server smtp cliente" sta veicolando spam
(nel qual caso la soluzione deve agire su questo aspetto, non sulle
conseguenze) oppure il filtraggio operato dall'MX (quindi lato
ricevente) è eccessivamente aggressivo (nel qual caso bisogna correggere
il ruleset).
-- 
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 ruleset).
Beh, supponiamo ci sia gmail come smtp.
Io non posso modificare il ruleset di gmail forzando maggiori
controlli antispam,
quindi, prima o poi, al mio MX arriverà una mail che secondo la mia
policy, non è valida.
Il mio MX rifiuta la mail, gmail genera un bounce.
Il che va anche bene, ma ricordo che tempo fa si discusse di un
qualche
effetto collaterale, ed ovviamente non ricordo quale...
BTW, i miei dubbi, nascono da questo log "sospetto":
2011-05-05 12:38:45 1QHvxF-0000yF-51 H=smtp.provider.tld [1.1.1.1]
F=<mitt...@dominio.tld> rejected during MIME ACL checks: Blacklisted
URL in message. (
test.uribl.com
) in [black]. See 
http://lookup.uribl.com
.
Questo log  è presente nel mio MX, il quale ha rifiutato la mail.
In questo modo, smtp.provider.tld dovrebbe generare un bounce perchè
il mio MX non ha accettato la mail, dico bene?
Dovrebbe essere tutto ok.

 Dovrebbe essere tutto ok.
Così pare.


 Così pare.
Bon, il log mi ha tratto in inganno e mi sembrava un comportamento
anomalo.

 in questo caso generi backscatter.
Supponiamo che il mailserver di destinazione (mio), per il quale l'MX
fa da relay, non dovesse funzionare.
Attualmente ho la verifica di tutto il recipient e non solo del
dominio, pertanto se il server di destinazione
non dovesse funzionare, il mio MX spara indietro un 451 dicendo di
riprovare perchè il destinatario non può
essere verificato.
Sarebbe perfetto, il server mittente riceve il 451 e riprova dopo non
si quanto , ne per quanto tempo.
Considerato che è pieno di server configurati alla c.d.c. non ho la
certezza matematica che il mittente riprovi dopo aver ricevuto un 451.
Può aver senso accettare la mail (anzichè sparare il 451) e poi
rimbalzarla in un secondo tempo nel caso l'indirizzo non fosse valido?
In alternativa, può aver senso portarsi dietro l'elenco delle caselle
anche sugli MX facendo fare il controllo direttamente al server MX
stesso
evitando la verifica dei destinatari ? In questo modo se il mail
server non dovesse funzionare, io la mail potrei comunque accettarla
sapendo
a priori che tale indirizzo è corretto.
Attualmente ho solo l'elenco dei domini, ma non quello degli indirizzi.

 a priori che tale indirizzo è corretto.
Secondo me comunque tu lavori all'UCAS (ufficio complicazioni affari 
semplici).

 semplici).
Sempre meglio dei tanti che intanto metton su "che funziona" e se ne
fregano di backscatter e tutto il resto, però... :-P


 semplici).
Pagano profumatamente :)

 l'MX per se stesso.
Se l'utente mette l'MX da te non è certo per fargli da coda per la posta
quando il suo server è a remengo, spero.
Perchè l'uso degli MX di backup è roba da anni '90...


 Perch l'uso degli MX di backup roba da anni '90...
Te come faresti quindi? niente MX di backup? (per la cronaca, in
questo
caso non sarebbe un mx di backup, non ne ho più da molto tempo)

 questo caso non sarebbe un mx di backup, non ne ho più da molto tempo)
Già trattato il caso in passato, cerca vecchi thread.


 martellare il backend- e 450 che questo non è disponibile.
Ovviamente con caching.

 Si, posso farlo, ma il sync non sarebbe in tempo reale.
Scusa, ma non capisco.
Se gli utenti vengono generati da un qualsiasi script di provisioning,
basta far sì che il sync avvenga a partire dal provisioning.
Ma anche se così non fosse, fare uno script che gisi sul mailstore e che
venga richiamato ogni minuto affinchè verifichi se la lista di utenti è
cambiata e solo in quel caso esegua il sync verso gli MX è cosa da due
minuti...


 minuti...
E' esattamente quello che faccio. Non ogni minuto ma ogni 5
(l'operazione
è pesantuccia, impiega una paio di minuti a terminare).
Ecco il perchè parlavo di mantenere il callout per eventuali indirizzi
non
presenti in lista. In quei 5 minuti potrebbero esserci variazioni sul
server
non ancora replicate sugli MX. In questo modo l'MX prova comunque a
fare il delivery della mail, eventualmente respingendola con un 500
perchè
inesistente sul mailstore. Una sorta di buffer in sostanza.

 inesistente sul mailstore. Una sorta di buffer in sostanza.
Non so che clienti hai, ma considerando che ti è esploso il datacenter,
credo che il disallineamento di uno e due utenti sui relay esterni è più
che giustificabile dagli stessi. Perchè non credo che ti capiti una
volta a settimana...
Se non lo è, e devi garantire un servizio a prova di esplosione
termonucleare, allora stai -di nuovo- risolvendo il problema sbagliato,
poichè quel che devi ripensare è l'architettura di tutto il sistema, che
deve essere realizzato per consentire una ridondanza geografica e sincrona.
Altrimenti applichi accrocchi inutili per risolvere problemi inesistenti.


 deve essere realizzato per consentire una ridondanza geografica e sincrona.
E' proprio la ridondanza degli MX che voglio fare.
Mi pare di capire che tu stia dicendo di fregarmene e non accettare le
mail nel caso
il callout non andasse a termine, sparar fuori un 4xx e lasciar fare
l'accodamento
al mittente? Se si, il discorso decade, e non dovrei nemmeno portarmi
dietro
l'elenco degli utenti sugli MX.

 4xx e lasciar fare l'accodamento al mittente?
Esatto.


 Esatto.
Ok.
Quindi quali possono essere i vantaggi (escludendo il carico)
nell'utilizzare
due o più server MX, magari dislocati in giro per il mondo, piuttosto
che far
fare da MX direttamente al mailstore?
Il risultato è sempre quello, se va giù il mailstore, gli MX (che sia
uno o 15)
sparano indietro un 4xx, se va giù il mailstore con MX integrato il
mittente accoderebbe
comunque.
Aumenta solo la complessità della infrastruttura ed incrementa il
numero
di apparati che possono dare problemi.

 di apparati che possono dare problemi.
Che senso ha mettere un firewall davanti a un server?
Oramai qualunque OS ne ha uno a bordo, e se va giù il server che il FW
ci sia o no il server è irraggiungibile comunque.
Aumenta solo la complessità della infrastruttura ed incrementa il numero
di apparati che possono dare problemi.
-- 


 ci sia o no il server è irraggiungibile comunque.
Uhm, ok,

> Uhm, ok,
gand, a me non è ancora chiaro il perchè ti scandalizzi tanto dare un 
reply 4xx... per natura stessa del protocollo smtp un errore 4 prevede 
un reinvio del mailserver mittente. punto. se il mailserver mittente non 
reinvia (ed è una cosa RARISSIMA) il problema non è il tuo, ma del tuo 
mittente che, come minimo, questo problema lo conosce.
se mando un'email da 
@
grandissimoproviderchemandadopo6oreinseguitoadunerrore4xx.it
, fidati 
che lo so che le mie email ogni tanto arrivano dopo 6 ore.
il problema non è tuo.
sai chi non reinvia le email in seguito ad un errore 4? gli spammer. 
...e la tecnica si chiama greylist e funziona abbastanza bene (se il 
cliente accetta di attendere la prima email -solitamente- per qualche 
minuto).

 minuto).
Bah, ho tolto il greylist da mesi, tanto una buona fetta dello spam
attuale passa
da server legittimi o macchine zombie. Ad oggi reputo il greylist solo
una rottura
di cojones per le mail legittime.

> Il cliente, però, chiama me incazzato nero e non $GrandissimoProvider.
si ma stai dimenticando che, nel tuo caso, l'errore 4 lo stai 
restituendo perchè ti hanno sganciato una bomba atomica nel ced. 
comunque del disservizio lo dovrai dare.
altrimenti la ridondanza a caldo e completa è tutt'altra cosa e la fai 
non con i meccanismi nativi degli mta, ma con i meccanismi nativi DELLA 
ridondanza.
IMHO eh..

 ridondanza.
Non saprei, a me sembrava più sensato, a logica, far accodare le mail
dentro la mia rete, dove io ho il controllo su cosa sta capitando.
Per assurdo, potrei avere un problema al mailstore di non semplice
risoluzione. Avendo le mail accodate sul mio server potrei
reinstradarle
su una macchina 'tampone' a cui i clienti accederebbero via webmail.
Se le mail invece di stare da me fossero accodate non si sa dove,
questa
operazione non potrei farla se non riconfigurando gli MX (facendo
quindi
puntare tutti i domini ad un mailstore specifico) ed aspettando che
l'smtp
remoto ritenti l'invio.
Solo supposizioni eh...

 reinstradarle
O potresti perderle del tutto, senza sapere quali, e senza che lo
sappia il mittente, se quel tuo server esplode.
Non mi sembra geniale, some soluzione.
Un mio amico toscano direbbe che metti il culo nelle pedate, visto
che prendi TU i rischi per una errata configurazione altrui.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 questa operazione non potrei farla se non riconfigurando gli MX
Perchè invece nel caso precedente il resinstradamento avviene attraverso
riti voodoo?


 che prendi TU i rischi per una errata configurazione altrui.
A casa mia, dal momento che offro un servizio, ai clienti non importa
di chi è il problema. La fattura a loro arriva da me, loro pagano me
e vedono me come unico interlocutore (ed è giusto così) problemi o non
problemi.
Immagina le ADSL in wholesale. Tu ti abboni con l'operatore Ciccio.
Se ti va giù l'adsl, te ne sbatti il piffero di risposte come:
"telecom
non va". I soldi tu li dai a 'Ciccio' e 'Ciccio' deve, giustamente,
risolvere il problema.
Della telecom a te non ti importa (e non ti deve importare) una fava.

 riti voodoo?
Certo che no, ma torniamo al punto iniziale: siamo sicuri che il
mittente
gestisca correttamente un 4xx ritentando dopo un po o per un tempo
sufficientemente lungo?
Per me il discorso verte su:
a) meglio tenere le mail in casa e gestirle in autonomo
b) respingere tutto mandando indietro le mail non si sa dove e non si
sa fino a quando ?
io tra le due soluzioni preferirei la prima, almeno non ci sono altri
operatori
coinvolti, ma a quanto pare qui tutti dite l'opposto.

 sufficientemente lungo?
Non siamo nemmeno sicuri che il mittente non cerchi di recapitarti mail
usando una sessione HTTP, quanto a quello, ma ti consiglierei di
concentrarti su quel che è realistico ed opportuno in base allo
*standard* di quel che accade lì fuori, non di sforzarti a cercare un
problema per una soluzione che credi di aver già trovato.
Poi, oh, libero di incasinarti la vita come ritieni più opportuno...


 problema per una soluzione che credi di aver già trovato.
Quindi, in sostanza, il voler accodare le mail sui propri server
nel caso ci dovessero essere problemi all'interno della propria
rete è davvero una idea così folle?

 rete è davvero una idea così folle?
1) Visto che il protocollo *è già* stato pensato per risolvere gli
stessi problemi, sì.
2) Se devi applicare del lavoro per migliorare qualcosa, cerca di
applicarlo a qualcosa che abbia un senso, come ridondare/clusterizzare
il backend, che è dove hai il problema vero.


 DELLA ridondanza. 
Insomma, ti prendi carico di un possibile problema non tuo con
strumenti "sbagliati", forzando il protocollo.


 Il cliente, però, chiama me incazzato nero e non $GrandissimoProvider.
Seguendo la stessa logica dovresti trovare una soluzione per quelli
che sbagliano a scrivere l'indirizzo email del tuo cliente.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 il backend, che è dove hai il problema vero.
E' un casino ridondare geograficamente il backend.

 che sbagliano a scrivere l'indirizzo email del tuo cliente.
beh, no, li la posta non arriva per problemi non miei e facilmente
spiegabili al cliente.
tu pensi di riuscire a dire al cliente che telecom (o chi per loro)
ha il server configurato male? C'è parecchia ignoranza in giro, e dal
punto di vista dei clienti, spesso il grosso ha ragione sul piccolo.
non è la prima volta che mi sento dire: "possibile che $GrossoProvider
abbia sempre problemi e voi mai? Scusate, hanno migliaia di
dipendenti,
migliaia di server e non san fare il loro lavoro mentre voi che siete
1/100 si? Mi pare un po megalomane e surreale il vostro discorso, più
probabile che sia un problema vostro ed accusate gli altri per non
ammetterlo"


Quindi hai tanto da fare ;-)
Per la cronaca, cmq, il casino è soprattutto gestire lo split brain, in
geografico.
Dal punto di vista della banda, per un mailserver non dovresti avere
grossi problemi a farlo...


 ammetterlo"
Guarda che di idioti è pieno il mondo, non è una novità.
Ma metterti a fare idiozie sui tuoi sistemi serve solo a portarti al
loro livello, non certo a migliorare la situazione...


 loro livello, non certo a migliorare la situazione...
a me non sembrava una idiozia, tutto qui.

 grossi problemi a farlo...
Uno stimato potrei farlo guardando il traffico sugli MX.
Ciò che entra può solo essere uguale o superiore a ciò che viene
scritto
ed i miei MX attualmente fanno traffico quasi trascurabile.

 ammetterlo"
Certo, mi succede, ma una volta che sono sicuro di aver fatto il
possibile *nei limiti di quanto contrattualizzato* mi sento tranquillo.


 da chi dice di non avere questi problemi.
Si vede che puoi permetterti di mandare via clienti di migliaia di
euro,
perchè di questo si tratta nel mio caso. Come ho scritto, sono clienti
che non possono permettersi di non ricevere mail. (se arrivano con
qualche ora di ritardo poco importa, l'importante è che arrivino)
Se io dicessi una cosa del genere al cliente, il primo ad andare oltre
la porta sarei io.

 la porta sarei io.
Se il problema non lo creo io, probabilmente non lo posso risolvere
io... ti assicuro che le configurazioni assurde sono tante, e se prometti
al cliente che non perderà posta metti solo il culo nelle pedate.
Tra le varie configurazioni 'estemporanee' ho anche trovato un server
smtp che buttava la posta diretta ai .to (forse anche ad altri ccTLD di
cui la scim^H^H^H il sistemista non conosceva l'esistenza).
Inutile dire che il cliente di turno aveva un .to e ha perso una fornitura
di ennemila euro di carburante perché non ha ricevuto la mail in cui
gli facevano l'ordine e che la colpa secondo lui era mia.


 
<estremizzazione>
se metti in piedi tutto il sistema che hai descritto mi sa che fuori dalla 
porta ci finisci comunque, solo piu' alla svelta.
vuoi gestire un servizio delicato come la posta elettronica in maniera 
macchinosa, non standard e in barba a qualsiasi rfc.
secondo te e' piu' facile *perdere* email con sistema macchinoso come 
quello che vorresti inventarti tu oppure con un server smtp che lavora 
nella maniera che tutto il resto del mondo s'aspetta, a cui viene fatto 
fare il suo lavoro nella maniera prevista?
ho messo *perdere* perche' in piu' post hai parlato a di email *perse* 
anche in caso di 4xx/5xx, quando sappiamo tutti che in quei casi al 
mittente arriva un avviso di mancata consegna entro tempi ben definiti: non 
sono email perse, sono email respinte/non consegnate e il mittente lo sa.
le email perse sono quelle che restano nel limbo nella tua coda locale e:
- per una svista di configurazione (si, potrebbe capitarti)
- per un cambio di comportamento dopo un upgrade di qualche sw che usi 
nella tua configurazione custom (lo so che controlli, ma lo sa anche 
murphy)
- per un effetto collaterale imprevisto della modifica di un parametro di 
cfg in uno dei vari programmi necessari per mettere in piedi il giro (il 
murphy di prima c'e' sempre)
- per un match imprevisto di una regexp con l'indirizzo mittente di una 
delle nmila email che ti arrivano (murphy fa lo spammer e s'inventa le 
peggio cose)
- varie ed eventuali in numero non prevedibile e tendenzialmente elevato 
(l'ho gia' detto che c'e' murphy?)
non ne escono piu' senza che ci siano avvisi o segnalazioni.
a questo punto t'attachi al tram, hai perso le email dei tuoi clienti da 
migliaia di euro e non hai una spiegazione, una giustificazione o una 
qualsiasi motivazione da usare per pararti il qlo.
la colpa puo' solo essere tua perche' per gestire una cosa standard che 
piu' standard non si puo' hai messo in piedi un accrocchio custom; la porta 
e' aperta, prendono la mira e ti ci sparano attraverso.
se prima di spararti ti chiedono di sistemare tutto il marchingegno, come 
fai a dare ai tuoi incazzatissimi clienti da migliaia di euro una vaga 
stima dei tempi di ripristino quando solo per capire dov'e' il problema 
devi inventarti il sistema di test (no, guardare i log non vale perche' il 
crash ha fatto in modo che siano inutili), dato che il 'limbo' delle email 
te lo sei inventato tu?
</estremizzazione>
quale era il vantaggio di reinventare la ruota?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 al cliente che non perderà posta metti solo il culo nelle pedate.
Fermi tutti, io non ho promesso niente a nessuno.
Ma per come son fatto io, se c'è la possibilità di ridurre al
minimo i problemi, cerco di adottare tale sistema.
Ripeto: mi sembrava sensato accettare posta diretta ai
miei server in caso di un MIO problema. Poi è ovvio che io
non devo risolvere problemi altrui, ma se la macchina che muore
è la mia ed ho modo di limitare i danni, mi sembrava sensato farlo.

 quale era il vantaggio di reinventare la ruota?
Ok ok, avete vinto :)

 problemi.
perdonami ma trovo che l'approccio commerciale sia sbagliato.
se il mailserver di @
pippo.com
 non ti rimanda un'email in segutio ad un 
errore 4 temporaneo, l'errore è di chi configura @
pippo.com
 NON IL TUO.
ed al cliente glielo spieghi, con gentilezza, che 
pippo.com
 è 
configurato a pene di segugio e che tu non puoi inventarti un nuovo 
protocollo smtp-gandalf solo perchè dall'altro capo del mondo 1 
mailserver su 100.000 fa questo difetto.
e torno a ripetere che l'utente di @
pippo.com
, come minimo, lo sa che il 
suo mailserver ogni tanto "si perde le email".
imho eh

 mailserver su 100.000 fa questo difetto.
Dipende con quali clienti hai a che fare.
Una cosa è certa: non posso dire al mio cliente di contattare il
gestore di 
pippo.com
Poi, se il gestore di 
pippo.com
 è $GrossissimaAzienda ed il mio
cliente è $EstremamenteIgnorante,
sfido a fargli capire che il problema non è mio ma di
$GrossissimaAziendaCheSullaCartaSembraIlDioInTerra
Se a questo aggiungi il fatto che il mio cliente non ha ricevuto mail
a seguito di un mio problema (perchè tutto
nasce da qui), lui fa 2+2.
$FornitorePiccolo con server guasto + $MailDa100KEuroPersa =
$FornitorePiccoloConProblemi = CambiareFornitore();
Ripeto, non è la prima volta che ci vien detto e non è la prima volta
che noi perdiamo nostri clienti per problemi altrui.

 nasce da qui), lui fa 2+2.
Capisco il problema, credimi.
Ma è meglio concentrarsi su come non far andare giù il sistema
principale e contemporaneamente su un'educazione del cliente
all'utilizzo e al funzionamento della posta elettronica, in special
modo se manifesta queste specifiche esigenze.
Butto qui un'idea magari sciocca: una zona dns con ttl bassissimo,
e puntamento del dominio su altro server in caso di problemi al server 
principale.


 principale.
in caso di caselle imap amplificheresti solo i problemi visto che i
clienti
non riuscirebbero ad aprire le mail pre-disservizio.
Dopo vallo a spiegare che abbiamo fatto una migrazione, possono
ricevere
solo le mail nuove ma non vedere le vecchie etc etc. Si fa prima a
dire
che c'è un guasto e che la posta ripartirà prima o poi piuttosto che
dover spiegare grossomodo una sorta di splitbrain.
Invece potrebbe essere interessante valutare una replica drdb via WAN.
Il flusso di dati replicato dovrebbe essere grossomodo analogo al
flusso
di dati in ingresso sugli MX (la posta deve transitare per forza di
cose
e per intero sugli MX). se gli MX facessero 1mbit, anche la replica
dovrebbe
aggirarsi attorno a tale valore.

 Invece potrebbe essere interessante valutare una replica drdb via WAN.
E quando va giù il link? Brrrr....


 devono aprire quella vecchia...
(e comunque dopo un'emergenza c'è sempre imapsync...)


 E quando va giù il link? Brrrr....
Tu come faresti?

 (e comunque dopo un'emergenza c'è sempre imapsync...)
Io pensavo di usare rsync, alla fine si tratta di banali
file di testo.
Il problema è la gestione dei 'doppioni'.
Se ho la stessa mail su ambo i server, sul secondario ha il flag di
letto, sul primario no (il server è morto ed il cliente ha letto la
mail sul secondario), quando sincronizzo, a chi do retta?
Sempre al secondario indiscriminatamente?

 Tu come faresti?
Boh, non ho mai pensato ad un link drbd su wan, mi vengono i
brividi solo all'idea.
Non mi viene in mente nulla per risolvere il problema che non includa
un mailstore altrove oppure un path secondario verso il mailstore
primario.


 primario.
Appunto, supponiamo di avere un mailstore altrove, come lo terresti in
sincronia
con il master?
Stavo anche pensando ad una porcata atomica: doppia scrittura su ambo
i server
tramite exim. La mail vien ricevuta ed exim la spara su ambo le
macchine anzichè
solo su uno.

 solo su uno.
Non conosco exim, ma potrebbe essere una soluzione.


 delle mailbox imap.
unison sembra fare tutto da solo e tutto in automatico.
Sogno o son desto?
Ho fatto questa prova sul mio pc (con banali file)
# touch dir1/file1
# unison --batch dir1/ dir2/
ha visto che su dir2 (vuota) mancava il file1 e l'ha copiato
# touch dir1/file2
# unison --batch dir1/ dir2/
ha visto che mancava il file2 in dir2 è l'ha copiato
# touch dir2/file3
# mv dir2/file2 dir2/file2.seen
# rm dir2/file1
# unison --batch dir1/ dir2/
in questo caso ho simulato il takeover del mailstorage slave.
più precisamente, è arrivata una nuova mail (touch file3),
l'utente ha modificato una mail già esistente leggendola
(e quindi cambiandone il nome del file aggiungendo il flag)
ed ha successiamente cancellato una mail ricevuta in precedenza.
unison ha:
 - copiato file3 in dir1 (la nuova mail ricevuta durante il down del
master)
 - copiato file2.seen in dir1 (la mail con flag letto)
 - cancellato da dir1 il file2 (la mail 'non letta')
 - rimosso da dir1 il file1 (la mail cancellata)
sembra funzionare. Dimentico qualche cosa?
Ho visto che unison non è molto felice di operare nel caso una delle
due directory
fosse completamente vuota perchè giustamente porterebbe ad una
cancellazione
in-toto della rispettiva controparte. (in teoria questa evenienza non
si dovrebbe
mai presentare, e comunque unison è configurabile)

 Sogno o son desto?
Non lo conosco, ma ricordo che serve per sincronizzare directory
quindi dovrebbe fare al caso tuo.
L'unico dubbio che ho: non è che in caso di file spostato via imap
unison faccia cancella/copia e invece imapsync sposti?
Su mailbox e messaggi grandi farebbe la differenza.


 Su mailbox e messaggi grandi farebbe la differenza.
Perchè ? Cosa cambia a livello di maildir?

 ha scritto nel
messaggio
news:0e40974c-3d85-48b4...@y31g2000vbp.googlegroups.com

Per l'imap nessuna differenza, Niente, a livello di banda e di
tempo necessario a sincronizzare, nonché di stress del server
imap, tanto.


 imap, tanto.
Ma perchè scusa?
Mi sfugge un passaggio, se lato client sposti una mail in un folder
differente, lui sul server lo sposta di directory.
Se io sposto manualmente la mail da una directory ad un altra, il
client
appena si collega sincronizza e sposta quella singola mail.

 ha scritto nel
messaggio
news:aadc931b-d40f-4b53...@e8g2000vbz.googlegroups.com

Appunto: il client sposta la stessa mail, non la ritrasferisce.
Faccio un esempio pratico: folder con dentro immaginone da 30
mb l'una. Un bel giorno l'utente decide di rinominare il folder da
'immagini' a 'foto'.
Un client imap AFAIK rinomina il suo folder locale e basta.
Non è che invece unison cancella 'immagini' e si trasferisce quei
due-tre gb di 'foto' perché è una nuova directory?


 due-tre gb di 'foto' perché è una nuova directory?
Boh, non so come funziona imap nel dettaglio.
In teoria il client dovrebbe basarsi sul nome del file della mail (ha
un nome specifico, non ricordo quale)
e non scaricare ciò che ha già indicizzato. In teoria, il client imap
se vede che un file XXXX è stato
spostato di directory dovrebbe aggiornare il proprio indice in locale
senza riscaricare il file.

 senza riscaricare il file.
Più che il nome file immagino sia il message-id.
Appunto per questo andrebbe fatta qualche prova per capire se
un syncer dedicato all'imap sia meglio di un qualunque software
di sincronia file.
