Newsgroup: it.comp.os.linux.sys
Titolo: (E-mail) Content-disposition, filename, nome di file lungo.

Sto programmando su una libreria smtp collegata ad un accrocchio che 
gira su un server Linux.
 
In pratica manda via e-mail dei report ad alcuni indirizzi. Una di 
queste è una macchina Windows ed il client di posta è Outlook 2007.
 
Mi preme capire se questo pezzo di header è sbagliato, perché autluk 
assegna all'allegato il classico nome "ATXXXXXX.YYY", invece di quello 
dichiarato:
 
Content-Disposition: attachment;
	filename*0=''192.168.2.200-server-centos-;
	filename*1=critical_error-report.txt
 
 
A me pare di aver rispettato RFC2231 alla lettera, ma magari mi sfugge 
qualcosa.
 
Un grazie anticipato.

 	filename*1=critical_error-report.txt
 
Non tutti i MUA supportano quel formato di filename multiriga (nemmeno 
tutti gli MTA ed i content scanner, a dire il vero).
 
Mi pare comunque che i due apici siano messi male.
Utilizza comunque il formato su una sola linea.

 Utilizza comunque il formato su una sola linea.
 
Dici che devo fregarmene della lunghezza del nome del file?
 
Be', in effetti ci stavo pensando.


Le RFC vorrebbero che tu ti limitassi a 72 caratteri ma nessun MTA 
normalmente fa questo tipo di controlli.
 
Teoricamente dovresti starci dentro quel limite ma se non ce la fai è 
assai probabile che, controllando la sorgente e la destinazione, 
bypassando i controlli antispam la mail arrivi in maniera corretta.
 
 

 bypassando i controlli antispam la mail arrivi in maniera corretta.
 
 
Ok, allora procedo così :)
 
Nel caso di nomi dei file con caratteri non ASCII, posso andare di 
RFC2047 secondo te?
 
Grazie ancora.
 

 Grazie ancora.
 
 
Ok, gli header sono corretti, autluc non li supporta.
 
Ma non basta: autluc vuole la codifica di cui a RFC2047 per i nomi di 
file e la applica alle mail che manda. Ovviamente questo è fuori standard.
 
Non basta: GMail digerisce i nomi dei file sia come rfc2047, sia come 
rfc2231, ma in composizione usa rfc2047.
 
Content-Type: text/plain; charset=US-ASCII; 
name="=?ISO-8859-1?Q?ciao_a_tutti_ol=E9=2Etxt?="
Content-Disposition: attachment; 
filename="=?ISO-8859-1?Q?ciao_a_tutti_ol=E9=2Etxt?="
Content-Transfer-Encoding: base64
X-Attachment-Id: df250d9ff3ee3d0c_0.1
 
 
Thunderbird legge tutto, ma in composizione usa un mix dei due come da 
esempio che posto:
 
Content-Type: text/plain;
  name="ciao a tutti =?ISO-8859-15?Q?ol=E9=2Etxt?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 
filename*0*=ISO-8859-15''%63%69%61%6F%20%61%20%74%75%74%74%69%20%6F%6C%E9;
  filename*1*=%2E%74%78%74
 
E' illuminante questa discussione su un bug report di Evolution:
 
https://bugzilla.gnome.org/show_bug.cgi?id=524377
 
 
Alla fine che metodo mi conviene implementare?

 Alla fine che metodo mi conviene implementare?
 
rfc2047, plain, dopo esserti assicurato che il nome non contenga 
caratteri non ascii.


Alla fine ho optato per RFC 2047 per name e 2231 per filename.
 
La ratio è semplice:
 
1) RFC 2047 è fuori standard in questo contesto, ma Outlook lo 
pretende. Fortunatamente Outlook si accontenta di name ed ignora filename.
 
2) Thunderbird, Kmail, Evolution, etc. supportano 2231, mentre un 
eventuale MTA dovrebbe fregarsene se non eventualmente per qualche 
tipo di content-filtering.
 
Per ora funzica.