search for: unflagged

...ls do no longer show flags with current Dovecot builds. This used to work before, not sure what broke it or whether I used it in the wrong way. When the removeflag line is dropped *both* messages get flagged in the client, one in INBOX and one in Trash. With removeflag in place, *both* messages are unflagged, the one in INBOX and the one in Trash. This used to work differently before if memory doesn't fail me. #Test if address :is "From" "user at example.com" { addflag "\\Flagged $MailFlagBit1"; keep; removeflag "\\Flagged $MailFl...

I activated Dovecot's Virtual Plugin in my configuration and created dovecot-virtual file with the following content: [quote] # ~/Maildir/virtual/Flagged/dovecot-virtual * ?flagged [quote] When I flag some messages these messages automatically appears inside my Virtual Folder called "Flagged", but once inside this folder , when I "Unflag" the message, It doesn't

...ot; { > ? set "email" "${1}";?? > } > addflag "Junk"; > addflag "\\seen"; > addflag "$label3"; > pipe :copy "learn-spam.sh"; > pipe :copy "learn-spam-sa.sh" [ "${email}" ]; > > When i move an unflagged email to Folder Junk, it is shown in > Thunderbird as "personal", Junk but Unseen. > > So, the rule is really working, except for the \\seen-Flag. > > I have the line > > addflag "\\seen"; > > from the dovecot-wiki! > > BG jakob > > > &g...

...quot; "${1}"; >> } >> addflag "Junk"; >> addflag "\\seen"; >> addflag "$label3"; >> pipe :copy "learn-spam.sh"; >> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; >> >> When i move an unflagged email to Folder Junk, it is shown in Thunderbird >> as "personal", Junk but Unseen. >> >> So, the rule is really working, except for the \\seen-Flag. >> >> I have the line >> >> addflag "\\seen"; >> >> from the dovecot-wiki!...

Hi Ralph! This is, what calls the correct sive-filter rules. I have that already in use. But the file file:/etc/dovecot/sievepipe/report-spam contains my sieve-script from my first posting. So, the difference from setflag to addflag is, setflag sets the flags, and only the given flags (removing all other flags), and addflag adds a flag to the existing flags... I fiddled around a little... The

...uot;Junk"; > >> addflag "\\seen"; > >> addflag "$label3"; > >> pipe :copy "learn-spam.sh"; > >> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; > >> > >> When i move an unflagged email to Folder Junk, it is shown in > Thunderbird > >> as "personal", Junk but Unseen. > >> > >> So, the rule is really working, except for the \\seen-Flag. > >> > >> I have the line > >> > >&g...

...>> addflag "\\seen"; > >> >> addflag "$label3"; > >> >> pipe :copy "learn-spam.sh"; > >> >> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; > >> >> > >> >> When i move an unflagged email to Folder Junk, it is shown in > >> Thunderbird > >> >> as "personal", Junk but Unseen. > >> >> > >> >> So, the rule is really working, except for the \\seen-Flag. > >> >> > >> >> I have the line &gt...

...ls do no longer show flags with current Dovecot builds. This used to work before, not sure what broke it or whether I used it in the wrong way. When the removeflag line is dropped *both* messages get flagged in the client, one in INBOX and one in Trash. With removeflag in place, *both* messages are unflagged, the one in INBOX and the one in Trash. This used to work differently before if memory doesn't fail me. > > #Test > if address :is "From" "user at example.com" > { > addflag "\\Flagged $MailFlagBit1"; > keep; > remov...

...ls do no longer show flags with current Dovecot builds. This used to work before, not sure what broke it or whether I used it in the wrong way. When the removeflag line is dropped *both* messages get flagged in the client, one in INBOX and one in Trash. With removeflag in place, *both* messages are unflagged, the one in INBOX and the one in Trash. This used to work differently before if memory doesn't fail me. > > #Test > if address :is "From" "user at example.com" > { > addflag "\\Flagged $MailFlagBit1"; > keep; >...

...t :matches "imap.email" "*" { ? set "email" "${1}";?? } addflag "Junk"; addflag "\\seen"; addflag "$label3"; pipe :copy "learn-spam.sh"; pipe :copy "learn-spam-sa.sh" [ "${email}" ]; When i move an unflagged email to Folder Junk, it is shown in Thunderbird as "personal", Junk but Unseen. So, the rule is really working, except for the \\seen-Flag. I have the line addflag "\\seen"; from the dovecot-wiki! BG jakob Am 04.12.18 um 14:06 schrieb Jakobus Sch?rz: > Hi Ralph! >...

Hi there, We've been long time users of Dovecot, and have found it a great IMAP server. I don't think we've had any serious problems in the 3-4 years of use. So great work. :) We have a IMAP inbox that is accessed by a number of different users from Thunderbird. We have a rule in Thunderbird to flag new emails as "TO DO", so someone can unflag the email once it has

...perfectly fine X-IMAP header, and up until I switched things were working great. The user visible symptom of this happened every time new spam arrived in my Junk folder [3] --- the new spam would arrive, be flagged as spam by Mail.app, and the earlier pieces of mail would promptly be unflagged! Anyway, Timo's clue in [2] prompted me to turn off both mbox_lazy_writes and mbox_dirty_syncs (the latter just on the off- chance... it's a low-volume server, so I can deal with the inefficiency). Lo and behold, Mail.app started acting sane again *and* the X-Keywords header app...

DISCLAIMER: I am SSA, LLVM and compiler ignorant, so take the following for what it is worth. What about logically breaking a (complex) SEH method into two logical methods, as per this pseudo-code as an example: ----------------------- foo(parameter-list) { leading-statements; try { try-statements; } catch(Execption0 ex0) { catch-0-statements; } . catch(ExceptionN exN) {

...> >> addflag "Junk"; > >> addflag "\\seen"; > >> addflag "$label3"; > >> pipe :copy "learn-spam.sh"; > >> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; > >> > >> When i move an unflagged email to Folder Junk, it is shown in > Thunderbird > >> as "personal", Junk but Unseen. > >> > >> So, the rule is really working, except for the \\seen-Flag. > >> > >> I have the line > >> > >> addflag "\\seen"; &...

..." { > set "email" "${1}"; > } > addflag "Junk"; > addflag "\\seen"; > addflag "$label3"; > pipe :copy "learn-spam.sh"; > pipe :copy "learn-spam-sa.sh" [ "${email}" ]; > > When i move an unflagged email to Folder Junk, it is shown in Thunderbird > as "personal", Junk but Unseen. > > So, the rule is really working, except for the \\seen-Flag. > > I have the line > > addflag "\\seen"; > > from the dovecot-wiki! > > BG jakob > > > &g...

...uot;Junk"; >> >> addflag "\\seen"; >> >> addflag "$label3"; >> >> pipe :copy "learn-spam.sh"; >> >> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; >> >> >> >> When i move an unflagged email to Folder Junk, it is shown in >> Thunderbird >> >> as "personal", Junk but Unseen. >> >> >> >> So, the rule is really working, except for the \\seen-Flag. >> >> >> >> I have the line >> >> >> >&g...

...ddflag "\\seen"; >>>>>> addflag "$label3"; >>>>>> pipe :copy "learn-spam.sh"; >>>>>> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; >>>>>> >>>>>> When i move an unflagged email to Folder Junk, it is shown in >>>> Thunderbird >>>>>> as "personal", Junk but Unseen. >>>>>> >>>>>> So, the rule is really working, except for the \\seen-Flag. >>>>>> >>>>>> I have...

> Le 27 juil. 2019 ? 14:30, Stephan Bosch <stephan at rename-it.nl> a ?crit : > > On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: >> Hello, >> >> I'm having trouble configuring the submission proxy. >> >> I have configured the submission service as follow: >> >> submission_host = smtp.example.com >>

...quot;; >>>>>>> addflag "$label3"; >>>>>>> pipe :copy "learn-spam.sh"; >>>>>>> pipe :copy "learn-spam-sa.sh" [ "${email}" ]; >>>>>>> >>>>>>> When i move an unflagged email to Folder Junk, it is shown in >>>>> Thunderbird >>>>>>> as "personal", Junk but Unseen. >>>>>>> >>>>>>> So, the rule is really working, except for the \\seen-Flag. >>>>>>> >>&gt...

> > > > Show us this "no way to update system properly" to get a clear big picture > that is allowing us to provide you with potentially better solutions. > Thanks really Leon very much w/ a very resourceful info. esp release notes helps across minor versions. So, this is for a friend of mine, and I have been told that they will not currently consider updating their