9Prerequisiti necessari;

Transcript

1

2 9Prerequisiti necessari;./ :Cosa è LDAP? Backend, file LDIF, ObjectClass e Attributi; :Cenni su installazione e configurazione di OpenLDAP; :Configurazione lato server: configurare Slapd e l'infrastruttura di base; :Configurazione lato client: migrazione del NSS e configurazione PAM; :Configurazione lato client: configurare SAMBA per usare LDAP; :Tools utili per l'amministratore: LAM, phpldapadmin; :Conclusione e altri scenari d'uso; :Questions & Answers.

3 /6124. :Sapersi muovere all'interno di un sistema di tipo UNIX :) :Saper generae certificati di openssl; :Conoscenza dei comandi della consolle; :Conoscenza delle procedure di compilazione dei sorgenti e loro installazione nel sistema; :Conoscenza basilare del server SAMBA (versione 3), del N.I.S. e di P.A.M.

4 LDAP == Lightweight Directory Access Protocol E' un protocollo che permette di accedere ad un servizio di directory (inteso come elenco di dati), simile ad una rubrica telefonica, ma con contenuti eterogenei. LDAP parte dal modello di dati stabiliti dallo standard X.500 (questo prevede sia un modello dei dati che un protocollo di accesso), da cui eredita solo il modello dati, ma implementa un protocollo di accesso semplificato basato sul TCP/IP, che è stato standardizzato dall'rfc Un elenco (o directory) è simile ad un database, ma tende a contenere informazioni più descrittive e basate su attributi. Un elenco LDAP è generalmente concepito per fornire una responsività elevata alle richieste di lettura e ricerca, può essere facilmente replicato, e supporta la distribuzione del carico. Inoltre il protocollo considera come accettabili inconsistenze temporanee delle informazioni. Il server di OpenLDAP si chiama slapd.

5 2/ 6 Slapd ha la possibilità di usare diversi tipi di database come backend in cui memorizzare tutte le informazioni necessarie. Meritano di essere citati almeno i seguenti: :BDB (Berkley Database): è quello di default, è un backend per database transazionali con grandi prestazioni e utilizza Sleepycat Berkeley DB 4; :LDBM (Lightweight DBM ): questo backend può utilizzare sia il Berkeley DB che GDBM; :SHELL: una interfaccia backend per script di shell; :PASSWD: una semplice interfaccia backend per il file passwd(5) Il backend transazionale BDB è progettato per autorizzare accessi multiutente (anche concorrenti ad un database con qualsiasi mix di operazioni di lettura/scrittura). Questo genere di backend è particolarmente utilizzato in situazioni che richiedono: :Transazioni: permette operazioni atomiche; :Disaster Recovery: permette di recuperare i dati in seguito a crash di sistema e/o crash dell'hardware, senza perdere le transazioni effettuate.

6 2/ In questo seminario si assume l'utilizzo del backend BDB. Per importare ed esportare directory tra i vari server LDAP-based, o per descrivere una serie di cambiamenti da applicare ad un directory, si utilizza un formato conosciuto come LDIF, che è un acronimo per LDAP Data Interchange Format. Un file LDIF memorizza informazioni in una gerarchia di entry object-oriented. Tutti i pacchetti LDAP dispongono di utility (generalmente sotto consolle) che convertono i file LDIF nel formato BDB. Un tipico file LDIF somiglia al seguente: dn: o=uzeda, c=com o: uzeda objectclass: organization dn: cn=angelo Failla, o=uzeda, c=com cn=angelo Failla sn=failla mail: afailla@uzeda.com objectclass: person o=uzeda, c=com cn= Angelo Failla, o=uzeda, c=com

7 / 52 1 Come si può vedere dall'esempio ogni entry è identificata univocamente da un distinguished name (abbreviato DN), un DN è formato dal nome dell'entry seguito a un path formato da più nomi che rintraccia il posizionamento dell'entry all'interno della struttura ad albero rovesciato che compone la struttura dati del server LDAP (si pensi alla classica rappresentazione di un filesystem). In LDAP, un ObjectClass definisce un set di attributi che possono essere usati per definire un entry. Tutti i pacchetti LDAP forniscono di default almeno i seguenti objectclass: :Groups: un particolare oggetto atto a rappresentare liste disordinate di oggetti singoli o di gruppi di oggetti; :Locations: un oggetto atto a rappresentare nome di nazioni e loro descrizione; :Organizations: atto a rappresentare organizzazioni, aziende, etc :Person: contiene gli attributi utili per schedare una persona all'interno di una directory.

8 . / E' possibile installare OpenLDAP prelevando i sorgenti in formato tar.gz direttamente dal sito ( TODO: controllare link), oppure utilizzando i pacchetti creati ad hoc per la vostra distribuzione GNU/Linux, BSD, Darwin, etc etc. Normalmente i pacchetti precompilati sono più rapidi da installare e/o mantenere, e sono già stati compilati per supportare molti backend, hanno già il supporto TLS/SSL compilato. Ad es. con una distribuzione Debian è sufficiente digitare il comando apt-get install slapd ldap-utils. Per le istruzioni inerenti l'installazione si rimanda alla documentazione ufficiale ed agli HOWTO elencati nella bibliografia di queste slide. Alla fine del processo di installazione tutti i binari, i file di configurazioni, gli schemi di default, etc. saranno installati in opportune directory del filesystem. Occorre prestare molta attenzione alla directory /etc/ldap/, in cui è presente il file di configurazione di slapd (slapd.conf)

9 /0 0. Vediamo adesso un esempio pratico di configurazione del server slapd, il suo file di configurazione si trova in /etc/ldap/slapd.conf (questo su debian, installando il pacchetto con apt, per le installazioni da sorgente il file dovrebbe trovarsi su /usr/local/etc/ldap/slapd.conf o in un altra directory, a seconda dell'opzione - -prefix fornita allo script configure). Il file di configurazione è strutturato in due parti: prima, in questa parte vengono definiti gli schemi da utilizzare, le impostazioni di protocollo, l'algoritmo :Definizioni Globali: %)"%+"",')%"*%"+ % %nellla di default da utilizzare per memorizzare le password, il livello di verbosity, la posizione del pid file, la definizioni dei tipi di backend da utilizzare, etc; :Direttive dei backend (leggi database): queste sezioni iniziano normalmente con la direttiva database <nome_backend>, e riguardano la configurazione dei singoli database.

10 1523 /0 # Global Directives: # Features to permit allow bind_v2 # Schema and objectclass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/qmail.schema Definizione schemi # Schema check allows for forcing entries to match schemas for their objectclasses's schemacheck on password-hash {CRYPT} # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 256 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb # Backend specific directives apply to this # backend until another 'backend' directive # occurs backend #backend #backend bdb <other backen> <another one>

11 1523 / ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb # The base of your directory in database #1 suffix "dc=miodominio,dc=mio_dominio_primolivello" # For SSL/TSL authentication TLSCertificateFile /etc/ssl/certs/ldapcert.pem TLSCertificateKeyFile /etc/ssl/certs/ldapkey.pem TLSCipherSuite HIGH TLSCACertificateFile /etc/ssl/certs/cacert.pem #TLSVerifyClient 1 rootdn "cn=admin,dc=miodomino,dc=mio_dominio_primolivello" rootpw {CRYPT}rkoPoUxb6iKN6 # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectclass eq uid # Save the time that the entry gets modified, for database #1 lastmod on

12 1523 / # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userpassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userpassword by dn="cn=admin,dc=miodominio,dc=mio_dominio_primolivello" write by anonymous auth by self write by * none access to dn="ou=rubrica,dc=miodominio,dc=mio_dominio_primolivello" by dn="cn=admin_rubrica,dc=miodominio,dc=mio_dominio_primolivello" write by dn= authuser,dc=miodominio,dc=mio_dominio_primolivello" read by * none Definizione ACL access to * by dn="cn=admin,dc=agencyuzeda,dc=local" write by dn="cn=authuser,dc=agencyuzeda,dc=local" read

13 Come potete leggere nel commento qui sotto, normalmente slapd parte facendo la listen solo sulla porta tcp 389 che corrisponde al servizio ldap (no ssl), per fare in mo do che il vostro server ldap ascolti anche alla porta ldaps (636) occorre inserire la uri ldaps:// all'interno dello script di avvio di slapd (attenzione! La posizione delle righe qui sotto può variare da distribuzione a distribuzione, per es. Sotto debian si trova su /etc/default/slapd, in altre distribuzioni SystemV potrebbe trovarsi in /etc/init.d/slapd). # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///" Nota bene: se il vostro server ldap deve esclusivamente essere utilizzato via ssl dai client della rete conviene impostare questa voce ai valori ldap:// ldaps://, questo impedisce le connessioni in chiaro da tutti gli host della rete eccetto che dall'interfaccia di loopback.

14 . /./ Adesso che il nostro file di configurazione è stato creato, il passo successivo è la migrazione del NSS. Il NSS è una interfaccia che permette di demandare, a delle librerie esterne, l'accesso a informazioni riguardanti l'ambiente locale (come ad es. account utenti, password, gruppi, hosts, corrispondenze tra i nomi delle macchine e i numeri di porta). Questo tipo di interfaccia viene fornita dalle libc GNU. Il grande vantaggio del NSS è che diventa possibile definire in maniera modulare ed estensibile il tipo di supporto da utilizzare per le varie classi di informazioni sopra descritte. Queste definizioni vengono dichiarate all'interno del file /etc/nsswitch.conf. Il formato prevede una riga per ogni classe di informazione, nella prima colonna viene specificato il tipo di classe (di solito le keyword sono hosts, group, passwd, aliases, protocols, etc) seguito dal carattere ' : ', poi sono possibili valori che indicano dove reperire le informazioni per quelle classi, questi valori sono identificati da parole chiavi come ldap, file, dns, db, nis, con la possibilità di specificare l'ordine in cui questi supporti vengono presi in considerazione. Un esempio di file nella prossima slide:

15 / 1. / /0 # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files ldap group: files ldap shadow: files ldap hosts: files dns ldap networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis

16 /0 Per usufruire del supporto LDAP è necessario installare il pacchetto libnss-ldap (sotto debian), bisogna poi editare il file /etc/libnss-ldap.conf, come il file sottostante: base dc=vostrodominio,dc=dominio_primario uri ldaps://vostroserver.vostrodominio.dominio_primario/ ldap_version 3 binddn cn=authuser,dc=vostrodominio,dc=dominio_primario bindpw <password_segreta> rootbinddn cn=admin,dc=vostrodominio,dc=dominio_primario scope one nss_base_passwd ou=people,dc=agencyuzeda,dc=local?one nss_base_shadow ou=people,dc=agencyuzeda,dc=local?one nss_base_group ou=group,dc=agencyuzeda,dc=local?one nss_base_hosts ou=hosts,dc=agencyuzeda,dc=local?one ssl start_tls ssl on Alcune avvertenze: E' opportuno settare i permessi di questo file a 600 in quanto alcune password sono specificate in chiaro... La password per il binding al server LDAP da account root è memorizzata nel file /etc/ldap.secret, anch'esso con permessi 600.

17 6 / / / / Adesso dobbiamo migrare le informazioni presenti in /etc/group, /etc/passwd ed /etc/shadow sul nostro server ldap. Per fare ciò ci vengono in aiuto una collezione di tool scritti in perl presenti nel pacchetti migrationtools ( Prima di procedere occorre editare il file /etc/migrationtools/migrate_common.ph, modificando le righe sottostanti: $DEFAULT_MAIL_DOMAIN = "agencyuzeda.local"; $DEFAULT_BASE = "dc=agencyuzeda,dc=local"; occorrerà successivamente chiamare il comando migrate_base.pl > base.ldif, questo comando genera un file ldif contenente l'infrastruttura di base dell'albero del server LDAP. Il file base.ldif conterrà ad es. Una sezione come questa: dn: ou=hosts,dc=gnulinux,dc=it ou: Hosts objectclass: top objectclass: organizationalunit

18 6 / / / / Normalmente conviene sempre editare il file base.ldif ed eliminare le entry non necessarie (ad es. Tutte le entry relative al NIS). Dopodichè occorrerà dare il comando: ldapadd -x -D"cn=admin,dc=gnulinux,dc=it" -W -f base.ldif -x dice al comando di utilizzare la simple authentication -D indica con quale dn si deve fare il lobin -W indica al comando di chiedere la password -f specifica al comando che deve prendere le informazioni da aggiungere dal file base.ldif Una volta aggiunta la struttura base occorre migrare il file delle password, lo shadow e i gruppi, questo si fa esattamente come fatto per la infrastruttura di base, utilizzando i vari comandi di migrationtools (migrate_passwd, migrate_groups, etc), veranno creati i vari file ldiff che dovranno essere aggiunti all'albero con il comando ldapadd.

19 6 6136/../ /2.0 6 Per quanto riguarda l'autenticazione conviene creare un utente dedicato sull'elenco, da tenere separato dall'utente utilizzato come amministratore dell'elenco. Questo permette di avere un maggiore controllo su quanto i vari client potranno fare, limitando l'accesso alle sole informazioni che è possibile prelevare (ricordate le ACL?). Per questo conviene creare un file ldif fatto pressapoco così: dn: cn=authuser,dc=vostro_dominio,dc=dominio_primo_livello cn: authuser sn: authuser objectclass: top objectclass: person userpassword: {CRYPT}D9/AZpu.opt3o Il campo userpassword può essere ottenuto col comando, seguente specificando l'hash. maciste:~# slappasswd -h {CRYPT} New password: Re-enter new password: {CRYPT}D9/AZpu.opt3o

20 / A questo punto, se è stato tutto fatto correttamente, dovremmo poter estrarre informazioni su gruppi, utenti, shadow password, da ogni macchina della rete abilitata a usare ldap (cioè con il file libnss-ldap corettamente configurato). Per verificare usiamo il comando getent. macchina_client# getent passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync pallotron:x:1000:1000:angelo Michele Failla:/home/pallotron:/bin/bash gmaggio:x:1001:1000:gabriele Maggio:/home/gmaggio:/bin/bash administrator:x:0:1000:account admin win:/home/administrator:/bin/bash segreteria:x:1002:1000:account di prova:/home/segreteria:/bin/bash mgrasso:x:1003:1000:maurizio Grasso:/home/mgrasso:/bin/bash Verifichiamo poi group e shadow nella medesima maniera.

21 5 23 / Ora che il NSS sta correttamente funzionando occorre configurare l'infrastruttura PAM delle nostre macchine client per permettere a servizi come login, passwd, ssh, etc di poter autenticare e cambiare le password. Prima di far questo occorre assicurarsi che le macchine client abbiano l'infrastruttura pam in grado di usare ldap, questo si verifica vedendo se in / lib/security esiste il relativo modulo pam_ldap.so, se questo file non è presente occorre installare questo modulo (sotto debian apt-get install libpam-ldap). Per far ciò occorre editare il file /etc/ldap/ldap.conf e i file dentro /etc/pam.d. Ecco il file ldap.conf: rootbinddn cn=admin,dc=vostro_dominio,dc=dominio_primo_livello binddn cn=authuser,dc=vostro_dominio,dc=dominio_primo_livello bindpw <pass_segreta> ssl start_tls ssl on suffix dc=vostro_dominio, dc=dominio_primo_livello uri ldaps://server_ldap.vostro_dominio.dominio_primo_livello/ ldap_version 3 pam_filter objectclass=posixaccount pam_login_attribute uid pam_password md5 pam_member_attribute memberuid pam_template_login_attribut e uid pam_password crypt

22 / Cosa ben diversa è invece la directory pam.d. All'interno di questa directory sono contenuti i vari file di configurazione per ogni servizio, che modificano il loro comportamento in fase di autenticazione. maciste:/etc/pam.d# ls BACKUP cupsys other sudo chfn gdm other.dpkg-old suexec-apache chsh gdm-autologin passwd suexec-apache-ssl common-account kcheckpass passwd.dpkg-old xdm common-auth kdm ppp xscreensaver common-password kscreensaver samba common-session login ssh cron login.dpkg-old su Sotto debian basta toccare i file common*, in quanto questi vengono poi inclusi da tutti gli altri.

23 common-account account sufficient pam_ldap.so account required pam_unix.so 52.46/ common-auth (definisce gli schemi di autenticazione da usare nel sistema) auth sufficient pam_ldap.so use_first_pass auth required pam_unix.so common-password (definisce i moduli che permettono di cambiare la password) password sufficient pam_ldap.so password sufficient pam_unix.so nullok use_authtok md5 shadow use_first_pass password required pam_deny.so common-session (definisce i moduli che definiscono i task da compiere all'inizio e alla fine di una sessione) session required pam_mkhomedir.so skel=/etc/skel/ session sufficient pam_ldap.so session required pam_unix.so

24 Adesso vedremo come configurare un server SAMBA (versione 3) come PDC utilizzando ldap come backend per utenti e gruppi. Prima di passare effettivamente alla sua configurazione prepariamo l'elenco ldap. Abbiamo bisogno di: 1) includere lo schema di samba3 nel file di configurazione di slapd 2) sono necessari alcuni dn di base per far joinare le workstation al dominio. Le entry di base dell'elenco sono nobody, administrator. Creiamoci il nostro file ldiff con queste entry e poi aggiungiamole con il comando ldapadd.

25 dn: uid=administrator, dc=vostro_dominio, dc=dominio_primo_livello objectclass: account objectclass: sambasamaccount objectclass: posixaccount gecos: Samba Admin homedirectory: / loginshell: /dev/null uidnumber: 506 gidnumber: 0 uid: Administrator sambapwdlastset: sambalogontime: 0 sambalogofftime: 0 sambakickofftime: 0 sambapwdcanchange: 0 sambapwdmustchange: 0 displayname: Administrator cn: Administrator sambahomepath: \\%N\ sambahomedrive: U: sambaprofilepath: \\%N\\profile Nota: i path sono relativi alla configurazione del server samba, i campi delle password sono settati random, tanto dopo potrà essere cambiato con il comando smbpasswd. Occorre sostituire S con il SID ottenuto con il comando net getlocalsid sambasid: S sambaprimarygroupsid: S sambalmpassword: 7DDDDD60A3BD71AAAAA65F DD sambantpassword: DD60A3BD71AAAAA82F4CC21AA sambaacctflags: [UX ]

26 dn: uid=nobody, dc=unav, dc=es objectclass: account objectclass: sambasamaccount objectclass: posixaccount uid: nobody sambapwdlastset: sambalogontime: 0 sambalogofftime: sambakickofftime: sambapwdcanchange: 0 sambapwdmustchange: displayname: Nobody cn: Nobody sambasid: S sambaprimarygroupsid: S gecos: Nobody or Guest homedirectory: / loginshell: /dev/null uidnumber: 99 gidnumber: 99 sambaacctflags: [UX ]

27 /0 [global] workgroup = NOME_DOMINIO security = user netbios name = maciste obey pam restrictions = Yes pam password change = yes passdb backend = tdbsam ldapsam:ldap://localhost/ syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 name resolve order = lmhosts host wins bcast logon script = script_logon.bat logon path = \\maciste\profiles logon drive = U: logon home = \\maciste\%u domain logons = Yes preferred master = Yes local master = Yes domain master = Yes dns proxy = No wins support = Yes idmap uid = idmap gid = winbind separator = '\' winbind use default domain = Yes winbind enum users = yes winbind enum groups = yes

28 /0 ldap suffix = dc=agencyuzeda, dc=local ldap machine suffix = ou=hosts,dc=agencyuzeda, dc=local ldap user suffix = ou=people,dc=agencyuzeda, dc=local ldap group suffix = ou=group, dc=agencyuzeda, dc=local ldap idmap suffix = dc=agencyuzeda, dc=local ldap admin dn = cn=admin,dc=agencyuzeda,dc=local [homes] comment = Home Directories read only = No create mask = 0755 directory mask = 0755 browseable = No [netlogon] comment = Network Logon Service path = /var/samba/netlogon write list guest ok = Yes share modes = No [profiles] path = /var/samba/profiles read only = No create mask = 0600 directory mask = 0700

29 / Per cambiare la password dell'account Administrator utilizziamo il comando smbpasswd. smbpasswd -w <nostra_pass_segreta> Dopo questo comando la password sarà modificata e possiamo joinare le nostre macchine al dominio. Per fare ciò occorre inserire un entry per ogni macchine all'interno dell'elenco ou=hosts, dc=vostrodominio, dc=dominio_pimo_livello con il comando: smbpasswd -a -m <machine_name>$ Dopodichè, su ogni macchina windows da joinare occorrerà recarsi sul pannello di controllo -> Proprietà di sistema -> Nome computer -> Cambio Dominio. Verrà richiesto l'utente con cui joinare, occorrerà inserire la stringa VOSTRODOMINIO\Administrator ed inserire la password settata con smbpasswd -w (TODO: mettere screenshot)

30 /

31 Se la vostra è un rete etorogenea, fatta di macchine Linux e Windows, che accedono a directory condivise da un fileserver (le macchine windows con samba, quelle linux ad es. Tramite NFS o altri filesystem di rete), può sorgere la esigenza di mappare i gruppi posix con quelli di windows, e viceversa, in modo da non avere noie e problemi con i permessi. Questo si realizza con la utility net messa a disposizione dal comando samba (dopo aver aggiunto il gruppo samba al vostro elenco ldap) maciste:~# net groupmap list System Operators (S ) -> manager grafici (S ) -> grafici [snip] Domain Admins (S ) -> manager Domain Users (S ) -> users Power Users (S ) -> manager Print Operators (S ) -> manager Administrators (S ) -> manager Account Operators (S ) -> manager Users (S ) -> users programmatori (S ) -> programmatori La mappatura si realizza con il comando: net groupmap add unixgroup=<nome_gruppo> type=domain ntgroup=<gruppo win>

32 E' irragionevole gestire un dominio con i soli comandi di shell!! / Per questo vengono in aiuto delle interfaccie, alcune binarie altre direttamente web, che permettono di gestire gli account, i gruppi, e le macchine. LAM è uno di questi. La cosa più interessante di questo tool è che permette di gestire sia gli account posix che quelli samba in modo integrato. Permette di impostare le password, gli expire, i path dei profili windows e delle home unix, di parametrizzare gli script bat di logon per ogni utente. Ha anche la possibilità di definire dei template di profilo. PhpLDAPadmin è invece un'applicativo php per l'accesso generale alla struttura dell'elenco, con esso è possibile browsare e modificare l'elenco in ogni singolo punto dell'albero, aggiungere attributi e classi ad un entry (io lo uso per gestire il dominio di posta con qmail + ldap). Di seguito degli screenshot.

33

34

35 / Aggiungendo gli opportuni schemi in slapd.conf e espandendo le entry di ogni singolo utente con gli attributi di questi schemi è possibile utilizzare un elenco ldap per autenticare un utente su innumervoli servizi, tra cui: :Apache (autenticazione HTTP); :MySQL; :Squid (Proxy WEB); :Qmail e altri server di posta; :Altri servizi. In più è anche possibile utilizzare una porzione del nostro db ldap per realizzare un elenco di contatti che poi è possibile browsare praticamente con tutti i client di posta evoluti come Evolution, Sylpheed, Mail di Apple, ed anche lo stesso Outlook Express.