Purtroppo, icedove (il gemellino nobrand di thunderbird) mi lascia spesso perplesso. In effetti sono i coder di mozilla che mi colpiscono.

Premesse: In ambiente Linux i permessi sono importanti, e di default la creazione di file da parte di un utente comune è sottoposta ad un codice di permessi che è -rw-r–r– , detto in ottale 644, detto in termini umani: l’utente può leggere e scrivere/modificare il file, mentre gruppi e altri possono solo leggerlo/copiarlo – e poi modificarselo a casina propria.

Situazione: Ho di recente aggiornato un mail browser su una box per sperimentare ed Icedove è passato dalla versione 2.* alla versione 3.0.11 – molto bene. Alcuni cambiamenti ci sono stati, ma li ho percepiti come superficiali (solite cose di configurazione, opzioni, ecc.).

Problema: Salvando un attachment col nuovo programma viene fuori invece una cosa curiosa:

-rw------- 1 simone users 29 Nov 18 11:58 zzz.txt

Il file ha permessi 600… wtf?

La mia umask è 0022 (che setta i permessi a 644, come vorrei), ma icedove se ne frega… No buono.

Comincio a cercare un’opzione che mi permetta di settare l’aspetto ma non trovo niente. Invece mi imbatto in questo bug. Mmm, molto male.
Leggendo questo commento

From the use of “06*” in the code, it seems that 00600 is hard-coded
in more places in nsMessenger.cpp that handles attachment saving in
v3 series.

ma non potendoci credere (hanno hard-codato i permessi? O_o Are you crazy?), decido di verificare.

$ strace -ff -o /tmp/strace_icedove  /usr/lib/icedove/icedove

L’opzione -ff permette di seguire i fork del programma e generare dei file di log diversi, ciascuno col nome del pid del processo come suffisso.

Dunque uso icedove, mi spedisco un file con attachment, lo salvo sul fs (e ovviamente ha i permessi ristretti), chiudo tutto.

Cerco di capire se c’è una modifica al setting di umask per qualche motivo nei log di strace:

$ grep -C2 umask strace_icedove.4*

Un cambio e poi un reset immediatamente dopo (chissà, ci han ripensato?).

E quindi che può essere… come diceva il bug?

$ grep zzz.txt strace_icedove.4*

Opporcavacca, l’hanno fatto sul serio:

Interessante il fatto che l’umask del sistema (0022 per lo più) avrebbe anche un senso, ma richiederebbe di agire su un mode 0666 (l’umask toglie, non mette).
Da man 2 open si evince chiaramente che O_CREAT necessita del mode, e che calcola

mode & ~umask

cioè in questo caso

 0600 = 110 000 000
 0022 = 000 010 010 e ~0022 = 111 101 101

&  110 000 000
=  111 101 101
- -------------
   110 000 000

quindi sempre 0600 (ovviamente).

A leggere da qui pare che il problema sussista da tanto tempo…

Il tutto parte da una considerazione: molti utenti usano in maniera peculiare le opzioni per gli attachment.
L’attachment, per definizione, andrebbe incluso alla fine della mail, in modalita’ attachment, in modo che sia immodificabile ecc. ecc.
Nella pratica, quasi tutti usano la modalità inline come reply più “ganza” perche’ include parte degli header… nella pratica questo comporta un pessimo uso della mail, e spesso e volentieri una rinuncia a mandare addirittura un messaggio perche’ non si comprende come mai il client non funzioni… (realmente successo).

Benchè perfettamente consapevole che la “comodità con qualche rinuncia” prevarra’ sempre sull’efficienza completa del prodotto, nonche’ consapevole della complessita’ di certe operazioni per un utente comune, sono andato a ravanare un po’ in icedove/thunderbird.

L’idea e’: se l’utente cerca un header più completo del “pippo@disney.com wrote:” in reply, stile forward inline, come può ottenerlo?

Prima cosa: un motore di ricerca con chiavi “thunderbird reply header” risolve molte questioni e porta sulla giusta strada: ci sono estensioni per il client di mozilla che permettono di avere gui (suppongo) per modificare certe variabili chiave in sicurezza.
Io comunque di plugin non ne voglio sapere mezza, quindi vediamo se si puo’ fare senza.

Il Config Editor (sotto Edit -> Preferences -> Advanced) apre un nuovo mondo di opzioni.
Qui ho trovato alcune dritte che cambiano in effetti le cose.
Le variabili da prendere in considerazione sono:

• mailnews.reply_header_type: questa è la variabile più importante; riceve come valore un numero che definisce l’ordine e la presenza degli elementi da visualizzare
• mailnews.reply_header_originalmessage
• mailnews.reply_header_authorwrote: “%s wrote:” produce il nome dell’autore che ha scritto la mail quotata – seguito da “wrote:”
• mailnews.reply_header_separator
• mailnews.reply_header_colon
• mailnews.reply_header_locale: setta i locale (ie: en-US, )
• mailnews.reply_header_ondate: questa var setta giorno e ora. L’unica cosa che ho visto e’ che %s usa questo genere di output mm/dd/yyyy HH:MM AM e credo lo influenzi a seconda del locale

I valori di mailnews.reply_header_type influenzano cosa si vede:

Interessante che l’inclusione della data nell’header della reply sia stata argomento di discussione anche fra i bugs – è una questione sentita!
Insomma, per farla breve, il metodo più “facile” per avere l’header un po’ più completo in reply e’ settare il type a 2.

In linux l’elenco delle preferenze e’ dentro ~/.mozilla-thunderbird/_codice_profilo_/pref.js , e io dopo aver capito ho preferito modificare le voci da qua. Qui vengono segnate solo le voci modificate – altrimenti c’è lo standard. Com’è scritto nel commento all’inizio del file, se si fanno cambiamenti con l’applicazione avviata, questi verrano sovrascritti alla chiusura – perfetto per testing.
Se si vuole l’header con la data:

Nota: icedove, al lancio di una reply, va in segmentation fault se si mette “%s %s” nella variabile _ondate. O_O mittici.

/usr/lib/icedove/run-mozilla.sh: line
            131: 23704 Segmentation fault      "$prog" ${1+"$@"}

Mamma mia.

Ho trovato online questo programma: https://nic-nac-project.org/~kaosmos/changequote-en.html che non è altro che un archivio zip contenente:

Archive:  changequote-0.6.4.3.xpi
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  06-28-10 18:57   chrome/
    36414  06-28-10 18:57   chrome/changequote.jar
     1150  02-16-10 23:47   chrome.manifest
        0  03-02-06 12:00   defaults/
        0  06-28-10 18:56   defaults/preferences/
     1125  06-28-10 18:53   defaults/preferences/prefs.js
    35147  10-03-08 15:00   gpl-3.0.txt
     1582  06-28-10 18:57   install.rdf
 --------                   -------
    75418                   8 files

Il jar è un altro archivio, contenente il codice javascript che manipola le variabili: la funzione decodeCustomizedDate in changequote.js e’ quella che fa la magia: accatta i dati dall’oggetto date di javascript e manipola in funzione del formato richiesto.

Mamma mia…

Delle impostazioni dei vari client grafici (ie: Icedove) non ne so mezza, ma ricercando a destra e manca ho trovato una cosa carina qui.
E’ possibile modificare i font dell’interfaccia utente di Icedove creando nella dir: ~/.mozilla-thunderbird/<account-name>/ chrome/ il file userChrome.css e inserendo il seguente codice (CSS).

Customizzare Mozilla

Se usate Icedove come client di posta, e ricevete una mail con un link web, c’è un’ampia possibilità che il suddetto client vi voglia far navigare con epiphany.
Questo è dovuto ad un link simbolico in /etc/alternatives della vostra Debian che risulta essere:

lobaloba:/etc/alternatives# ll x-www-browser*
lrwxrwxrwx 1 root root 17 2009-01-22 10:19 x-www-browser ->
     /usr/bin/epiphany
lrwxrwxrwx 1 root root 33 2009-01-22 10:19 x-www-browser.1.gz ->
     /usr/share/man/man1/epiphany.1.gz

Supponendo che vogliate aprire gli hyperlink con iceweasel, vi informo che con un sanissimo whereis si possono scoprire alcune info fondamentali.

lobaloba:/etc/alternatives# whereis iceweasel
iceweasel: /usr/bin/iceweasel [...]
/usr/share/man/man1/iceweasel.1.gz

A questo punto basta ricreare i symlink, ed il gioco e’ fatto.

lobaloba:/etc/alternatives# ln -s /usr/bin/iceweasel
     x-www-browser
lobaloba:/etc/alternatives# ln -s /usr/share/man/man1/iceweasel.1.gz
      x-www-browser.1.gz

La soluzione più elegante comunque, passa attraverso $ update-alternatives –config x-www-browser.