Remove "Duplicate" emails

2018-02-22 Thread @lbutlr
In a quest to remove “duplicate” messages sent to both me and lists I subscribe 
to I came up with this, which I think should clean out my Archive folder, but 
I’ve been unable to get it to work for scanning all on my list-user email.

$ doveadm -f table fetch -u kremels 'hdr.message-id guid uid hdr.x-listname' 
mailbox "Archive" | sort| awk 'cnt[$1]++{if (cnt[$1]==2) print prev[$1]; print} 
{prev[$1]=$0}' |grep -E "[0-9] +$" |awk '{print "doveadm expunge -u kremels 
MAILBOX-GUID "$2" UID "$3}’

X-listname is a header that my list user applies to each message that comes 
from a list, and the output is just text to the screen that I can then run 
manually (I am not confident enough to automatically delete the messages).

I include the X-listname header at the end so that I can exclude lines that 
don’t end in a number, which means the copies sent directly to me are the ones 
expunged and the ones from the list are preserved.

So far so good. But ther are issues.

First, even after expunging a message and running doveadm index -u kremels 
“Archive”, subsequent runs still show the same duplicate messages. 

Second, what I really want to do is run this over ALL the mailboxes, except for 
Junk and Sent but if that is possible I can’t find the right syntax.

-- 
"He has all the virtues I dislike and none of the vices I admire."
Winston Churchill



Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Chris Ross


> On Feb 22, 2018, at 15:21, Josef 'Jeff' Sipek  wrote:
> 
>>  Loading the core file, as described
>>  https://www.dovecot.org/bugreport.html , shows the error in libc
>>  somewhere:
> 
> I read the your other mails in this thread; can you run things as before and
> do a 'bt full' on the core file with the debug-symbol-enabled libdovecot?
> gdb seems to be catching the SIGTRAPs, which is making things a bit confusing.
> 
>> (gdb) bt full
>> #0  __unaligned_load (
>>p=0x617070656e640e6d , size=4)

  No difference there.  I changed the install process to not strip things, and 
manually copied in all of the libs in /usr/local/lib/dovecot again with 
unstripped (I think libtool stripped them, I just rejiggered makefiles and 
install-sh).

  Loading a core from a SEGV shows:

Loaded symbols for /libexec/ld-elf.so.1
#0  __unaligned_load (
p=0x706172736572690a , size=4)
at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:45
45  val = (val << 8) | p[i];
(gdb) bt full
#0  __unaligned_load (
p=0x706172736572690a , size=4)
at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:45
val = 0
i = 0
#1  0x40adb7cc in __unaligned_fixup (uf=0x7fdf110)
at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:78
addr = 
val = 
insn = 3254806592
sig = 
#2  0x40adb5b0 in __sparc_utrap (uf=0x7fdf110)
at /usr/src/lib/libc/sparc64/sys/__sparc_utrap.c:100
sig = 16
#3  0x40a2c1cc in __sparc_utrap_gen () from /lib/libc.so.7
No symbol table info available.
#4  0x40a2c1cc in __sparc_utrap_gen () from /lib/libc.so.7
No symbol table info available.
Previous frame identical to this frame (corrupt stack?)
(gdb) 

(Which as you note below, that address is actually “parseri\n”)

> This address looks like ASCII - "append\x0em", so my theory at the moment
> is:
> 
> (1) something clobbers a pointer
> (2) the CPU attempts to execute a load from the address
> (3) a utrap is generated to handle unaligned load
> (4) the utrap code attempts to emulate the unaligned load
> (5) the CPU fails to access the address since it is bogus, and a SIGSEGV is
>generated
> 
> Now, I'm have no idea why it'd first try to work around the alignment
> requirement before doing a quick sanity check and generating SIGSEGV to
> begin with, but that's my theory based on the info available so far.
> Hopefully, a stack trace from a core file will help.

  Unfortunately it seems not to have.  But, good catch on the pointer value 
there
being ASCII data.  Let me know if you have any other ideas.

  - Chris



Constant IMAP timeouts/dropouts

2018-02-22 Thread H.E.

Hello,

  I've searched and searched for a solution to this problem but 
continue to come up empty.


  I have a very generic setup.  CentOS Linux 7.3.1611 running on AWS.  
  I installed the QMail toaster from here: http://www.qmailtoaster.com/
 ( I had been using Bill Shupp's Qmail Toaster for years and years, but 
he stopped supporting it.)


  As such, I did have to convert my Courier mailboxes to Dovecot (no 
real problem there).


  I'm using Thunderbird client on Windows and Mac.

  I have one user (me) using two vpopmail domains with a total of three 
mailboxes.    Each mailbox has about 20 folders which I tag in 
Thunderbird as "When getting new messages for this account, always check 
this folder".  I might have two or three client machines (at different 
locations) running at once (desktop and two notebooks) all trying to get 
mail.


  The problem is I can't go 5 minutes without Dovecot timing out on me, 
returning an error in Thunderbird: "Login to server failed" and asks to 
"enter new password, cancel, or retry" options, or just hanging.


The only way to get Dovecot back is to bounce both dovecot and the 
network via:


/bin/systemctl restart  dovecot.service ; /bin/systemctl restart network

Then I can resume normal activities for a while.  It got so bad that I 
put the above restarts into a cron job running every 5 minutes. But even 
then the problem persists after a couple of minutes. There's nothing 
else running on this box.


I've already increased both
mail_max_userip_connections = 8000
and:
protocol imap {
  mail_max_userip_connections = 8000
  mail_plugins = " quota imap_quota"
}

By the way, the the identical mailbox and client setup, I never had this 
problem with Courier IMAP.


My dovecot -n is pasted below.

So I'm at a loss on how to fix this.  I have tried adjusting the number 
of cached Thunderbird connections, and that doesn't change anything.


Any help or pointers in the right direction to keep Dovecot connected 
would be most helpful.


Thanks,
-hank

Here is my dovecot -n

# 2.2.24 (a82c823): /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-514.26.2.el7.x86_64 x86_64 CentOS Linux release 
7.3.1611 (Core)

auth_cache_size = 64 M
auth_debug_passwords = yes
auth_mechanisms = plain login digest-md5 cram-md5
first_valid_gid = 89
first_valid_uid = 89
log_path = /var/log/dovecot.log
login_greeting = Dovecot toaster ready.
mail_max_userip_connections = 8000
mail_plugins = " quota"
namespace {
  inbox = yes
  location =
  prefix =
  separator = .
  type = private
}
passdb {
  args = cache_key=%u webmail=127.0.0.1
  driver = vpopmail
}
plugin {
  quota = maildir:ignore=Trash
  quota_rule = ?:storage=0
}
protocols = imap
ssl_cert = 

Re: Panic: data stack: Out of memory when allocating bytes

2018-02-22 Thread Josef 'Jeff' Sipek
On Mon, Jan 29, 2018 at 15:23:28 +0100, Thomas Robers wrote:
> Any idea what the problem could be? Is there anything more i could do
> to encircle the problem? Or perhaps is the information i provided
> uncomplete?

Sorry for the delay... your mail scrolled off the screen in my INBOX and
then I forgot about it.

The good news is that I have a general idea what is happening.  The bad news
is, it's not a trivial fix.  The ACL code is *far* from efficient.  It has
never gotten any real optimizations, so the code is a bit memory hungry.
Your heavy use of acls and shared mailboxes just happens to run that code
enough times that it chews through the 128MB limit.

You could increase the vsz_limit for the imap service [1] to something
higher than 128MB, but that'll eventually break if you create more
mailboxes/share them, and it allows imap processes to use more of the
servers RAM.


If I had the time to work on it, I'd try to implement a replacement acl
format to use instead of vfile.  I'd probably try to base it on top of
dovecot dictionaries [2], so that it could use existing key-value storages.
This should make acl handling faster since the entries could be modified "in
place" (instead of having to reconstruct the whole file)... or at least it
should make it possible to change the acl code to do these improvements.

Then, the acl setting would be as flexible as the acl_shared_dict setting.

Jeff.

[1] https://wiki2.dovecot.org/Services?highlight=(vsz_limit)#Service_limits
[2] https://wiki2.dovecot.org/Dictionary

> Am 25.01.2018 um 16:24 schrieb Thomas Robers:
> > Hi,
> > 
> > Am 24.01.2018 um 23:39 schrieb Josef 'Jeff' Sipek:
> > > It looks like the binaries are stripped.  There should be a "debug"
> > > package
> > > you can install with symbol information.  Then, the backtrace should
> > > be much
> > > more helpful.
> > 
> > I installed the debug package and the backtrace now is:
> > 
> > --- snip ---
> > (gdb) bt full
> > #0  0x7f73f1386495 in raise () from /lib64/libc.so.6
> > No symbol table info available.
> > #1  0x7f73f1387c75 in abort () from /lib64/libc.so.6
> > No symbol table info available.
> > #2  0x7f73f17ab822 in mem_block_alloc (min_size=520) at
> > data-stack.c:356
> >      block = 
> >      prev_size = 
> >      alloc_size = 134217728
> > #3  0x7f73f17abc18 in t_malloc_real (size=,
> > permanent=true) at data-stack.c:415
> >      block = 
> >      ret = 
> >      alloc_size = 520
> > #4  0x7f73f17abdeb in t_malloc0 (size=513) at data-stack.c:468
> >      mem = 
> > #5  0x7f73f17a95dd in p_malloc (buf=0x7f73ebdcef28, size=513) at
> > mempool.h:99
> > No locals.
> > #6  buffer_alloc (buf=0x7f73ebdcef28, size=513) at buffer.c:34
> >      __func__ = "buffer_alloc"
> > #7  0x7f73f17a967b in buffer_create_dynamic (pool= > out>, init_size=512) at buffer.c:143
> >      buf = 0x7f73ebdcef28
> > #8  0x7f73f17a803b in backtrace_get (backtrace_r=0x7ffd0ddd8358) at
> > backtrace-string.c:86
> >      str = 
> > #9  0x7f73f17af1da in default_fatal_finish (type= > out>, status=0) at failures.c:221
> >      backtrace = 
> >      recursed = 1
> > #10 0x7f73f17af766 in i_internal_fatal_handler (ctx=0x7ffd0ddd83a0,
> > format=, args=) at
> > failures.c:718
> >      status = 0
> > #11 0x7f73f1723e11 in i_panic (format=0x1310  > bounds>) at failures.c:306
> >      ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0,
> > timestamp_usecs = 0, log_prefix = 0x0}
> >      args = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
> > 0x7ffd0ddd84a0, reg_save_area = 0x7ffd0ddd83e0}}
> > #12 0x7f73f17ab83a in mem_block_alloc (min_size=512) at
> > data-stack.c:360
> >      block = 
> >      prev_size = 
> >      alloc_size = 134217728
> > #13 0x7f73f17abc18 in t_malloc_real (size=,
> > permanent=false) at data-stack.c:415
> >      block = 
> >      ret = 
> >      alloc_size = 512
> > #14 0x7f73f17abd3b in t_buffer_get (size=512) at data-stack.c:543
> >      ret = 0x0
> > #15 0x7f73f17e1d60 in vstrconcat (str1=0x7f73ebdceeb0
> > "/export/home/imap/b...@tutech.de/Maildir/.bla_blub.foo_bar.John Doe",
> > args=0x7ffd0ddd8550,
> >      ret_len=0x7ffd0ddd8570) at strfuncs.c:183
> >      str = 0x7f73ebdceeb0
> > "/export/home/imap/b...@tutech.de/Maildir/.bla_blub.foo_bar.John Doe"
> >      temp = 
> >      bufsize = 512
> >      i = 
> >      len = 
> >      __func__ = "vstrconcat"
> > #16 0x7f73f17b7d03 in i_strconcat (str1=0x7f73ebdceeb0
> > "/export/home/imap/b...@tutech.de/Maildir/.bla_blub.foo_bar.John Doe")
> > at imem.c:65
> >      temp = 
> >      _data_stack_cur_id = 5
> >      args = {{gp_offset = 8, fp_offset = 48, overflow_arg_area =
> > 0x7ffd0ddd8650, reg_save_area = 0x7ffd0ddd8580}}
> >      ret = 
> >      len = 
> >      __func__ = "i_strconcat"
> > #17 0x7f73f0b1fa39 in 

Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Josef 'Jeff' Sipek
On Tue, Feb 20, 2018 at 19:08:27 -0500, Chris Ross wrote:
> 
>   Apologies first for using two addresses, but I can’t currently read my 
> email at distal.com.  :-)
> 
>   I was previously running dovecot2-2.2.29.1_2 on FreeBSD 11 on sparc64.
>   Trying to debug a problem I was having with one of my clients, I
>   upgraded to dovecot-2.2.33.2_4 on that same server.  However, I cannot
>   connect now, log shows:
> 
...
>   Loading the core file, as described
>   https://www.dovecot.org/bugreport.html , shows the error in libc
>   somewhere:

I read the your other mails in this thread; can you run things as before and
do a 'bt full' on the core file with the debug-symbol-enabled libdovecot?
gdb seems to be catching the SIGTRAPs, which is making things a bit confusing.

> (gdb) bt full
> #0  __unaligned_load (
> p=0x617070656e640e6d , size=4)

This address looks like ASCII - "append\x0em", so my theory at the moment
is:

(1) something clobbers a pointer
(2) the CPU attempts to execute a load from the address
(3) a utrap is generated to handle unaligned load
(4) the utrap code attempts to emulate the unaligned load
(5) the CPU fails to access the address since it is bogus, and a SIGSEGV is
generated

Now, I'm have no idea why it'd first try to work around the alignment
requirement before doing a quick sanity check and generating SIGSEGV to
begin with, but that's my theory based on the info available so far.
Hopefully, a stack trace from a core file will help.

Thanks,

Jeff.

> at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap_align.c:45
>   val = 0
>   i = 0
> #1  0x109f9f6c in __unaligned_fixup (uf=0x7fdee40)
> at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap_align.c:78
>   addr = 
>   val = 
>   insn = 3254807616
>   sig = 
> #2  0x109f9d50 in __sparc_utrap (uf=0x7fdee40)
> at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap.c:100
>   sig = 272013984
> #3  0x1094a10c in __sparc_utrap_gen () from /lib/libc.so.7
> No symbol table info available.
> #4  0x1094a10c in __sparc_utrap_gen () from /lib/libc.so.7
> No symbol table info available.
> Previous frame identical to this frame (corrupt stack?)
> (gdb) 
> 
>   As this is a sparc64, with 8-byte alignment requirements, I’m guessing 
> that’s the issue.  Many a piece of software has failed to respect that and 
> crashed.  But, I’m not sure.
> 
>   Does anyone have any suggestions?  I’ve built it locally (via ports), so if 
> there are compiler options I can/should try, I certainly can try.
> 
>   Thanks…
> 
>  - Chris

-- 
If I have trouble installing Linux, something is wrong. Very wrong.
- Linus Torvalds


Re: lmtp: Couldn't parse DH parameters

2018-02-22 Thread Aki Tuomi
I can't see ssl_dh= Subject: Re: 
lmtp: Couldn't parse DH parameters 
Here's the configuration:

https://pastebin.com/ufyQkaBX

On Monday, February 19, 2018 7:15:31 PM PST @lbutlr wrote:
> On 2018-02-19 (14:08 MST), jorda...@startmail.com wrote:
> > I'm using SSL for dovecot, and dovecot kindly warned me on startup that I
> 
> > needed the ssl_dh parameter, which I specified:
> doveconf -n

Re: lmtp: Couldn't parse DH parameters

2018-02-22 Thread jorda...@startmail.com
Here's the configuration:

https://pastebin.com/ufyQkaBX

On Monday, February 19, 2018 7:15:31 PM PST @lbutlr wrote:
> On 2018-02-19 (14:08 MST), jorda...@startmail.com wrote:
> > I'm using SSL for dovecot, and dovecot kindly warned me on startup that I
> 
> > needed the ssl_dh parameter, which I specified:
> doveconf -n

signature.asc
Description: This is a digitally signed message part.


Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Sami Ketola
> As this is a sparc64, with 8-byte alignment requirements, I’m guessing that’s 
> the issue.  Many a piece of software has failed to respect that and crashed.  
> But, I’m not sure.
> 
>  Does anyone have any suggestions?  I’ve built it locally (via ports), so if 
> there are compiler options I can/should try, I certainly can try.
> 
>  Thanks…

On what specific hardware you are running FreeBSD/sparc64? I have some old Sun 
desktops 
lying around with UltraSPARC-III and UltraSPARC-IIIi processors. Maybe I need 
to power them 
up again so that we can run some tests on big-endian machine ourself.

Sami



Re: Authenticating pam and and sql

2018-02-22 Thread @lbutlr
On 2018-02-22 (10:06 MST), Aki Tuomi  wrote:
> 
> You can use username_filter setting on passdb block since 2.2.30

Excellent! thanks.


username_filter = "!*@*"

looks like the right syntax to put in the driver=pam block.

…yes, that appears to do the job.

-- 
Would you say you worship Satan, or do you simply respect his
no-nonsense approach to discipline?



Re: Authenticating pam and and sql

2018-02-22 Thread Aki Tuomi


 
 
  
   
  
  
   
On 22 February 2018 at 19:03 "@lbutlr" <
krem...@kreme.com> wrote:
   
   

   
   

   
   
When a sql user logs in, dovecot always tries pam first (used for the local users with home directories) which generates a login failure in the log, before trying sql (virtual users) and allowing the user to login.
   
   

   
   
Since all the pam users login as 'user' and all the sql users login as 
'u...@example.com' is it possible to tell dovecot which method to check based on the username pattern?
   
   

   
   
It's not a big deal, but these errors show up when I am checking my maillog for problems, and I can't really exclude them since I do want to see actual login failures.
   
   

   
  
  
   You can use username_filter setting on passdb block since 2.2.30
  
  
   ---
   Aki Tuomi
   
 



Re: preferred way to move an imap folder

2018-02-22 Thread Aki Tuomi


 
 
  
   
  
  
   
On 22 February 2018 at 18:53 "@lbutlr" <
krem...@kreme.com> wrote:
   
   

   
   

   
   
On 2018-02-22 (07:48 MST), 
himbe...@shinymail.de wrote:
   
   

 Hello list.


 


 What is the preferred way to move an imap folder. Lets say an User has.


 


 .maildir/.INBOX.Junk


 


 I want to move this imap folder to:


 


 .maildir/.Junk


 


 Can i just use:


 


 mv .maildir/.INBOX.Junk .maildir/.Junk


 


 and be done with that?

   
   
Yes, but if the mailbox is defined as being under .INBOX it will recreate it.
   
   

   
   

   
   
--
   
   
'But you ain't part of it, are you?' said Granny conversationally. 'You
   
   
try, but you always find yourself watchin' yourself watchin' people, eh?
   
   
Never quite believin' anything? Thinkin' the wrong thoughts?'
   
  
  
   
  
  
   or you can use doveadm mailbox rename
  
  
   ---
   Aki Tuomi
   
 



Authenticating pam and and sql

2018-02-22 Thread @lbutlr
When a sql user logs in, dovecot always tries pam first (used for the local 
users with home directories) which generates a login failure in the log, before 
trying sql (virtual users) and allowing the user to login.

Since all the pam users login as 'user' and all the sql users login as 
'u...@example.com' is it possible to tell dovecot which method to check based 
on the username pattern?

It's not a big deal, but these errors show up when I am checking my maillog for 
problems, and I can't really exclude them since I do want to see actual login 
failures.




Re: preferred way to move an imap folder

2018-02-22 Thread @lbutlr
On 2018-02-22 (07:48 MST), himbe...@shinymail.de wrote:
> 
> Hello list.
> 
> What is the preferred way to move an imap folder. Lets say an User has.
> 
> .maildir/.INBOX.Junk
> 
> I want to move this imap folder to:
> 
> .maildir/.Junk
> 
> Can i just use:
> 
> mv .maildir/.INBOX.Junk .maildir/.Junk
> 
> and be done with that?

Yes, but if the mailbox is defined as being under .INBOX it will recreate it.


-- 
'But you ain't part of it, are you?' said Granny conversationally. 'You
try, but you always find yourself watchin' yourself watchin' people, eh?
Never quite believin' anything? Thinkin' the wrong thoughts?'



Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Chris Ross
(long gdb output, you’ve been warned)

  Okay.  So, the libdovecot shared library in /usr/local was stripped.  
Replaced that, and got farther.  gdb walk below.

  It looks to me like it gets deep into the OS’s vfork/execv where it catches a 
trap/crashes.  Is this a problem I can catch, or something wrong with running 
in gdb?  I notice this is a SIGTRAP, where the binary when run out of gdb gets 
a SIGSEGV, and that’s what a loaded core shows.

  Thanks for any assistance.

- Chris



Breakpoint 3, master_service_exec_config (service=0x4103, 
input=0x7fdf5a8) at master-service-settings.c:125
125 const char **conf_argv, *binary_path = service->argv[0];
(gdb) n
128 (void)t_binary_abspath(_path);
(gdb) n
130 if (!service->keep_environment && !input->preserve_environment) 
{
(gdb) 
131 if (input->preserve_home)
(gdb) 
133 if (input->preserve_user)
(gdb) 
135 if ((service->flags & MASTER_SERVICE_FLAG_STANDALONE) 
!= 0)
(gdb) 
136 
master_service_import_environment("LOG_STDERR_TIMESTAMP");
(gdb) 
140 if (getenv(DOVECOT_PRESERVE_ENVS_ENV) == NULL)
(gdb) 
146 if (input->use_sysexits)
(gdb) 
150 i = 0;
(gdb) 
151 argv_max_count = 11 + (service->argc + 1) + 1;
(gdb) 
152 conf_argv = t_new(const char *, argv_max_count);
(gdb) 
153 conf_argv[i++] = DOVECOT_CONFIG_BIN_PATH;
(gdb) 
154 if (input->service != NULL) {
(gdb) 
158 conf_argv[i++] = "-c";
(gdb) 
159 conf_argv[i++] = service->config_path;
(gdb) 
160 if (input->module != NULL) {
(gdb) 
161 conf_argv[i++] = "-m";
(gdb) 
162 conf_argv[i++] = input->module;
(gdb) 
163 if (service->want_ssl_settings) {
(gdb) 
168 if (input->parse_full_config)
(gdb) 
171 conf_argv[i++] = "-e";
(gdb) 
172 conf_argv[i++] = binary_path;
(gdb) 
173 memcpy(conf_argv+i, service->argv + 1,
(gdb) 
175 i += service->argc;
(gdb) 
177 i_assert(i < argv_max_count);
(gdb) 
178 execv_const(conf_argv[0], conf_argv);
(gdb) p conf_argv
$3 = (const char **) 0x41016e48
(gdb) p conf_argv[0]
$4 = 0x4064f6d8 "/usr/local/bin/doveconf"
(gdb) p *conf_argv
$5 = 0x4064f6d8 "/usr/local/bin/doveconf"
(gdb) s
execv_const (path=0x4064f6d8 "/usr/local/bin/doveconf", argv=0x41016e48)
at execv-const.c:23
23  (void)execv(path, argv_drop_const(argv));
(gdb) p parth
No symbol "parth" in current context.
(gdb) p path
$6 = 0x4064f6d8 "/usr/local/bin/doveconf"
(gdb) s
argv_drop_const (argv=0x41016e48) at execv-const.c:13
13  for (count = 0; argv[count] != NULL; count++) ;
(gdb) p argv
$7 = (const char * const *) 0x41016e48
(gdb) p argv[0]
$8 = 0x4064f6d8 "/usr/local/bin/doveconf"
(gdb) p argv[1]
$9 = 0x4064f708 "-c"
(gdb) p argv[2]
$10 = 0x4104 "/usr/local/etc/dovecot/dovecot.conf"
(gdb) p argv[3]
$11 = 0x4064f710 "-m"
(gdb) p argv[4]
$12 = 0x16ad70 "auth"
(gdb) p argv[5]
$13 = 0x4064f728 "-e"
(gdb) p argv[6]
$14 = 0x7fdfd18 
"/usr/ports/mail/dovecot/work/stage/usr/local/libexec/dovecot/auth"
(gdb) p argv[7]
$15 = 0x0
(gdb) n
15  ret = t_new(char *, count + 1);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
17  ret[i] = t_strdup_noconst(argv[i]);
(gdb) 
16  for (i = 0; i < count; i++)
(gdb) 
18  return ret;
(gdb) 
19  }
(gdb) 

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x4022a380 in ?? ()
(gdb) b argv_drop_const
Breakpoint 4 at 0x405d50b8: file execv-const.c, line 13.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: 
/usr/ports/mail/dovecot/work/stage/usr/local/libexec/dovecot/auth 
Error in re-setting breakpoint 3:
No source file named master-service-settings.c.
Error in re-setting breakpoint 4:
No source file named execv-const.c.

Breakpoint 3, 

replication and .dovecot.lda-dupes

2018-02-22 Thread Patrick Cernko
Hi list,

this question was already posted a few years ago
(https://www.dovecot.org/list/dovecot/2014-November/098585.html). I
already asked the original queriest and he told me, that he never got an
solution or workaround but it was not important enough for him.


When using replication in conjunction with sieve vacations, the
.dovecot.lda-dupes file is not synced with the other server. So when
delivering to both servers (round-robin or randomized), senders might
get more vacation mails than configured as the other server does not
know, that the first one already sent a vacation message.

Is this a bug or intentional? If it is a bug, I hereby ask for a fix,
please.


We are using Dovecot version 2.2.27 on Debian/stretch.
This is dovecot -n (hostnames anonymized):

# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.16 (fed8554)
# OS: Linux 4.9.76.1.amd64-smp x86_64 Debian 9.3
auth_verbose = yes
default_vsz_limit = 2 G
doveadm_password =  # hidden, use -P to show it
doveadm_port = 12345
listen = *
login_log_format_elements = pid=%p user=<%u> method=%m rip=%r lip=%l
mpid=%e %c
mail_attachment_dir = /IMAP/mail/attachments
mail_attachment_fs = sis-queue /IMAP/mail/attachments/queue:posix
mail_home = /IMAP/mail/mailboxes/%u
mail_location = mdbox:~/mdbox
mail_log_prefix = "%s(%u[%p]): "
mail_max_userip_connections = 0
mail_plugins = " notify replication zlib fts fts_squat"
maildir_stat_dirs = yes
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart extracttext
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix =
}
passdb {
  args = /etc/dovecot/ldap.conf
  driver = ldap
}
plugin {
  fts = squat
  fts_autoindex = yes
  fts_squat = partial=4 full=10
  mail_replica = tcp:other-server
  sieve = file:~/sieve;active=~/.dovecot.sieve
  zlib_save = gz
  zlib_save_level = 3
}
postmaster_address = <>
protocols = " imap lmtp sieve"
service aggregator {
  fifo_listener replication-notify-fifo {
mode = 0666
  }
  unix_listener replication-notify {
mode = 0666
  }
}
service anvil {
  client_limit = 2250
}
service auth {
  client_limit = 2447
}
service doveadm {
  inet_listener doveadm-server {
port = 12345
  }
}
service imap-login {
  inet_listener imap {
port = 0
  }
  process_limit = 2047
}
service imap {
  process_limit = 2047
}
service lmtp {
  inet_listener lmtp {
port = 24
  }
}
service pop3-login {
  inet_listener pop3 {
port = 0
  }
  inet_listener pop3s {
port = 0
  }
}
service replicator {
  process_min_avail = 1
  unix_listener replicator-doveadm {
mode = 0666
  }
}
ssl_cert =  +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Multiple SSL-Certificates/Domains setup not working | Solved!

2018-02-22 Thread Travis Dolan
I have gone down a similar path. Certbot uses the Lets Encrypt service to
manage the needed keys. I have found that using the following Bash tool to
manage the creation and validation of the needed certs works great.



We deploy Dovecot to AWS, as such we use userdata scripts to execute the above
mentioned tool



pushd /opt/  
sudo git clone https://github.com/Neilpang/acme.sh.git  
pushd acme.sh  
sudo --preserve-env ./acme.sh --install --accountemail 
domains@.com --certhome /opt/letsencrypt  
export AWS_ACCESS_KEY_ID=${LetsEncryptAccessKey}  
export AWS_SECRET_ACCESS_KEY=${LetsEncryptSecretKey}  
sudo --preserve-env ./acme.sh --issue \  
--dns dns_aws \  
--dnssleep 60 \  
--staging \  
-d mail.yourdomain.com

The above commands perform the following...

\- clone the tool

\- setup the tool

\- export API keys (hard to work around this with IAM only applied to the EC2
instance)

\- run the tool using the Lets Encrypt staging endpoints. This is important
since Lets Encrypt rate limits their production APIs, and since we deploy to
AWS often, we potentially request many certs.

\- the "--dns dns_aws" flag tells the tool to use DNS records to perform the
validation of ownership requests from Let Encrypt. TXT records are added, then
removed to the Hosted Zone of mail.yourdomain.com.

Upon successful execution of the tool both the ".csr", ".key" and fullchain
keys are available for use within Dovecot.

Note: These keys are only valid ~3 months, so this process does need to be
maintained. The author of the tool has included a CRON to aid in this.

Hopefully this help others.

  
On Feb 22 2018, at 10:58 am, Poliman - Serwis  wrote:  

> Could you write step by step how you reach the goal?  

>

>  

>

> 2018-02-22 15:55 GMT+01:00 Gabriel Kaufmann
<[maili...@typoworx.com](mailto:maili...@typoworx.com)>:  

>

>> I've tried to create an certbot SAN-Cert with multiple domain-names and
this worked like a charm using one cert for all! Thanks!

>>

>>  

>>  
>>  
>> Best regards

>>  
>> Gabriel Kaufmann

>

>  
  
  
\--  

>

> _Pozdrawiam / Best Regards  
_

>

> _Piotr Bracha_  



Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Chris Ross
 Okay.  Got to the next bit pretty quickly.:

Breakpoint 4, auth_settings_read (service=0x0, pool=0x4104b020,
   output_r=0x7fdf6d0) at auth-settings.c:522
522 input.module = "auth";
(gdb) n
523 input.service = service;
(gdb) n
524 if (master_service_settings_read(master_service, ,
(gdb) s

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x4022a380 in ?? ()
(gdb)

 So, why did it not step into master_service_settings_read ?  Trying again:

523 input.service = service;
(gdb) s
524 if (master_service_settings_read(master_service, ,
(gdb) list
519
520 i_zero();
521 input.roots = set_roots;
522 input.module = "auth";
523 input.service = service;
524 if (master_service_settings_read(master_service, ,
525  output_r, ) < 0)
526 i_fatal("Error reading configuration: %s", error);
527
528 pool_ref(pool);
(gdb) p input
$1 = {roots = 0x27fbd8, config_path = 0x0, preserve_environment = false,
 preserve_user = false, preserve_home = false, never_exec = false,
 use_sysexits = false, parse_full_config = false, module = 0x16ad70 "auth",
 service = 0x0, username = 0x0, local_ip = {family = 0, u = {ip6 = {
   __u6_addr = {__u6_addr8 = '\0' , __u6_addr16 = {0,
   0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, ip4 = {
   s_addr = 0}}}, remote_ip = {family = 0, u = {ip6 = {__u6_addr = {
 __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0,
   0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, ip4 = {s_addr = 0}}},
 local_name = 0x0}
(gdb) p 
$2 = (struct master_service_settings_input *) 0x7fdf5a8
(gdb) p output_r
$3 = (struct master_service_settings_output *) 0x7fdf6d0
(gdb) p 
$4 = (const char **) 0x7fdf598
(gdb) p error
$6 = 0x10dbd0 "@\005?\204\001"
(gdb) p master_service
$5 = (struct master_service *) 0x4103
(gdb) s

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x4022a380 in ?? ()
(gdb)

 Any ideas here?  I’m not sure where to look next…

 - Chris


> On Feb 22, 2018, at 10:10, Chris Ross  wrote:
> 
> Fancy, while not fun.  :-)  But thanks, that does work.  Doing that, n’ing 
> over calls to strcmp, it failed:
> 
> passdbs_init () at passdb.c:313
> 313   passdb_register_module(_ldap);
> (gdb)
> passdb_register_module (iface=0x280120) at passdb.c:33
> 33old_iface = passdb_interface_find(iface->name);
> (gdb)
> passdb_interface_find (name=0x16fe60 "ldap") at passdb.c:20
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 21struct passdb_module_interface *iface = *ifaces;
> (gdb)
> 23if (strcmp(iface->name, name) == 0)
> (gdb) n
> 20array_foreach(_interfaces, ifaces) {
> (gdb)
> 26return NULL;
> (gdb)
> 27}
> (gdb)
> passdb_register_module (iface=0x280120) at passdb.c:34
> 34if (old_iface != NULL && old_iface->verify_plain == NULL) {
> (gdb)
> 37} else if (old_iface != NULL) {
> (gdb)
> 41array_append(_interfaces, , 1);
> (gdb)
> 42}
> (gdb)
> 

Re: Auth SEGV on sparc64, alignment problem?

2018-02-22 Thread Chris Ross
  Fancy, while not fun.  :-)  But thanks, that does work.  Doing that, n’ing 
over calls to strcmp, it failed:

passdbs_init () at passdb.c:313
313 passdb_register_module(_ldap);
(gdb) 
passdb_register_module (iface=0x280120) at passdb.c:33
33  old_iface = passdb_interface_find(iface->name);
(gdb) 
passdb_interface_find (name=0x16fe60 "ldap") at passdb.c:20
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
21  struct passdb_module_interface *iface = *ifaces;
(gdb) 
23  if (strcmp(iface->name, name) == 0)
(gdb) n
20  array_foreach(_interfaces, ifaces) {
(gdb) 
26  return NULL;
(gdb) 
27  }
(gdb) 
passdb_register_module (iface=0x280120) at passdb.c:34
34  if (old_iface != NULL && old_iface->verify_plain == NULL) {
(gdb) 
37  } else if (old_iface != NULL) {
(gdb) 
41  array_append(_interfaces, , 1);
(gdb) 
42  }
(gdb) 
passdbs_init () at passdb.c:314
314 passdb_register_module(_sql);
(gdb) 
315 passdb_register_module(_sia);
(gdb) 
316 passdb_register_module(_static);
(gdb) 
317 passdb_register_module(_oauth2);
(gdb) 
318 }
(gdb) 
main_preinit () at main.c:186
186 userdbs_init();
(gdb) 
188 password_schemes_init();
(gdb) 
190 services = read_global_settings();
(gdb) 

Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x4022a380 in ?? ()
(gdb) 
Cannot find bounds of current function
(gdb) 

  Next step I’ll stop before that and be more careful about n’ing things, but.  
Just passing on context while I have it.

  Thanks.  More later.

   - Chris

> On Feb 22, 2018, at 02:25, Aki Tuomi  wrote:
> 
> Hi!
> 
> Unfortunately we do not have a Sparc64 with any OS at hand. Maybe you could 
> 
> break main
> r
> s
> 
> until it breaks?
> 
> Aki
> 



Re: Multiple SSL-Certificates/Domains setup not working | Solved!

2018-02-22 Thread Poliman - Serwis
Could you write step by step how you reach the goal?

2018-02-22 15:55 GMT+01:00 Gabriel Kaufmann :

> I've tried to create an certbot SAN-Cert with multiple domain-names and
> this worked like a charm using one cert for all! Thanks!
>
>
> Best regards
>
> Gabriel Kaufmann
>
>


-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*


Re: Multiple SSL-Certificates/Domains setup not working | Solved!

2018-02-22 Thread Gabriel Kaufmann
I've tried to create an certbot SAN-Cert with multiple domain-names and 
this worked like a charm using one cert for all! Thanks!



Best regards

Gabriel Kaufmann



preferred way to move an imap folder

2018-02-22 Thread himbeere

Hello list.

What is the preferred way to move an imap folder. Lets say an User has.

.maildir/.INBOX.Junk

I want to move this imap folder to:

.maildir/.Junk

Can i just use:

mv .maildir/.INBOX.Junk .maildir/.Junk

and be done with that?

thanks and cheers
t.



"Stale mailbox lock file detected, will override in 0 seconds"

2018-02-22 Thread Raffaele Gambelli
Hi all dovecot members,

I've received this notice from a dovecot server: "Stale mailbox lock file 
detected, will override in 0 seconds"

I would like to know what it means.

I've implemented a "Mail Proxy Server" in java, which connects to many accounts 
and folders, listening for incoming messages or deleted one, it uses the IMAP 
protocol.
I received that message only 5 times in 60 days of logs, last time, in the same 
time lapse my server has not received three messages, saying differently, the 
listener (I'm using Javamail which works fine) has not be notified about those 
new threee messages.

So, I would like to find a link between the above dovecot message and the 
"black-out" which I had, could you help me please?

Thanks, bye

Raffaele Gambelli
WebRainbow® Software Analyst & Developer





Re: exim dovecot sieve

2018-02-22 Thread himbeere

On 2018-02-21 19:37, Larry Rosenman wrote:

I use lmtp with exim.


Thanks for that pointer. Works fine now.

cheers
t.


Sent from my T-Mobile 4G LTE Device

 Original message 
From: himbe...@shinymail.de
Date: 2/21/18 11:59 AM (GMT-06:00)
To: dovecot@dovecot.org
Subject: exim dovecot sieve

Hello list.

I have just a generic question. Exim delivers fine to dovecot-lda. My
problems are the logfiles. Whenever I recieve a message
Exim writes to dovecot.log as the user who recieves the mail. This
forces me to have that logfile world writeable. I don't
really like that. How do you guys deal with that? Here my transport:

dovecot_delivery:
   driver = pipe

   # You may or may not want to add -d $local_part@$domain depending
on
if you need a userdb lookup done.
   command = /usr/libexec/dovecot/dovecot-lda -f $sender_address

   message_prefix =
   message_suffix =
   log_output
   delivery_date_add
   envelope_to_add
   return_path_add
   #group = mail
   #mode = 0660
   temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78

thanks and best regards
t.