<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Rispondo quotando.<br>
<br>
</font>
<div class="moz-cite-prefix">Il 08/12/2013 17:22, nemesis ha
scritto:<br>
</div>
<blockquote cite="mid:62fbc7b7fe012e45c0e0482ac4e7b860@ninux.org"
type="cite">Sconsiglio di utilizzare un unico mail server con le
stesse credenziali per tutti.
<br>
Si può offrire un mailserver dedicato alle istanze di ninuxoo, con
un account per ogni istanza. Se si vuole tenere anonimi i
proprietari dell'istanza gli si può dare un nome tipo
<a class="moz-txt-link-abbreviated" href="mailto:istanza1@ninuxoo.ninux.org">istanza1@ninuxoo.ninux.org</a>
<br>
</blockquote>
Se il processo di creazione si potrebbe automatizzare sarebbe
perfetto.<br>
<br>
<blockquote cite="mid:62fbc7b7fe012e45c0e0482ac4e7b860@ninux.org"
type="cite">
Dalle esperienze che ho fatto, dico la mia, ci sono 3 opzioni:
<br>
<br>
1. mail server locale
<br>
vantaggi: non si dipende da un servizio esterno
<br>
svantaggi: configurazione necessaria ogni volta, rischio che le
email vengano contrassegnate come spam se non si configura bene,
in particolare se il mail server non è contrassegnato come
autoritativo per il dominio
<br>
<br>
2. mail server remoto autogestito
<br>
vantaggi: si configura tutto una volta sola, chi installa il
software deve solo inserire le credenziali
<br>
svantaggi: più o meno come il punto 1 ma col vantaggio che va
fatto una volta sola ed in più è un single point of failure
<br>
<br>
3. mail server remoto commerciale (gmail)
<br>
vantaggi: non si configura una beata minchia e tutto funziona
<br>
svantaggi: si dipende da un servizio esterno che quasi sicuramente
effettua il tracciamento del servizio .. amenochè non si utilizzi
autistici/inventati - single point of failure
<br>
<br>
Federico
<br>
</blockquote>
<br>
Scartando l'opzione gmail, questo era il motivo per cui mi sono
naturalmente rivolto alla lista.<br>
<br>
Un'altra opzione potrebbe essere quella di implementare dei proxy
mail, ai quali si chiede di "inviare la posta per conto di", in
pratica una richiesta di inoltro via email.<br>
Il messaggio conterrebbe un link con hash chilometrica
visualizzabile solo nel NAS del destinatario.<br>
Mi spiego meglio:<br>
<ul>
<li>A vuole collegare il nas di B alle ricerche, quindi gli invia
un messaggio con scritto "We belìn, accetta la connessione del
mio NAS, questa è la mia key PGP";</li>
<li>Questo messaggio viene cifrato con la RSA pubblica del nas B e
inviato al proxy mail che lo conserva per x tempo, spedisce
perciò una mail al proprietario di B con il link temporaneo.</li>
<li>Quindi il proprietario di B per visualizzare il messaggio in
codice clicca sul link che rimanda al suo NAS, il quale si
scarica il messaggio dal proxy mail e lo decifra con la chiave
rsa privata del suo nas.</li>
<li>A questo punto lui deciderà se collegare o meno il nas A, e il
processo può proseguire...</li>
</ul>
<p>In tutto questo passaggio di pubblico compare solo il fatto che
<a class="moz-txt-link-rfc2396E" href="mailto:pippo@example.com">"pippo@example.com"</a> ha un nas, che può essere collegato con altri
x nas.<br>
Niente di ché.<br>
Ricordo che grazie a mdns i nas potranno avere tranquillamente
indirizzi in dhcp, indirizzi che comunque non sono mai
visualizzati ma solo processati, in quanto variabili su script
lato server.<br>
Alla fine, l'unica cosa che veramente importa per il funzionamento
del tutto sono le chiavi RSA e i permessi manuali dei proprietari.<br>
</p>
<p>Ce stamo a complicà la vità?<br>
Secondo me con la scusa si otterrebbero pure una serie di server
mail ridondati, il ché non è un male...<br>
</p>
<p>Gubi<br>
</p>
<br>
</body>
</html>