SpippolAzione.net

“Thread View” does not work
ERROR: Bad or malformed request.
Query: THREAD ORDEREDSUBJECT ISO-8859-1 ALL
Server responded: Error in IMAP command UID: ORDEREDSUBJECT threading is currently not supported.

Solution

You need to log into Squirrelmail then click on “Options” then “DisplayPreferences” and make sure that “Enable Thread Sort by References Header” is set to “yes”.

Il mail server aziendale (Qmail su CentOs) che ho messo in produzione il primo gennaio 2009 ha macinato un bel pò di roba.

Per circa 600 caselle di posta:

Contando anche che il filtro antispam che stà sul firewall recapita solo il 40% di quello che arriva, filtrando il resto con vari metodi: filtri bayesani, greylist, whitelist, blacklist DNS, URI Blocklist, antivirus etc etc.

Qmail, e forse non solo lui, usa un timestamp piuttosto strano e particolarmente illeggibile per i suoi log.

Se andiamo a vedere dentro un log troviamo una cosa del tipo (l’e-mail è offuscata per privacy):

@40000000498b04873ac599d4 new msg 12355746
@40000000498b04873ac5a1a4 info msg 12355746: bytes 1347 from qp 4405 uid 89
@40000000498b0488009a8c74 starting delivery 121098: msg 12355746 to local hiddenmail@puppa.com
@40000000498b0488009a982c status: local 1/10 remote 7/60
@40000000498b0488009a9c14 new msg 12355853
@40000000498b0488009aa3e4 info msg 12355853: bytes 1364 from qp 4406 uid 89
@40000000498b04880187c304 starting delivery 121099: msg 12355853 to local hiddenmail@puppa.com
@40000000498b04880187cebc status: local 2/10 remote 7/60
@40000000498b0488028fad84 delivery 121099: success: did_0+0+1/
@40000000498b0488028fc4f4 status: local 1/10 remote 7/60
@40000000498b0488028fccc4 end msg 12355853
@40000000498b0488031f9944 new msg 12355853
@40000000498b0488031fa114 info msg 12355853: bytes 1462 from qp 4416 uid 89
@40000000498b048804d99d84 starting delivery 121100: msg 12355853 to local hiddenmail@puppa.com
@40000000498b048804d9a554 status: local 2/10 remote 7/60
@40000000498b048805322d64 delivery 121100: success: did_0+0+1/
@40000000498b048805323534 status: local 1/10 remote 7/60
@40000000498b048805323d04 end msg 12355853
@40000000498b0488081ae9bc new msg 12355853
@40000000498b0488081af574 info msg 12355853: bytes 1239 from qp 4421 uid 89
@40000000498b048808d2a8cc starting delivery 121101: msg 12355853 to remote hiddenmail@puppa.com
@40000000498b048808d2b484 status: local 1/10 remote 8/60
@40000000498b048808d2b86c delivery 121098: success: hiddenmail@puppa.com/did_0+0+1/
@40000000498b048808d2c03c status: local 0/10 remote 8/60
@40000000498b048808d2c424 end msg 12355746

il timestamp e’ la prima colonna, quel numerone esadecimale dopo la chiocciola ed è coposto da due parti:

1) le prima 16 cifre è un numero a 64 bit che rappresenta i secondi trascorsi dall’inizio del 1970
2) le rimanenti 8 cifre sono un numero a 32 bit che rappresenta i nanosecodi trascorsi dall’inizio del secondo indicato sopra

da qui si capisce che due timestamp uguali sono assai difficil da avere, ma come dicevo, è particolarmente illegibile.

Fortunatamente esiste una utility chiamata tai64nlocal che si preoccupa della conversione, a condizione che il timestamp sia la prima colonna dei dati, come sopra.

Quindi basta un cat nomefile | tai64nlocal per avere un “human-readable”

2009-02-05 16:23:41.986028500 new msg 12355746
2009-02-05 16:23:41.986030500 info msg 12355746: bytes 1347 from qp 4405 uid 89
2009-02-05 16:23:42.010128500 starting delivery 121098: msg 12355746 to local hiddenmail@puppa.com
2009-02-05 16:23:42.010131500 status: local 1/10 remote 7/60
2009-02-05 16:23:42.010132500 new msg 12355853
2009-02-05 16:23:42.010134500 info msg 12355853: bytes 1364 from qp 4406 uid 89
2009-02-05 16:23:42.025674500 starting delivery 121099: msg 12355853 to local hiddenmail@puppa.com
2009-02-05 16:23:42.025677500 status: local 2/10 remote 7/60
2009-02-05 16:23:42.042970500 delivery 121099: success: did_0+0+1/
2009-02-05 16:23:42.042976500 status: local 1/10 remote 7/60
2009-02-05 16:23:42.042978500 end msg 12355853
2009-02-05 16:23:42.052402500 new msg 12355853
2009-02-05 16:23:42.052404500 info msg 12355853: bytes 1462 from qp 4416 uid 89
2009-02-05 16:23:42.081370500 starting delivery 121100: msg 12355853 to local hiddenmail@puppa.com
2009-02-05 16:23:42.081372500 status: local 2/10 remote 7/60
2009-02-05 16:23:42.087174500 delivery 121100: success: did_0+0+1/
2009-02-05 16:23:42.087176500 status: local 1/10 remote 7/60
2009-02-05 16:23:42.087178500 end msg 12355853
2009-02-05 16:23:42.135981500 new msg 12355853
2009-02-05 16:23:42.135984500 info msg 12355853: bytes 1239 from qp 4421 uid 89
2009-02-05 16:23:42.148023500 starting delivery 121101: msg 12355853 to remote hiddenmail@puppa.com
2009-02-05 16:23:42.148026500 status: local 1/10 remote 8/60
2009-02-05 16:23:42.148027500 delivery 121098: success: hiddenmail@puppa.com/did_0+0+1/
2009-02-05 16:23:42.148029500 status: local 0/10 remote 8/60
2009-02-05 16:23:42.148030500 end msg 12355746

Mi è successo (colpa mia) che nella coda della posta in uscita di Qmail ci siano rimasti dei messaggi che a intervalli regolari continuavano ad essere recapitati.

poca roba, ma la codi Qmail e’ strutturata in modo un po’ “vasto”, e andre a cancellare a mano i file che costituiscono la coda puo’ essere un po’ lungo e tedioso.

Ma si puo’ fare anche cosi:

/etc/init.d/qmail stop
find /var/qmail/queue/mess -type f -exec rm {} \;
find /var/qmail/queue/info -type f -exec rm {} \;
find /var/qmail/queue/local -type f -exec rm {} \;
find /var/qmail/queue/intd -type f -exec rm {} \;
find /var/qmail/queue/todo -type f -exec rm {} \;
find /var/qmail/queue/remote -type f -exec rm {} \;
/etc/init.d/qmail start

semplice ed elegante

Il passaggio dal vecchio Qmail (su Debian Woody, kernel 2.4.25 installato [grazie Daniele] il 25 marzo del 2004 con un disco che dava problemi da oltre un anno) al nuovo server di posta (QmailToaster su Centos 5.2 virtuale) con un 600inaio di caselle di gente che preferisce rimanere senza ossigeno piuttosto che senza posta elettronica, e con 28 giga di posta on line da muovere sembra che sia andato, anche se stamattina verso le 10.00 quando:

1) il mail server del San Paolo di Torino non trovava i nostri utenti (usano Exchange di Microsoft ma non sono certo)

2) il Monte dei Paschi non ci prendeva in considerazione (usano Exchange di Microsoft, qui ne sono certo)

3) i fastidiosi BlackBerry di un nostro cliente nitrivano e scalciavano imbizzarriti

tutto contemporaneamente, mi sono trovato un po’ in crisi, ma come sempre l’amico Google aiuta molto e sul finir della mattinata lo tsunami dei casini è scemata.

Sistemista mannaro 1 – server proprietario 0  

Comunque al prossimo giro Postfix, ma ne riparliamo da 4 o 5 anni

Come già detto a suo tempo è possibile con poco sforzo ed un briciolo di astuzia implementare una architettura schematizzata nel diagramma qui sotto.

INTERNET   <->  MAIL.MIODOMINIO.IT (Qmail) -> Exchange / BES -> Internet

Le e-mail destinate al domino @miodominio.it spedite sia da persone che hanno un account @miodominio.it sia da persone che hanno una e-mail qualunque arrivano al server di posta principale raggiungibile all’indirizzo pubblico su internet mail.miodominio.it che fa capo, nei miei test ad un Linux con Qmail ma può essere usato un qualunque server canonico di posta configurato su internet come pop/smtp.

Qui rimangono fino a che il destinatario non le legge via webmail o le scarica col suo client di posta preferito.

Se il destinatario è fornito di BlackBerry allora le e-mail, grazie ad un connettore, verranno spostate dal Qmail alla corrispondente casella di posta presente su Exchange da dove a sua volta il BlackBerry Enterprise Server (BES) le recapita ai terminali BlackBerry.

Come connettore ho usato lo stato dell’arte per queste cose: GFI MailEssentials.

La posta per coloro che sono in possesso di un terminale BlackBerry quindi non risiede nel server Qmail, dove è solo di transito, ma staziona in Exchange da dove è consultabile via Outlook Web Access (OWA) o via Microsoft Outlook.

Quando un possessore di terminale BlackBerry spedisce una e-mail, indipendentemente dal destinatario, questa non transita MAI da Qmail, ma è l’Exchange stesso che, comportandosi da vero server SMTP, la recapita al server giusto, remoto se esterno a @miodominio.it, o a Qmail se il destinatario è @miodominio.it.

Se poi il destinatario @miodominio.it è a sua volta possessore di un terminale BlackBerry allora il connettore la riporterà dentro Exchange nel giro di pochi secondi.

Il tempo minimo impostabile dell’intervallo di polling della posta da parte del connettore che ho usato è di 60 secondi, quindi, tra l’arrivo dell’e-mail dentro Qmail al suo spostamento dentro Exchange, passeranno di media circa 30 secondi.

Tutto questo per evitare di avere un numero di licenze T (tutti gli utenti del mio dominio) quando ho un numero N di BlackBerry visto che nel mio caso T=28*N

Nota personale: non avrei mai creduto, a distanza di 7 anni, che avrei mai rimesso le mani su Exchange, ma devo ammettere che è cresciuto non poco, adesso è quasi usabule, anche se ha sempre una laogica tutta sua, purtroppo Microsoft Outlook 2007 funziona male più o meno come il ’97, inoltre adesso è più pesante,  di diverso ha solo i colori e i pulsanti messi in altri posti, ma è sempre fastidioso come un brufolo su una natica. Per quello che riguarda Zimbra prometteva bene, ma è, come già qualcuno aveva detto, troppo lento, soprattutto all’avvio del client, e il connettore schianta ogni 3×2, troppo instabile per un uso in produzione.