Newsgroup: it.comp.os.linux.sys
Titolo: Servizi di posta e password con accentate

Salve a tutti.
Ho un server POP3s (ora Dovecot, fino a ieri qpopper e il problema era 
lo stesso) su una macchina Debian, configurato tramite PAM e Winbind per 
autenticare gli utenti sul database del dominio, gestito da Samba (tdbsam).
Il problema è che, se un utente ha una password contenente un carattere 
accentato, la password non viene accettata quando l'utente si connette 
al server POP3 con Thunderbird, Outlook o Outloox Express. Invece tutto 
funziona bene usando Mail di OSX (ma non è una questione di OS, con TB 
non funziona neanche da Mac). Non ho provato altri client.
Questo è un problema perché gli utenti della LAN ovviamente 
possono/devono cambiare di tanto in tanto la propria password del 
dominio, e le password con accentate funzionano senza problemi su Samba 
e Windows, quindi potrebbero benissimo sceglierne.
Non capisco da cosa possa dipendere. Se non funzionasse con nessun 
client, direi che è un "limite", magari stabilito per convenzione, dei 
server POP3, e mi rassegnerei ad istruire gli utenti in proposito. Ma 
con Mail funziona, quindi boh?
Ne sapete niente?
-- 
Ciao,
   Marco.

 con Mail funziona, quindi boh?
che charset usano i client?
controlla quello prima di impazzire

 con Mail funziona, quindi boh?
ma Mail e' avanti.
a parte gli scherzi. Io istruirei gli utonti a non usare caratteri
strani, quindi solo a-zA-Z0-9 e al limite - e _ (ma non lo spazio).
gia' io evito pure w,y,x e z, che cambiano abbastanza spesso nei
layout delle tastiere. in modo che se si incasina il layout non passo
mezz'ora a provare tutte le combinazioni possibili con x,y,z,w. a
questa e' preferenza personale, mentre la prima che ti ho detto e'
pratica buona e giusta.
Ciao Jack

 strani, quindi solo a-zA-Z0-9 e al limite - e _ (ma non lo spazio).
Stiamo parlando di password! Più caratteri strani usano *meglio* è.

 Stiamo parlando di password! Piů caratteri strani usano *meglio* č.
Sě, purchč funzionino... :-\
Il problema č che gli stessi caratteri, quando non comuni a tutte le
codifiche, sono rappresentati da codici diversi...
Quindi bene i caratteri "strani", ma con un minimo di saggezza... :-P
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGZCPH8THo01J+SBERAujwAJsE/rJsxSokFo3shWFwlbcUPOUTOgCfYorq
arJRuIgxWSX54fRtlXQNzZk=
=yggk
-----END PGP SIGNATURE-----

 che charset usano i client?
Uhm... non stiamo parlando di charset usato per la codifica delle email 
inviate o roba simile, stiamo parlando solo del modo in cui vengono 
comunicate le password al server, e in questo caso come diavolo faccio a 
capire quale codifica usa il client? Non mi sembra di aver mai visto 
opzioni al riguardo. E non dipende dalla codifica del SO perché, come 
dicevo, sullo stesso Mac funziona Mail, ma non TB.
Fra parentesi, per capire se era una cosa relativa solo al mio server 
volevo provare con un account di posta dei soliti provider free, ma né 
Libero, né Tiscali, né Gmail permettono l'uso delle accentate nelle 
password :-P.
Forse dovrò attivare il POP3 in chiaro e sniffare un po', ma avrei 
preferito evitare.
-- 
Ciao,
   Marco.

 strani, quindi solo a-zA-Z0-9 e al limite - e _ (ma non lo spazio).
Il fatto è che a me non piace imporre limiti se esiste la possibilità di 
risolvere in altro modo... voglio dire: se esiste un modo per usare le 
password con accentate a me piacerebbe usarlo e lasciare più libertà 
agli utenti nella scelta delle password, piuttosto che dire direttamente 
di non usare le accentate solo perché *IO* non so come farle accettare 
al server. Almeno un tentativo vorrei farlo.
Comunque, in caso, l'ideale sarebbe imporre la restrizione direttamente 
da Samba, in modo che al cambio password non vengano accettati caratteri 
"pericolosi"; altrimenti di tanto in tanto mi arriva l'utente che non 
riesce a scaricare la posta perché ha usato uno di quei caratteri. Se 
non c'è altra soluzione, dovrò studiare questa via.
-- 
Ciao,
   Marco.

 password :-P.
Ci sara' un motivo? <vbeg>
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Ci sara' un motivo? <vbeg>
ROTFL
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGZCmH8THo01J+SBERAnTMAKCLQHBKjfRRRC6ZCF9DPKOu1XrFowCdE+uN
/3YbA8yb7DQlNbV4hNJTL/Y=
=JaLD
-----END PGP SIGNATURE-----

 password con accentate a me piacerebbe usarlo e lasciare più libertà 
E chi ti da' la certezza che al momento del login al dominio la tastiera
sia codificata con il charset italiano?
Questo e' un sintomo di _FALSA_ democrazia redmondiana.
Nomi di file, nomi utenti, password con caratteri nazionali NON
dovrebbero essere accettati.
Altrimenti ti trovi come qui da me, che la collega russa scrive i nomi
di file in cirillico, perche' la sua macchina lo consente, ma il file
server non sa come gestirli per i backup, e non ho nessuna intenzione
di installare il pacchetto multilingue sul server di dominio.


 sia codificata con il charset italiano?
Forse il fatto che conosco personalmente tutti gli utenti e so che sono 
tutti italiani e che usano la tastiera italiana e che le mani sui client 
come amministratore le metto solo io?
-- 
Ciao,
   Marco.



Non basta. Devi uniformare anche il charset. Windows non usa iso-8859-1,
ma windows-1252 per la lingua italiana. Quasi tutti i caratteri sono
uguali, ma ce ne sono di diversi.
Se riesci a uniformare tutto (tutti i client, tutti i software che girano
sui client e che devono comunicare quella password, e il programma di
autenticazione sul server), lo puoi fare. A quel punto per lui sono solo
bit, non gliene frega niente se e` una è o una §.
Bye.

 Ci sara' un motivo? <vbeg>
Certo, ma se permetti ci sono ottime possibilità che un grosso ISP con 
milioni di utenti abbia motivi diversi dal banale "mi incasino con i 
charset". Il primo che mi viene in mente: evitare chiamate al call 
center solo perché qualcuno ha scelto "gattofrùfrù" come password ma poi 
andando a memoria scrive "gattofrufru" o "gattofru'fru'". Problemi 
praticamente inesistenti in una realtà di 15 utenti con istruzione di 
buon livello.
Se poi qui arriva qualcuno di Gmail e mi dice "sì è vero, abbiamo fatto 
questa scelta perché con i charset è un casino", allora siamo d'accordo. 
Ma fino ad allora...
-- 
Ciao,
   Marco.

 bit, non gliene frega niente se e` una è o una §.
Faccio notare che Windows (2000 e XP, perché questi mi interessano) per 
l'autenticazione e l'accesso ai file usa UTF-8. E sul server Samba mi 
basta impostare il sistema in UTF-8 e usare "unix charset = UTF8" nel 
smb.conf per far funzionare tutto senza problemi di accentate nelle 
password e nei nomi dei file (neanche nei backup lato Linux). Quindi non 
è che questo genere di cose siano impossibili.
Ora, il problema sembra essere nei client: forse Mail invia la password 
in UTF-8, mentre Outlook, OE e TB non lo fanno? Può darsi... snifferò, 
se non ci sono altre idee.
Grazie.
-- 
Ciao,
   Marco.

 se non ci sono altre idee.
Smandruppare nei parametri di configurazione per TB potrebbe essere un
primo abbozzo: ci si trova un po' di roba interessante, e fare qualche
tentativo (magari su una sandbox) potrebbe portare a qualche risultato.
Idem per OE nel registro di sistema, al limite...
E la sniffata male non fa...
Però francamente devi proprio volerlo... :-D
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGZDKr8THo01J+SBERAk1OAJ0cxxnnKjTlBAmfNZN3xH4H0jo5HwCgo30t
JVafxHV0b5x5CAbGjK4iQkI=
=vRS9
-----END PGP SIGNATURE-----

 capire quale codifica usa il client?
tcpdump?

 Però francamente devi proprio volerlo... :-D
Se l'unica soluzione è modificare chiavi di registro di Windows lascio 
perdere :-P ;).
-- 
Ciao,
   Marco.

 tcpdump?
Appunto, come dicevo, proverò a sniffare un po' di traffico, anche sui 
client di modi ne ho... non è certo il massimo smazzarsi un po' di dump 
ma un tentativo si può fare. Solo che (lo avevo scritto) al momento sto 
usando pop3s, devo attivare il pop3 in chiaro altrimenti non vedo un 
tubo :).
-- 
Ciao,
   Marco.

 capire quale codifica usa il client?
Non puoi a quello stadio. Quindi a priori non puoi sapere come verranno
codificate le accentate. Ergo, non puoi permetterne l'uso.
Luca
-- 
Regole per la felicit?:
1. Sii soddisfatto di quello che hai.
2. Assicurati di avere tutto.

Marco De Vitis ha scritto:

http://wiki.wireshark.org/SSL

 di installare il pacchetto multilingue sul server di dominio.
Ecco, questo mi sconcerta. Al programma di backup non deve importare
*nulla* dei nomi dei file! Perché mai dovrebbe avere problemi con i
caratteri russi?
Luca
[1] Parliamo di Linux o di un altro unix sano, eh ;)
-- 
Porc i' mond che cio' sott i piedi!
V. Catozzo

 
http://wiki.wireshark.org/SSL
Interessante, non sapevo.
-- 
Ciao,
   Marco.

 controlla quello prima di impazzire
E io, per l'appunto, gli ho risposto: come diavolo faccio, visto che nei 
client non esistono opzioni per il charset da usare durante 
l'autenticazione?
Il "controlla quello prima di impazzire" presuppone l'esistenza di un 
metodo facile, ma non mi viene in mente niente di meglio che sniffare il 
traffico o smanettare con parametri esotici come suggeriva Skull, e non 
li definirei metodi facili.
Quello che mi scrivi tu non è molto diverso da quello che già pensavo 
io... quindi, chiediamo insieme: Aioe, cosa intendevi dire? :)
-- 
Ciao,
   Marco.

 quindi, chiediamo insieme: Aioe, cosa intendevi dire?
le vocali accentate sono un problema /storico/ (in alcune lingue, ad
esempio quelle scandinave, i caratteri aggiunti sono talmente tanti che è
abbastanza difficile immaginare una parola non banale che ne sia priva).
Tutti i charset ASCII condividono i primi 128 caratteri: i primi 32 (da 0
a 31) contengono caratteri di controllo, poi quelli stampabili a schermo,
infine altri 128 caratteri *non* standard che variano a seconda del
charset.
Questo significa che il carattere 'T' avrà *sempre* il valore 84 nella
tavola ASCII indipendentemente dalla codifica scelta.
Il carattere 'è' avrà il valore 232 nella codifica italiana, 139 in quella
islandese.
Come regola generale, è cosa poco furba ammettere le vocali accentate nelle
password. In ogni caso, il tuo problema probabilmente è che il server ed
il client utilizzano tavole ASCII diverse. 
in TB è /sicuramente/ possibile modificare il charset (come non saprei ma
sono sicuro avendo visto installazioni LINUX in inglese con TB in russo)
poi, per esperienza vissuta, ho avuto anni addietro lo stesso problema (me
ne accorsi con tcpdump) e l'ho risolto vietando le accentate

 le vocali accentate sono un problema /storico/ (in alcune lingue, ad
[...]
Sì, ok, grazie per il ripasso sui charset ma conosco la questione :).
Io stavo chiedendo: cosa intendevi dire con "controlla che charset usano 
i client"? Ti riferivi a qualche opzione dei client o altro?
Comunque ormai penso che intendessi proprio suggerire di usare tcpdump e 
simili.
E infatti l'ho fatto ora, usando Eavesdrop su Mac e provando Mail e TB, 
e sigh, in effetti Mail invia la password in UTF-8, e TB in ISO-Latin-1.
Poiché l'unica soluzione è operare lato client, e a me decisamente non 
va di impazzire con i vari Outlook, mi adeguerò alla massa: niente 
caratteri strani nelle password!
Grazie a tutti per la discussione.
-- 
Ciao,
   Marco.

 [1] Parliamo di Linux o di un altro unix sano, eh ;)
Eh, purtroppo no, nel mio esempio, non parliamo di linux.


 in effetti Mail invia la password in UTF-8, e TB in ISO-Latin-1.
cambia il charset del sistema operativo (poi dovrebbe funzionare)
in debian/ubuntu 
$ dpkg-reconfigure locales



Uh? Intendi sul client o sul server? E che charset dovrei impostare, 
secondo te?
Sul server non posso toccarlo, è già UTF-8 e va bene così per il buon 
funzionamento di Samba.
Sui client, parliamo di Win2000/XP, ma parlavi di questi?
-- 
Ciao,
   Marco.

Mandi! Marco De Vitis
  In chel d? si favelave...
MDV> Ne sapete niente?
Policy aziendale interna impedisce le password con accentate, ed
esattamente per questo motivo.
Uso samba+ldap, e sinceramente avevo dato la colpa a ldap. ma mi pare
chiaro dai tuoi esperimenti che invece la colpa ? dell'applicazione che
non usa un charset definito per inviare la password.
Se qualcuno viene a capo della questione, sono ben contento...
-- 
  If you want to travel around the world and be invited to speak at a lot
  of different places, just write a Unix operating system.
						(Linus Torvalds)

 Sui client, parliamo di Win2000/XP, ma parlavi di questi?
no
per UNIX (client) il charset giusto è iso-8859-15
per WIN dovrebbe essere windows-1252 o ISO-8859-1



Perdonami, ma continuo a non capire.
Puoi essere un po' meno sintetico, per favore?
Non afferro cosa mi stai suggerendo di fare: cambiare il charset nel 
client di posta? Oppure cambiarlo nel SO del computer client?
Nel primo caso, che mi sembra il più probabile, stai tentando di 
suggerirmi un metodo comodo, tenendo conto che gli utenti usano 
principalmente Outlook e OE?
A me non viene in mente nessuna soluzione "comoda", ma se tu ne hai in 
mente una, ti prego, parla! :)
Grazie.
-- 
Ciao,
   Marco.

 Puoi essere un po' meno sintetico, per favore?
Non sono lo stesso di prima, però a me viene in mente questa opzione di 
configurazione per tb che dovrebbe fare al caso tuo
network.standard-url.encode-utf8
Se ricordo bene dovrebbe cambiare anche la codifica delle password.
-- 
Bio82 --> bio(underscore)82(underscore)mail-nntp(at)yahoo(dot)it