Posts Tagged ‘IMAP’

Samstag, 23. Mai 2020

Zwei Cyon IMAP-INBOXen innerhalb von drei Wochen zerschossen

Link zu diesem Artikel

Seit 2012 bin ich glücklicher Kunde von Cyon, eines schweizerischen Hosting-Anbieters. In den letzten drei Wochen hat sich das Erlebnis etwas getrübt.

Wichtig: Die unten beschriebene Problematik hatte ich in den letzten acht Jahren nie, und schon gar nicht innerhalb von drei Wochen zwei Mal. imapfilter hat bisher auch immer reibungslos funktioniert.

Das erste Problem

Am Morgen des Samstag, 9. Mai 2020 konnte ich plötzlich nicht mehr auf meine E-Mails in der INBOX von Konto A zugreifen. Weder in Apple Mail (meinem hauptsächlichen E-Mail-Client), noch über RainLoop (Webmail), noch mit imapfilter, welches ich verwende, um E-Mails automatisiert in Unterordner zu verschieben (oder im Falle von Spam: zu löschen).

Das alle 5 Minuten laufende imapfilter, gepaart mit Healthchecks, ist übrigens auch ein optimales „Frühwarnsystem“, welches mir meldet, wenn mit dem Mailserver etwas nicht stimmt.

Das Log von RainLoop (unter RAINLOOPROOT/data/_data_/_default_/logs) zeigte den Fehler schön auf:

...
[08:55:36.698][1c50d1ff] IMAP[DATA]: > TAG3 SELECT "INBOX"\r\n
[08:55:36.960][1c50d1ff] IMAP[ERROR]: Stream Meta: Array
...
[08:55:36.961][1c50d1ff] IMAP[ERROR]: MailSo\Net\Exceptions\SocketReadException: MailSo-Net-Exceptions-SocketReadException (NetClient.php ~ 523) in %PATH%/rainloop/v/0.0.0/app/libraries/MailSo/Net/NetClient.php:523
Stack trace:
...

Und so sah das Symptom bei imapfilter aus:

...
Sat May  9 10:41:38 2020: reading data through SSL; the connection has been closed cleanly
...

Diese Meldung wurde in einer Schleife ausgegeben, und zwar bei jedem Befehl, der E-Mails filtern und — falls vorhanden — verschieben sollte.

Als ich imapfilter im Debug-Modus laufen liess …

$ imapfilter -v -l log.txt -d debug.txt recipe.imapfilter

… tauchte folgende erhellende Nachricht im Debug Log (debug.txt) auf:

IMAP (5): 107C NO [UNAVAILABLE] Maximum number of connections from user+IP exceeded (mail_max_userip_connections=75)

Weil die IMAP-INBOX nicht abrufbar war, steckten meine Scripts in Endlosschleifen fest, welche die Zahl der Verbindungen pro E-Mail-Konto und IP voll ausschöpfte. Es waren also keine Verbindungen mehr möglich.

Als erstes schaltete ich deshalb den imapfilter-Cronjob ab, um dem IMAP-Server eine Verschnaufspause zu gönnen. Dann wurde rasch klar, dass die E-Mails in der INBOX aus irgendeinem Grund nicht aufgelistet werden konnten. Ich hatte in den zwei Tagen zuvor einige Anpassungen am imapfilter-Konfiguration vorgenommen; eine Möglichkeit war, dass die Verschiebeaktionen dabei zu einer korrupten INBOX-Datei geführt haben könnten.

Obwohl das Problem an einem Wochenende auftrat, schrieb ich dem Support — wohlwissentlich, dass ich erst am Montag eine Antwort erhalten würde. Vielleicht würde ja trotzdem eine gute Seele reinschauen … leider nein, The Computer Says No.

Ich kämpfte deshalb auf eigener Faust weiter: Nach viel Pröbeln wählte ich die Holzhammer-Methode: Nach einem lokalen Backup des kaputten Dovecot-Verzeichnisses löschte ich via SSH alle Dateien im INBOX-Verzeichnis (Pfad: siehe unten), ein frischer Start, sozusagen. Seither funktioniert die INBOX wieder.

Glück im Unglück: Da ich bei Konto A versuche, Inbox Zero anzuwenden, waren nur vier E-Mails von der Löschaktion betroffen, von denen ich die von Apple Mail lokal gespeicherten .emlx an einen sicheren Ort kopieren konnte.

Das zweite Problem

Kurz nach Mitternacht in der Nacht von Donnerstag auf Freitag, 22. Mai 2020 traten gemäss imapfilter Probleme mit Konto B auf. Ich merkte dieses am späteren Freitag-Morgen, als ich mit meinen Mail-Clients nicht mehr auf meine E-Mails in der INBOX von Konto B zugreifen konnte. Dieses Mal gab es aber keine Überlastung der erlaubten Verbindungen. imapfilter meldete bei Abfragen auf die INBOX:

...
Fri May 22 14:47:16 2020: IMAP (5): 127C NO [SERVERBUG] Internal error occurred. Refer to server log for more information. [2020-05-22 14:47:16] (0.040 + 0.000 + 0.039 secs).
...

Ohne Zugriff auf die Logs konnte ich „SERVERBUG“ nicht weiter eingrenzen. Erneut schrieb ich eine E-Mail an den Support (Versand um 15:19 Uhr), und erhielt um 16:57 Uhr eine Antwort. Leider in der Form „Have you tried turning it off and on again?“. Die Hoffnung war verloren, dass mir Cyon noch vor dem Wochenende beim Debugging helfen konnte — somit sah ich ca. 56 Stunden ohne E-Mail entgegen.

Hilfreich war in der ersten Antwort des Supporters einzig der Tipp, anstelle von RainLoop doch bitte das „offizielle“ Webmail von Cyon zu verwenden: webmail.cyon.ch, welches auf RoundCube basiert. Gesagt, getan. So konnte ich dem Supporter klipp und klar belegen, dass das Problem auf der Serverseite lag. Wenn ich die INBOX anwählte, erschien am unteren Bildschirmrand ganz in rot folgende Fehlermeldung:

Serverfehler: UID SORT: Internal error occurred. Refer to server log for more information. [2020-05-22 17:59:38] (0.041 + 0.000 + 0.040 secs)

Leider gab es seither keine Antwort mehr, weshalb ich mir erneut selber helfen musste (wieso passieren diese Fehler immer auf’s Wochnenende hin?!)

Das Problem war dieses Mal etwas anderer Natur — Apple Mail und imapfilter zeigten partout keine E-Mails mehr in der INBOX an; die Unterordner konnten hingegen abgerufen werden. RoundCube hingegen zeigte die INBOX etwas erratisch manchmal an, manchmal nicht.

Die schlussendliche Lösung:

  • Per SSH auf den Shared Hosting-Server einloggen
  • Alle dovecot-Prozesse abschiessen mittels 
    $ ps ax | grep -i dovecot | grep -v grep | awk '{print $1}' | xargs kill
  • Die (möglicherweise korrupte?) dovecot.index Datei löschen
  • In Cyons RainLoop Webmail einloggen
  • Die E-Mails der letzten Tage im problematischen Mail-Ordner von Hand durchgehen; solche, die nicht angezeigt werden konnten, habe ich kurzerhand gelöscht
  • Einen neuen Unterordner erstellen; bspw. BACKUPYYYYMMDD
  • Alle verbleibenden E-Mails im problematischen Ordner auswählen und in den Backup-Ordner verschieben (ich hatte Angst, dass der Verschiebeprozess nicht funktionieren würde, klappte in dem Fall aber problemlos)
  • Zurück auf SSH wechseln
  • Im Verzeichnis des problematischen Emailordners rm -rf * ausführen, um alle vorhandenen Dateien zu löschen (ACHTUNG: Wer diesen Befehl am falschen Ort ausführt, löscht sich sein gesamtes Benutzerverzeichnis)
  • RoundCube, RainLoop Apple Mail und imapfilter wieder starten resp. öffnen — der problematische Ordner ist jetzt zwar leer, aber kann immerhin wieder ohne Fehlermeldungen abgefragt werden. Im Hintergrund erstellt Dovecot alle benötigten Dateien wieder.
  • Falls gewünscht die E-Mails aus dem Backup-Ordner zurück in den (neu erstellten) ehemals problematischen Ordner verschieben oder kopieren (ACHTUNG: Es könnte sein, dass eine ganz bestimmte E-Mail im Backup Dovecot zum Straucheln bringt; in dem Fall würde man mit der Rückkopieraktion das Problem wieder von vorne starten … bei mir war das glücklicherweise nicht der Fall)

Epilog

Ohne Zugriff auf die IMAP-Logs ist mir aber weiterhin nicht möglich herauszufinden, was denn nun wirklich genau das Problem war. Und so besteht zu befürchten, dass das Problem jede Minute erneut auftreten kann.

Und nein, ich gebe nicht Cyon die Schuld: Es könnte sein, dass mein spezielles Setup mit 5-minütigen imapfilter-Verbindungen die Ursache hinter den Problemen ist. Bspw. eine Anpassung, welche tausende E-Mails verschiebt und der Mailserver noch am kopieren ist, wenn der nächste imapfilter-Prozess bereits wieder startet und gerade in Kopie befindliche E-Mails irgendwohin kopiert. Oder ein Software-Update meiner Debian-Systeme in den letzten drei Wochen.

Es könnte aber auch sein, dass der Fehler bei Cyon zu suchen ist — d.h. ein kaputter RAM-Baustein, der beim Schreiben IMAP-Ordnerdateien korrumpiert, oder das Storage-System, welches zu schreibende Daten verfälscht, oder ein Update von Dovecot, nach welchem sich die Software nicht mehr wie gewohnt verhält. Oder eine Inkompatibilität zwischen der neuen Dovecot-Version mit dem bisherigen imapfilter; oder mit dem neuen imapfilter und der bisherigen Dovecot-Version.

Cyons E-Mail-Infrastruktur

Was ich bei diesen Problemen über Cyons E-Mail-Infrastruktur gelernt habe:

  • Cyon verwendet Dovecot als IMAP-Server
  • Ist man per SSH auf dem Cyon-Server eingeloggt, kann man sich die (eigenen) laufenden IMAP-Server-Prozesse mit folgendem Befehl anzeigen lassen. Die Zahl der Prozesse ist meines Erachtens proportional zur Anzahl der Clients, die gerade per IMAP E-Mails abfragen (mindestens 1 Prozess, es können aber durchaus auch mehrere pro Client sein). 
    $ ps ax | grep -i dovecot
3662642 ?        S      0:00 dovecot/imap
3662645 ?        S      0:01 dovecot/imap
3662646 ?        S      0:00 dovecot/imap
3662706 ?        S      0:00 dovecot/imap
3663038 ?        S      0:00 dovecot/imap
3664246 ?        S      0:00 dovecot/imap
3674314 ?        S      0:00 dovecot/imap
3674316 ?        S      0:00 dovecot/imap
3674317 ?        S      0:00 dovecot/imap
3674449 ?        S      0:00 dovecot/imap
  • Die Mail-Daten eines Benutzers liegen in einer Ordnerstruktur unter /userdata01/%CYONUSER%/mail
  • Die Mail-Ordner einer E-Mailadresse %EMAILUSER%@%DOMAIN% finden sich unter /userdata01/%CYONUSER%/mail/%DOMAIN%/%EMAILUSER%/mailboxes
  • In einem Mail-Ordner finden sich normalerweise folgende Dateien: 
    drwxr-x--x 2 user user    158 May 23 17:02 ./
drwxr-x--x 3 user user     32 May 23 16:43 ../
-rw-r----- 1 user user  15024 May 23 16:41 dovecot.index
-rw-r----- 1 user user  15024 May 23 16:41 dovecot.index.backup
-rw-r----- 1 user user 391208 May 23 17:34 dovecot.index.cache
-rw-r----- 1 user user   2144 May 23 17:02 dovecot.index.log
-rw-r----- 1 user user  32928 May 23 16:41 dovecot.index.log.2
  • Löscht man die Cache-Datei dovecot.cache in einem Mailordner (kann mehrere hundert Megabytes oder sogar Gigabytes gross sein), wird diese von Dovecot nicht automatisch neu generiert. Nichts geht mehr; d.h. der Ordner wird als leer angezeigt.
  • Löscht man die Index-Datei dovecot.index, wird diese von Dovecot automatisch neu generiert. Beim zweiten Problem half dies tatsächlich, dass ich wieder Zugriff auf E-Mails erhielt.

Tags: , , , , , , ,
Labels: IT, Schweiz, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. März 2020

Mail.app unter macOS High Sierra sortiert IMAP-Ordner nicht (mehr) alphabetisch

Link zu diesem Artikel

Das Problem löst man, indem man Apple Mail zuerst schliesst und die Datei .mboxCache.plist des betroffenen IMAP-Kontos löscht.

Mit dem folgenden Befehl findet man alle von Mail.app angelegten Dateien mit diesem Namen:

$ find ~/Library/Mail -maxdepth 3 -type f -name .mboxCache.plist

Wer die Dateien gleich löschen möchte:

$ find ~/Library/Mail -maxdepth 3 -type f -name .mboxCache.plist -exec rm '{}' ';'

ACHTUNG: Bitte kopiert den zweiten Befehl auf eigene Verantwortung von hier. Der Befehl LÖSCHT Dateien auf deinem Computer — wenn alles gut geht nur diejenigen Dateien, die hier beschrieben wurden. Ich übernehme aber keine Gewähr..

Quelle: Using Apple Mail, my folders have stopped being displayed in alphabetical order – how can I restore this sort order?

Tags: , , , , , , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 3. Juni 2015

Mail.app unter OS X sortiert IMAP-Ordner nicht (mehr) alphabetisch

Link zu diesem Artikel

ACHTUNG: Dieser Trick funktioniert spätestens unter macOS High Sierra nicht mehr. Hier der neue Weg zur Lösung des Problems.

Wenn Mail.app sich irgendeinmal im Laufe der Zeit entscheidet, neu erstellte IMAP-Ordner nicht alphabetisch in die Ordnerstruktur einzureihen, sondern einfach an das Ende der Ordnerliste stellt, ist es Zeit für diesen kleinen Trick:

The solution is to disable the associated account in Mail Preferences, Quit Mail, restart Mail and then enable to account again.

Quelle: Mac Mail not automatically sorting mailbox folders alphabetically

Auf Gut Deutsch: Das besagte IMAP-Konto unter den Einstellung auf Inaktiv setzen, Mail.app beenden und neu starten.

Bei mir fügte diese Aktion leider dazu, dass das Mail-Konto selber an den Schluss meiner fünf Mailkonten gestellt wurde. Ich musste das Spiel deshalb anschliessend noch mit allen anderen Konten durchführen.

Tags: , , , , , ,
Labels: Apple

4 Kommentare | neuen Kommentar verfassen

Freitag, 27. Juni 2014

Spam-Mails mit imapfilter in einen Unterordner verschieben

Link zu diesem Artikel

Der falsche Weg, wie ich ihn bis heute angewendet hatte:

...
-- SPAM
messages = mbox.INBOX:contain_subject('[SPAM]')
messages:move_messages(mbox['Spam'])
...

Das führte in diesem einen speziellen Fall dazu, dass ein legitimes E-Mail eines Kollegen mit „[SPAM]“ im Subject gekennzeichnet wurde. Da das elektronische Gespräch hin- und herging, landeten alle Antworten des Empfängers immer wieder in meinem Spam-Ordner.

Der richtige Weg — jedenfalls für Mail-Accounts, die bei Cyon GmbH gehostet werden — ist:

...
-- SPAM
messages = mbox.INBOX:contain_field('X-Spam-Status','Yes')
messages:move_messages(mbox['Spam'])
...

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Make Mail.app respect your .mailboxlist when using IMAP

Link zu diesem Artikel

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

Mail.app is a nice, sleek E-Mail-Client which does quite everything you need in everydays use. But there’s one great drawback: Apple engineers sometimes simply miss the point. When accessing IMAP-mailboxes through Mail.app, you’re not only presented all the expected IMAP-folders, but all those crappy dot-hidden-files (.*) in the IMAP-root, even if there is a .mailboxlist, which tells well written (!) Mail-clients which folders to subscribe to (isn’t it even mentioned in a RFC?). Mail.app doesn’t – god knows why. In fact, it seems also to depend on which mail-server your provider uses. If it’s pmdf, you’re most likely to end up the way I am. Another provider I use to store my eMeidi.com-accounts on, there are no such issues at all.

Anyway, while browsing the web I only found some small hints … one worked! There’s some manual work to do, so it’s essential to have SSH-/Telnet-Access to the server where your folders are being stored.

  • Really first, close all your Mail-clients. Safe is safe
  • Second, make a backup-copy of all your IMAP-folders.
  • The clue is to move your IMAP-folders to a subdirectory. I therefore created a folder IMAP/ in my home-directory. Now you can move all folders to IMAP/
  • Configure Mail.app to use „IMAP/“ as folder prefix. This setting is required by all other Mail-clients you use aside
  • Make also sure to update .mailboxlist in your root-directory to point to the new folders
  • If your provider also offers Horde IMP (Webmail), you have to „subscribe“ to the new folders. Don’t forget to point sent-mail and Trash to the new locations. These settings can usually be done under ‚Options‘

I feared to mess it up, so I waited months before I took these steps. Now I wish I had done it earlier. It’s so smooth to see only your mailfolders and all the other .profile, .whatever and .huh being gone forever!

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 15. August 2013

Mit imapfilter eingehende E-Mails verschieben — aber erst nach der Lektüre

Link zu diesem Artikel

In einem anderen Blog-Artikel habe ich vor einiger Zeit beschrieben, wie ich mich mittels imapfilter von den Filterregeln meiner Mailserverbetreiber losgelöst habe. Sollte ich mich jemals von der cyon GmbH abwenden, müsste ich die Filterregeln beim neuen Anbieter — falls überhaupt möglich — nicht erneut umständlich über eine Web-Oberfläche einprogrammieren.

In der Zwischenzeit habe ich realisiert, dass nachfolgender Befehl optimal ist, um Nachrichten automatisiert in der IMAP-Ordnerstruktur abzulegen — aber erst, nachdem ich die Nachrichten auch wirklich gelesen habe:

messages = mbox.INBOX:contain_from('email@domain.tld') * mbox.INBOX:is_seen()
messages:move_messages(mbox['IMAP-Folder'])

Der erste Befehl auf der ersten Zeile wählt E-Mails eines bestimmten Absenders aus. Das Asterisk („*“) bedeutet „AND“, während der zweite Teil des Ausdrucks die Bedingung macht, dass die E-mail-Nachricht als gelesen markiert ist.

Ich verwende einen solchen Filter beispielsweise, um Kalendereinladungen abzulegen, sobald ich diese bestätigt habe.

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2013

Thunderbird effizient mit einem IMAP-Server und zehntausenden E-Mails verwenden

Link zu diesem Artikel

Neben der lokalen Ablage der Logs meines Linux-Servers unter /var/log leite ich Resultate von Cron-Läufen auch an eine E-Mail-Adresse auf einen in einem Rechenzentrum stehenden IMAP-Server weiter. Einerseits stelle ich so sicher, dass ich im Falle eines verheerenden Hacks auf dem IMAP-Server möglicherweise Informationen extrahieren kann, welche mir bei der Forensik helfen. Ob diese Lösung wirklich das Gelbe des Eis ist sei hier dahingestellt (heute würde ich mich wohl für eine Lösung wie Splunk entscheiden).

Nach langer Zeit habe ich heute wieder einmal per Web-Mail in diesen Account hineingeschaut und musst feststellen, dass sich in zwei IMAP-Ordnern je über 50’000 Mails angesammelt haben. Ich entschied mich, diese Ordner zu säubern. Hierzu verwendete ich aber nicht die vom Hoster angebotene Web-Mail-Lösung Roundcube, sondern Mozilla Thunderbird.

Nachfolgend einige Tipps, wie man mit der riesigen Flut an Mails umgeht:

Alle IMAP-Nachrichte herunterladen

Einerseits habe ich unter

  1. Thunderbird
  2. Preferences
  3. Advanced
  4. General
  5. Config Editor

den Wert von mail.server.default.check_all_folders_for_new auf true gesetzt. Ob dies etwas bewirkt, kann ich leider nicht sagen.

Andererseits habe ich auch bemerkt, dass man alle E-Mails in einem Ordner mittels Command-A auswählt und dann mittels Rechtsklick über die Option „Get Selected Messages“ herunterladen kann.

IMAP-Nachrichten auf dem Server durchsuchen

Unter

  1. Edit
  2. Find
  3. Search Messages…
  4. [x] Run search on server

In meinem Fall funktionierte diese Methode aber nicht; es wurden nur die Bodies derjenigen Mails durchsucht, welche sich bereits lokal auf meiner Festplatte befanden.

Zehntausende E-Mails rasch löschen

Nachfolgende Option verhindert, dass Thunderbird während Minuten nicht mehr reagiert, einen Spinning Beachball anzeigt und in Mac OS X‘ Activity Monitor rot als „not responding“ markiert wird:

  1. Tools
  2. Account Settings…
  3. Server Settings
  4. When I delete a message: (x) Remove it immediately

Dies verhindert, dass zu löschende Nachrichten von Thunderbird im Hintergrund in den Ordner „Trash“ verschoben werden, aus welchem man diese danach noch mittels „Empty Trash“ löschen muss.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 27. September 2012

Wenn imapfilter plötzlich mit meinem bei Cyon gehosteten Mail-Server nicht mehr funktioniert

Link zu diesem Artikel

Da verreise ich als auf einen IT-Audit ins „Ländle“, und prompt versagt mein geliebter imapfilter seinen Dienst. Fazit: Meine INBOXes sind plötzlich voller Mails, welche von imapfilter sonst schön brav spätestens 5 Minuten nach deren Ankunft auf meinen Mail-Konti in einen Unterordner verschoben werden. Zuerst dachte ich, dass mein lokaler Linux-Server, auf welchem imapfilter läuft, wegen eines Stromunterbruchs ausgefallen ist.

Doch mittels des äusserst nützlichen SSH-Clients Prompt hatte ich bereits am Dienstag realisiert, dass der Server am Netz hängt und ansprechbar ist.

Ein Blick in das von meinem imapfilter.sh-Script erzeugten Log zeigte, dass das Problem erstmals am Montag um 17 Uhr 15 Minuten aufgetaucht ist (Montag kurz vor Feierabend – dann scheinen die Cyon Sysadmins am liebsten ihre Zertifikate zu erneuern?)

2012-09-24 17:15 - <imapfilter Script> - Error '5' checking mail

Nun gut … letzter Ausweg: Ich versuche mich mittels

imapfilter -d -c <imapfilter Script>

interaktiv anzumelden und Debug-Meldungen abzulegen. Doch zur Analyse dieses Debug-Dumps kommt es nicht, denn auf der Kommandozeile strahlt mich folgender Hinweis an:

Server certificate subject: /OU=Domain Control Validated/CN=*.cyon.ch
Server certificate issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - G2
Server key fingerprint: 39:E9:08:A5:D9:EC:C3:A3:3E:0F:73:7C:14:B7:F2:A5
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Mittels Eingabe von p akzeptiere ich das neue Zertifikat, und gut isses.

Da hat Cyon also einfach nur sein Server-Zertifikat geändert. Wieso nimmt man immer gleich das Schlimmste an?

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Juni 2011

Mail.app 4.5 sortiert IMAP-Ordner nicht alphabetisch

Link zu diesem Artikel

Offenbar erlaubt Apple seit Mac OS X Snow Leopard das Verschieben von IMAP-Ordnern innerhalb der Liste. Leider hat dies aber zur Folge, dass nachträglich erstellte Ordner nicht mehr alphabetisch eingeordnet werden, sondern ans Ende der Liste gelangen.

Um die Sortierung zurückzusetzen, führe man deshalb bei jeder sich bietender Gelegenheit folgenden Befehl aus:

$ rm ~/Library/Mail/<interne Bezeichnung des Mail-Kontos>/.mboxCache.plist

Quelle: Mail Not Sorting new Folders Added Alphbetically

Tags: , , , , ,
Labels: Apple

2 Kommentare | neuen Kommentar verfassen

Mittwoch, 8. Juni 2011

Zertifikatsprobleme mit imapfilter bei einem loadbalancierten Exchange 2010-Server

Link zu diesem Artikel

ACHTUNG: Funktioniert leider doch nicht wie erwünscht.

imapfilter ist das Tool meiner Wahl, um einkommende Mail-Nachrichten in IMAP-Unterordner zu verschieben. Dessen Anwendung habe ich in einem Blog-Artikel erläutert.

Seit mein Arbeitgeber mein E-Mail-Konto von einem Unix-Mailserver auf eine Microsoft Exchange 2010-Lösung migriert hat, gab es Probleme mit den Zertifikaten. (Natürlich hätte ich die Regeln erneut unter Exchange erfassen können, aber der Vorteil von imapfilter ist eben gerade, dass man nur die Serververbindung anpassen muss, und die Mails werden weiter schön sauber sortiert).

imapfilter lässt man bekanntlich beim ersten Verbindungsversuch im interaktiven Modus laufen und akzeptiert dort dann brav das Zertifikat das Mail-Servers:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: CD:10:34:E9:6D:1D:07:09:3D:9E:53:FC:B5:94:B0:10
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Doch leider schien dieser Server in der Folge einfach so den Fingerprint zu wechseln. Als ich imapfilter nach einiger Zeit (und Fehlermeldungen im cron.log) erneut im interaktiven Modus ausführte, erschien folgende Warnung:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: 6D:D9:E8:FF:A3:70:2A:D8:44:10:0C:7D:0E:94:65:FC
ATTENTION: SSL/TLS certificate fingerprint mismatch.
Proceed with the connection (y/n)? y

Leider führte das Bestätigen der Warnung nicht dazu, dass dieses neue Zertifikat akzeptiert wurde (wohl, weil für denselben Server bereits ein anderes Zertifikat gespeichert war). Meine Vermutung: Da mein Arbeitgeber einen loadbalancierte Exchange 2010-Infrastruktur aufgebaut hat, besitzt jeder Server ein anderes Zertifikat (auch wenn beide gegen aussen als mail.campus.unibe.ch in Erscheinung treten).

Der Workaround sah folgendermassen aus:

$ copy ~/.imapfilter/certificates ~/.imapfilter/certificates.old
$ imapfilter -c myconfigfile
(... accept certificate permanently ...)
$ cat ~/.imapfilter/certificates.old >> ~/.imapfilter/certificates

Ab sofort motzte imapfilter nicht mehr über den gelegentlich wechselnden Fingerprint, weil nun einfach beide möglichen Zertifikate in der Datei gespeichert sind.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

« Older Entries