similar to: /usr/lib/dovecot/imap exits with an error if stderr closed

Hi My toy mail server runs dovecot. My client is mutt, which I use normally use a a remote screen session. I normally connect to imap locally: account-hook imap://localhost/ 'set tunnel="/usr/local/bin/imap-local"' After a long frustration from the new mail notification in 0.99, I have decided to bite the bullet and try the -test series. Ever since I have not had stable mutt

Dear Dovecot experts, I'm in the process of setting up dovecot with mbsync as a local cache for remote IMAP servers. One recipe that I found involves using the /usr/lib/dovecot/imap (This is with Debian's dovecot package). For example, in .mbsyncrc I have IMAPAccount cwg-wf-local RequireSSL no Tunnel "/usr/lib/dovecot/imap -o mail_location=maildir:/home/cwg/.mail/cwg-wf"

On Mon, Sep 28, 2015 at 10:29:16AM +0200, Erwan Velu wrote: > Just looking at the code and the description of it, for me the current code > looks wrong and the proposed patch correct for the following reason: > > The while loop is made for insuring that *source is valid but just after > shift the pointer by one. > This new position isn't tested and so we are addressing an

* Victor Sudakov <vas at mpeks.tomsk.su> 2018.09.26 12:17: > > >> However, I often read and modify the mailboxes locally with Mutt (e.g. > > >> append and delete mails). Why not use Mutt's IMAP capabilities and keep the indexes nice and clean? Regards Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:

What I do is keep my passwords in a file encrypted by GPG and have mutt do: source "gpg -q --textmode -d ~/.neomutt/passwords.gpg |" that way they're not readable except by use of a passworded GPG key. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx at gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX

Erwan, could you shed some light on this? Was the behavior intentional? If not, I think it might prove more useful down the road to commit this patch. Original code in commit ID 85d9a1a -- -Gene On Sat, May 16, 2015 at 3:30 AM, Josh Triplett via Syslinux <syslinux at zytor.com> wrote: > Check if the first character matches the character to replace, rather > than skipping it and

On Mon, Oct 21, 2013 at 7:34 PM, Josh Triplett <josh at joshtriplett.org> wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the >

On Mon, Oct 21, 2013 at 7:34 PM, Josh Triplett <josh at joshtriplett.org> wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the >

On Mon, Dec 16, 2013 at 06:23:38AM -0800, Josh Triplett wrote: > On Mon, Dec 16, 2013 at 04:54:08PM +0530, Rashika Kheria wrote: > > Mark the function virtballoon_migratepage() as static in > > virtio_balloon.c because it is not used outside this file. > > > > This eliminates the following warning in virtio_balloon.c: > > drivers/virtio/virtio_balloon.c:372:5:

On Mon, Dec 16, 2013 at 06:23:38AM -0800, Josh Triplett wrote: > On Mon, Dec 16, 2013 at 04:54:08PM +0530, Rashika Kheria wrote: > > Mark the function virtballoon_migratepage() as static in > > virtio_balloon.c because it is not used outside this file. > > > > This eliminates the following warning in virtio_balloon.c: > > drivers/virtio/virtio_balloon.c:372:5:

On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote: > On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote: > > --- a/arch/x86/kernel/process-io.h > > +++ b/arch/x86/kernel/process-io.h > > @@ -1,9 +1,17 @@ > > #ifndef _X86_KERNEL_PROCESS_IO_H > > #define _X86_KERNEL_PROCESS_IO_H > > > > +static inline void

On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote: > On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote: > > --- a/arch/x86/kernel/process-io.h > > +++ b/arch/x86/kernel/process-io.h > > @@ -1,9 +1,17 @@ > > #ifndef _X86_KERNEL_PROCESS_IO_H > > #define _X86_KERNEL_PROCESS_IO_H > > > > +static inline void

Some kernel images use the Linux kernel boot protocol and header structure, but do not actually have any protected-mode code. For instance, grub's 1024-byte lnxboot.img consists of 1024 real-mode bytes and 0 protected-mode bytes; you can concatenate it with a full grub core.img to produce a self-contained bootable kernel, but you can also use it standalone as the kernel with the core.img

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > The 32-bit and 64-bit versions of copy_thread have functionally > identical handling for copying the I/O bitmap, modulo differences in > error handling. Clean up the error paths in both by moving the copy of > the I/O bitmap to the end, to eliminate the need

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > The 32-bit and 64-bit versions of copy_thread have functionally > identical handling for copying the I/O bitmap, modulo differences in > error handling. Clean up the error paths in both by moving the copy of > the I/O bitmap to the end, to eliminate the need

Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then

Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then

Hi all, I have recently migrated my mail from courier-imap to dovecot. In doing so, I finally configured mutt to connect to imaps (SSL). In the end I got it all working. I then sat back and thought: "I kinda don't understand the SSL/TLS part even though it works". And I hate setting stuff up and not truely understanding the mechanics of it. So I started to write about it and am

Thomas Leuxner wrote: > > > > >> However, I often read and modify the mailboxes locally with Mutt (e.g. > > > >> append and delete mails). > > Why not use Mutt's IMAP capabilities and keep the indexes nice and clean? Maybe the only reason is that I don't want to bother with authentication and don't want to keep my password in muttrc. Anyway,

Hi, I'm running dovecot 1.2.15, on Debian squeeze. /var/mail is owned by group "mail" with permissions "g+rwxs,o=". The mail_privileged_group setting is set to "mail". I am trying to access mail on a remote machine with mutt by tunnelling mutt though ssh and running `dovecot --exec-mail imap` on the mail server. But I frequently get errors in the mail