[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: KMail das umbenennen von Mails abgewoehnen



Andreas Pakulat schrieb:
Hi,

es sieht so aus, als ob KMail standardmaessig ungelesene neu Mails eines
IMAP-Ordners in den cur/ Zweig verschiebt. Dass zerstoert dann aber
leider die Nutzung der zugrundeliegenden Mailboxen mit Mutt, weil ich
nicht mehr sehe welche Boxen neue Mails enthalten und welche nicht.

Jo. Das scheint wohl die Standardvorgehensweise der MUAs zu sein.
(Gefundene Nachrichten in /new automatisch nach /cur zu verschieben).

Macht das mutt etwa anders? (mein TB macht das auch (verschieben in cur)).

Kennt jemand ne Moeglichkeit das abzuschalten, so dass neue Mails immer
im new/ Zweig bleiben, bis ich sie gelesen habe/sie als gelesen
markiere?

snip aus der englischen Wikipedia[1]:

When the mail user agent process finds messages in the new directory it moves them to cur (using the same link then unlink strategy) and appends an informational suffix to the filename before reading them. The information suffix consists of a colon (to separate the unique part of the filename from the actual information), a '2', a comma and various flags. The '2' specifies, loosely speaking, the version of the information that follows the comma. '2' is the only currently officially specified version, '1' being an experimental version. One can only assume that it was used while the Maildir format was under development. The specification defines flags "P", "R", "S", "T", "D" and "F",[1], while dovecot uses lowercase letters to match 26 IMAP keywords,[3] which may include standardised keywords such as $MDNSent, and user defined flags.



Allerdings weiss ich nicht ob das "abschalten" dieser Prozedur möglich (oder überhaupt als "Feature" vorgesehen ist). (Zumindest habe ich hier auf die schnelle keine Möglichkeit gefunden)

[1] http://en.wikipedia.org/wiki/Maildir


Vielleicht könnte man auch über die "seen" flags was erreichen?

Andreas


--
HTH
MH


Dont send mail to: ubecatcher@linuxrocks.dyndns.org
--



Reply to: