Archivio Tag: Mail

Come recuperare gli allegati nei Winmail.dat (sottotitolo: Maledetto Outlook…)

Problema Winmail.dat

A chi non è mai capitato di ricevere un messaggio di posta elettronica e trovarsi, al posto dell’atteso allegato, un anonimo file “Winmail.dat”?

Il problema è nelle impostazioni del software di posta elettronica (Outlook, ma guarda un po’…) del mittente, che manda le mail in un formato RTF tutto suo.

Basterebbe che il mittente cambiasse le impostazioni di default di Outlook (da RTF a HTML o meglio ancora solo testo) per essere in pace con il mondo, lo scrive anche il supporto di Microsoft, dove spiega anche il motivo di questi malefici allegati.

Rimane il fatto di cosa farne di questi Winmail.dat.

Alcuni li cestinano subito, ritengono che siano files inutilizzabili, ma non è così. Contengono gli allegati che stavamo aspettando, e si possono recuperare.

Soluzione 1: San Gmail, lavora per noi…

Se si dispone di un account Gmail, basta inoltrargli il messaggio con il file Winmail.dat, e questo su Gmail sarà perfettamente leggibile e salvabile nel formato corretto!  (E questo vuol dire pure, tra le righe, che chi usa solo account gmail non conosce  proprio il problema dei winmail.dat).

Sempre tra le righe, ma se i signori di Google, per certe cose sempre un passo avanti, hanno pensato bene di fare un filtro automatico di conversione degli allegati Winmail.dat, perché non lo fanno anche gli sviluppatori dei client di posta elettronica?

Soluzione 2: utilities gratuite

I non possessori di un account Gmail possono dormire ugualmente sogni tranquilli, esistono delle utilities gratuite che li convertono estrapolando gli allegati.

Per Mac: TNEF’s Enough
Per Windows: Winmail Opener

 

Prima di tutto la Risoluzione Inversa

Postmaster

Parliamoci chiaro, te che ti vuoi mettere un server mail in ufficio: se non rispetti alcune regole basilari, farai un solo un gran casino e poi non ti venire a lamentare qui che le tue mail ti tornano indietro, rifiutate come si rifiuta la presenza di un appestato.

La prima di queste regole fondamentali, è che i server si devono presentare tra di loro, e non devono cercare di spacciarsi per chi non sono, come spesso fanno gli spammer. Buone maniere e sincerità sono alla base di una buona comunicazione anche nella vita reale, o no?

I server mail, quando iniziano a parlare fra di loro prima di cominciare a scambiarsi messaggi di posta, si pongono alcune domande. Anzi è il server di destinazione che le pone al mittente, per verificare che sia davvero un server di posta “perbene” come vorrebbe far credere, che non sia uno spammer o peggio ancora un untore.

Dialogo tra server SMTP:

  • Mittente: “Ciao, devo mandarti un paio di mail per i tuoi utenti!”
  • Destinatario: “Si OK, però prima fa il bravo e dimmi chi sei…”
  • Mittente “Giusto, presentarsi è da serverini ben educati, io mi chiamo mail.cicciabombacanottiera.it”

Il server del destinatario, che non è uno scemo, ha già memorizzato l’indirizzo IP del server del mittente e zitto zitto effettua immediatamente due prove per stabilire che il server del mittente sia effettivamente chi dica di essere.

  1. Come prima verifica, si accerta che al nome host dichiarato corrisponda effettivamente l’indirizzo IP con cui si presenta.
  2. La seconda verifica è la classica prova del nove, verifica cioè che all’IP con cui il server mittente si è collegato corrisponda esattamente il nome host di cui sopra.

In pratica, se al nome mail.cicciabombacanottiera.it è stato assegnato l’IP 123.123.123.123, e questo deve essere convalidato dai DNS, all’indirizzo IP 123.123.123.123 deve corrispondere dell’host, mail.cicciabombacanottiera.it.

Record A, Record PTR, Risoluzione Inversa…

Le due prove sono banali interrogazioni ai server DNS, la prima chiede il record A di un dato nome host, la seconda chiede il record PTR di un indirizzo IP, entrambe devono corrispondere, ma un peso maggiore viene dato in genere al secondo test, per una serie di motivi che magari spiegherò in un secondo tempo.

Succede, e pure molto frequentemente, che chi decide di mettersi in casa un mail server si preoccupa, per forza di cose, di far assegnare un nome all’indirizzo IP pubblico destinato al server, un Record A affinché il server mail sia raggiungibile dal mondo. Per forza di cose, dicevo, altrimenti non riceverebbe una beata fava da nessuno…

L’improvvisato postmaster però non si preoccupa di far assegnare un record PTR all’IP da chi gli fornisce la connessione.  Se ha fortuna, ma capita di rado, la connessione e i DNS sono gestiti dalla stessa azienda, e il responsabile della gestione dei DNS, quando riceve la richiesta del Record A capisce che è importante associare anche il Record PTR. Santuomo…

È vero anche (e va detto, sic!) il problema contrario, ossia che molti mail server non effettuano o non considerano il test del reverse check come un errore, come dovrebbe essere, il più delle volte per una configurazione discutibile o frettolosa, e si lasciano recapitare porcherie da chiunque. Postmaster maldestri…

Morale della favola: i server mail non devono accettare missive dagli sconosciuti, e gli aspiranti postmaster devono preoccuparsi, prima di mettere in produzione un server mail, di avere un indirizzo IP ben configurato nei DNS, con tanto di Risoluzione Inversa.

Non è finita qui, ma il resto lo vediamo poi, un pezzo per volta…

Mentre ero arrivato ormai alla fine della stesura di questo post, mi sono accorto che avevo già scritto riguardo Indirizzi IP e  Risoluzione Inversa. La memoria non è più quella di una volta.
Poco male, repetita iuvant…

L’insostenibile semplicità della posta elettronica

Problema SPAM

In molti non si rendono conto che il grande problema della posta elettronica risiede nella semplicità del suo ormai vetusto protocollo, una semplicità che diventa un’arma molto pericolosa in mano agli spammer, che ne approfittano a man bassa con i risultati che ben conosciamo.
Non se ne rendono conto i fruitori del servizio, quelli che considerano la posta elettronica un servizio pressoché gratuito, ma che deve funzionare per forza, e pure bene.

Parlando del problema SPAM con i clienti, ci si rende conto che loro si aspettano da te, come amministratore/fornitore del servizio, che il fastidio venga debellato. Se esiste un problema, deve esistere anche una cura, e se non funziona è colpa tua che non la sai applicare bene. Magari fosse così…
Il problema è che loro non sanno che il fenomeno dello SPAM è una lotta ad armi impari, che per quanto noi ci si metta di buon grado per limitarne i danni, la guerra contro lo SPAM è una guerra persa in partenza.

La posta elettronica è un sistema debole e vulnerabile

Il problema dello SPAM nella posta elettronica è dovuto ai limiti di base, purtroppo insormontabili, del protocollo utilizzato. Continua a leggere

Creare account mail multipli in Plesk Panel

Il problema si pone quando ti chiedono di creare un dominio con qualche centinaia di account di posta elettronica: “Oddiomamma sai che due scatole a crearli tutti uno ad uno…” è la prima cosa che ti viene da pensare, perché l’interfaccia di amministrazione di Plesk non prevede, tra le tante cose purtroppo, la creazione di più account mail partendo da una lista di testo, una cosa che, tanto per dire, sarebbe estremamente comoda.

Non lo prevede l’interfaccia grafica di amministrazione, ma se si va a scavare nei meandri della documentazione si scopre che da terminale invece è possibile, e qui si tira un gran sospiro di sollievo!
Stiamo parlando di Plesk Panel per Linux, ovviamente, non so dire ci sia qualcosa di analogo per la versione Windows ma immagino di si.

Plesk su Linux prevede il comando mail, tra quelli che installa tra i suoi binari, e che si trova qui:

/usr/local/psa/bin/mail

Lanciato con l’opzione “–help”, questo comando mostra tutta la sua potenzialità.

La struttura del comando è semplice:

/usr/local/psa/bin/mail comandi <indirizzo_mail> [opzioni]

e una formula di partenza potrebbe essere questa:

/usr/local/psa/bin/mail -c account@dominio.it -mailbox true -cp-access true -passwd password

dove -c sta per “create”, e dopo l’indirizzo mail le opzioni riguardano la creazione della mailbox (con i valori predefiniti per il dominio), l’abilitazione all’accesso al pannello di controllo e per terminare la password, ovviamente sostituendo “password” con una stringa adeguatamente sicura.

Curiosando tra le varie opzioni si scopre che è possibile attivare e configurare l’antivirus, l’amministrazione dell’antispam e molte altre ancora.

A questo punto, avendo una lista di indirizzi mail da creare, è facile creare un file di testo dove riga per riga si definiscono i comandi, renderlo eseguibile e lanciarlo come uno shell script:

#!/bin/sh
/usr/local/psa/bin/mail -c account1@dominio.it -mailbox true -cp-access true -passwd password1
/usr/local/psa/bin/mail -c account2@dominio.it -mailbox true -cp-access true -passwd password2
/usr/local/psa/bin/mail -c account3@dominio.it -mailbox true -cp-access true -passwd password3
...

Qualche centinaio di account mail si creano in pochi minuti!

Io ho provato, per comodità e pigrizia, mettendo a tutti la stessa password, ma immagino che con un po’ di destrezza si potrebbe tranquillamente creare una variabile che definisca una password diversa per ogni account, autogenerata.