Problem syncing mail with IMAP

[Odhiambo Washington via dovecot]

I am seeing the following errors in my logs, which I believe are preventing
Outlook from syncing.
How do I solve these?
Can I just delete the index.cache??


Jun 18 11:23:34 imap(techni...@mydomain.co.ke)<59754>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:23:45 imap(sa...@mydomain.co.ke)<59812>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:03 imap(techni...@mydomain.co.ke)<59891>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:24:12 imap(sa...@mydomain.co.ke)<59933>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in  mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:40 imap(sa...@mydomain.co.ke)<60053>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:49 imap(techni...@mydomain.co.ke)<60079>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:25:09 imap(sa...@mydomain.co.ke)<60184>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in  mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:25:13 imap(techni...@mydomain.co.ke)<60204>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:25:42 imap(techni...@mydomain.co.ke)<60328>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:26:03 imap(sa...@mydomain.co.ke)<60358><9ckk3JSLLe7FsVm2>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:26:11 imap(techni...@mydomain.co.ke)<60455>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:26:32 imap(sa...@mydomain.co.ke)<60548>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:26:33 imap(techni...@mydomain.co.ke)<60553>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:26:45 imap(techni...@mydomain.co.ke)<60602>:
Error: Corrupted record in index cache file /var/spool/virtual/

Re: mdbox to Maildir

[Odhiambo Washington via dovecot]

On Tue, 18 Jun 2019 at 01:35, Ralph Seichter via dovecot <
dovecot@dovecot.org> wrote:

> * Odhiambo Washington via dovecot:
>
> > Is it possible? How do I do it for ALL mailboxes?
>
> This has been asked (and answered) recently; see the Dovecot Wiki.
>
> -Ralph
>

Could you kindly point me to the exact article in the wiki, please?


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Problem syncing e-mails with Outlook

[Odhiambo Washington via dovecot]

Hello all,

I am running dovecot- 2.3.5.2 with mdbox storage.
I deleted the dovecot.index* from all my folders, which led to mails not
being displayed.
I rebuilt the indexes for all the users after that, using: doveadm
force-resync -u user@domain "*"

However, the problem now is that Outlook,configured for IMAP, is not able
to sync the mails with the server.
I can login to the server using webmail and I see all the e-mails listed.
However, when I connect outlook, it does not sync all these e-mails.

I am seeing the errors below. Not sure how to fix that.

Jun 18 11:23:34 imap(techni...@mydomain.co.ke)<59754>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:23:45 imap(sa...@mydomain.co.ke)<59812>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:03 imap(techni...@mydomain.co.ke)<59891>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:24:12 imap(sa...@mydomain.co.ke)<59933>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in  mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:40 imap(sa...@mydomain.co.ke)<60053>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:24:49 imap(techni...@mydomain.co.ke)<60079>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:25:09 imap(sa...@mydomain.co.ke)<60184>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in  mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:25:13 imap(techni...@mydomain.co.ke)<60204>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual  size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:25:42 imap(techni...@mydomain.co.ke)<60328>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:26:03 imap(sa...@mydomain.co.ke)<60358><9ckk3JSLLe7FsVm2>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:26:11 imap(techni...@mydomain.co.ke)<60455>:
Error: Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/technical/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 29: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/technical/mdbox/storage/m.1): FETCH BODY[] got too little
data: 131524 vs 772408
Jun 18 11:26:32 imap(sa...@mydomain.co.ke)<60548>: Error:
Corrupted record in index cache file /var/spool/virtual/
mydomain.co.ke/sales/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
UID 25: Broken virtual size in mailbox INBOX: read(/var/spool/virtual/
mydomain.co.ke/sales/mdbox/storage/m.552): FETCH BODY[] got too little
data: 17130 vs 370736
Jun 18 11:26:33 imap(techni...@mydomain.co.ke)<60553>:
Error: Corrupted record in index cache file 

mdbox to Maildir

[Odhiambo Washington via dovecot]

I'd like a way to convert all my mailboxes from mdbox to Maildir.

Is it possible? How do I do it for ALL mailboxes?

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Deleted dovecot.index.*

[Odhiambo Washington via dovecot]

On Mon, 17 Jun 2019 at 21:03, Aki Tuomi  wrote:

>
> > On 17 June 2019 20:55 Odhiambo Washington  wrote:
> >
> >
> >
> >
> >
> > On Mon, 17 Jun 2019 at 20:45, Aki Tuomi via dovecot 
> wrote:
> > >
> > >  > On 17 June 2019 18:59 Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
> > >  >
> > >  >
> > >  > I'm using mdbox.
> > >  >
> > >  > What's the consequence of deleting dovecot.index.* from all folders?
> > >  >
> > >  > All mail gets lost or I can rebuild the indexes and get the mails?
> > >  >
> > >  >
> > >
> > >  You will lose flags, such as \Seen. But mails should come out intact.
> > >
> > >  Aki
> > >
> >
> > Thank you for this fast (and comforting) response.
> >
> > All the previous mails disappeared after I deleted the files. What do I
> need to do to get them back??
> >
> >
> >
> > --
> >
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.",grep ^[^#] :-)
>
> doveadm force-resync -u victim "*"
>


Is there a way to mark all mails older that today as "Read" in all folders?

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Deleted dovecot.index.*

[Odhiambo Washington via dovecot]

On Mon, 17 Jun 2019 at 21:03, Aki Tuomi  wrote:

>
> > On 17 June 2019 20:55 Odhiambo Washington  wrote:
> >
> >
> >
> >
> >
> > On Mon, 17 Jun 2019 at 20:45, Aki Tuomi via dovecot 
> wrote:
> > >
> > >  > On 17 June 2019 18:59 Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
> > >  >
> > >  >
> > >  > I'm using mdbox.
> > >  >
> > >  > What's the consequence of deleting dovecot.index.* from all folders?
> > >  >
> > >  > All mail gets lost or I can rebuild the indexes and get the mails?
> > >  >
> > >  >
> > >
> > >  You will lose flags, such as \Seen. But mails should come out intact.
> > >
> > >  Aki
> > >
> >
> > Thank you for this fast (and comforting) response.
> >
> > All the previous mails disappeared after I deleted the files. What do I
> need to do to get them back??
> >
> >
> >
> > --
> >
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.",grep ^[^#] :-)
>
> doveadm force-resync -u victim "*"
>
> Aki
>


Thank you very very much.

Now off to read again about dbox storage.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Deleted dovecot.index.*

[Odhiambo Washington via dovecot]

On Mon, 17 Jun 2019 at 20:45, Aki Tuomi via dovecot 
wrote:

>
> > On 17 June 2019 18:59 Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
> >
> >
> > I'm using mdbox.
> >
> > What's the consequence of deleting dovecot.index.* from all folders?
> >
> > All mail gets lost or I can rebuild the indexes and get the mails?
> >
> >
>
> You will lose flags, such as \Seen. But mails should come out intact.
>
> Aki
>

Thank you for this fast (and comforting) response.

All the previous mails disappeared after I deleted the files. What do I
need to do to get them back??


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Deleted dovecot.index.*

[Odhiambo Washington via dovecot]

I'm using mdbox.

What's the consequence of deleting dovecot.index.* from all folders?

All mail gets lost or I can rebuild the indexes and get the mails?

Re: Dovecot 2.3 error, FreeBSD 12 in a jail

[Odhiambo Washington via dovecot]

On Sat, 15 Jun 2019 at 07:12, David Mehler via dovecot 
wrote:

> Hello,
>
> I'm trying to get Dovecot going on my system. It's a FreeBSD
> 12.0-RELEASE system and it's running dovecot 2.3 via ports in a jail.
> I'm getting the same error message(s) as in this bug report, which has
> been marked as closed:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225078
>
> Dovecot is not starting at all in this jail when starting with service
> dovecot start. A service dovecot status also reveals the error message
> about /var/run/dovecot/dovecot.conf file, but a doveconf -n does not
> reveal any configuration file issues. I did put a symlink in
> /var/run/dovecot to /usr/local/etc/dovecot/dovecot.conf, this did not
> correct the issue.
>
> Any suggestions welcome.
> Thanks.
> Dave.
>

Hi David,

Your problem must be something to do with your jails on FreeBSD, IMHO.
The FreeBSD port maintainer (Larry Rosenman) is here.
Perhaps he'll be willing to help troubleshoot the jail issue.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

All your approaches are not well thought out.
The best solutions are always the simplest ones.
KISS principle dictates so.

On Thu, 11 Apr 2019 at 15:01, Marc Roos  wrote:

>
> How long have we been using the current strategy? Do we have less or
> more abuse clouds operating?
>
> "Let the others bother with their own problems." is a bit narrow minded
> view. If every one on this mailing list would have this attitude, there
> would be no single answer to your question.
>
>
> -Original Message-
> From: Odhiambo Washington [mailto:odhia...@gmail.com]
> Sent: donderdag 11 april 2019 12:54
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
> Marc,
>
> There is a strategy loosely referred to as "choose your battles well"
> :-)
> If you can, hack the server and dump the 500GB - you'll be using
> resources transferring the 500GB as the other server receives it. Two
> servers wasting resources because you think you are punishing an
> offender!
>
>
> On Thu, 11 Apr 2019 at 13:43,  wrote:
>
>
> Please do not assume anything other than what is written, it is a
> hypothetical situation
>
>
> A. With the fail2ban solution
>- you 'solve' that the current ip is not able to access you
>- it will continue bothering other servers and admins
>- you get the next abuse host to give a try.
>
> B. With 500GB dump
>  - the owner of the attacking server (probably hacked) will notice
> it
> will be forced to take action.
>
>
> If abuse clouds are smart (most are) they would notice that
> attacking my
> servers, will result in the loss of abuse nodes, hence they will
> not
> bother me anymore.
>
> If every one would apply strategy B, the abuse problem would get
> less.
> Don't you agree??
>
>
>
>
>
>
> -Original Message-
> From: Odhiambo Washington
> Sent: donderdag 11 april 2019 12:28
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
>
>
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot
>  wrote:
>
>
>
>
> Say for instance you have some one trying to constantly
> access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any
> password
> * link that account to something like /dev/zero that
> generates
> infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a
> thing.
>
>
>
>
> Instead of being evil, just use fail2ban to address this problem
> :-)
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>
>
>
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

Marc,

There is a strategy loosely referred to as "choose your battles well" :-)
Let the others bother with their own problems.
If you can, hack the server and dump the 500GB - you'll be using resources
transferring the 500GB as the
other server receives it. Two servers wasting resources because you think
you are punishing an offender!


On Thu, 11 Apr 2019 at 13:43, Marc Roos  wrote:

> Please do not assume anything other than what is written, it is a
> hypothetical situation
>
>
> A. With the fail2ban solution
>- you 'solve' that the current ip is not able to access you
>- it will continue bothering other servers and admins
>- you get the next abuse host to give a try.
>
> B. With 500GB dump
>  - the owner of the attacking server (probably hacked) will notice it
> will be forced to take action.
>
>
> If abuse clouds are smart (most are) they would notice that attacking my
> servers, will result in the loss of abuse nodes, hence they will not
> bother me anymore.
>
> If every one would apply strategy B, the abuse problem would get less.
> Don't you agree??
>
>
>
>
>
>
> -Original Message-
> From: Odhiambo Washington
> Sent: donderdag 11 april 2019 12:28
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
>
>
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot
>  wrote:
>
>
>
>
> Say for instance you have some one trying to constantly access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates
> infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a thing.
>
>
>
>
> Instead of being evil, just use fail2ban to address this problem :-)
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
wrote:

>
>
> Say for instance you have some one trying to constantly access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a thing.
>
>
Instead of being evil, just use fail2ban to address this problem :-)

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: /var/run/dovecot/stats-writer) failed: Permission denied

[Odhiambo Washington via dovecot]

On Wed, 10 Apr 2019 at 19:44, @lbutlr via dovecot 
wrote:

> On 10 Apr 2019, at 09:06, @lbutlr via dovecot  wrote:
> > Should I add
> >
> > service stats {
> >  unix_listener stats-writer {
> >  user = dovecot
> >  }
> >  unix_listener stats-reader {
> >  user = dovecot
> >  }
> > }
> >
> > to my dovecot.conf file?
>
> I did this and it appears to have fixed the issue.
>
> Also, the failed message strongly implies that the email was not
> delivered, since it happens on the delivery log line and there is not
> indication in the log that delivery succeeded. However, the message is
> delivered. It might be worth changing the message or still logging the
> actual message delivery?
>
>
I use dovecot-lda for deliveries and would see entries in both Exim (MTA)
and Dovecot log files.

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: /var/run/dovecot/stats-writer) failed: Permission denied

[Odhiambo Washington via dovecot]

On Wed, 10 Apr 2019 at 18:06, @lbutlr via dovecot 
wrote:

>
>
> > On 10 Apr 2019, at 08:57, Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
> >
> >
> >
> > On Wed, 10 Apr 2019 at 17:50, @lbutlr via dovecot 
> wrote:
> > On 10 Apr 2019, at 08:36, @lbutlr via dovecot 
> wrote:
> > > net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission
> den))
> >
> > One other detail:
> >
> > /var/run/dovecot/stats-writer:
> > 0 srw-rw  1 root dovecot 0 Apr 10 08:47 stats-writer
> >
> >
> > Edit your 10-master.conf and make sure that the user specified in the
> details below matches the dovecot user:
> >
> >
> > service stats {
> >   unix_listener stats-writer {
> >   user = mailnull
> >   }
> >   unix_listener stats-reader {
> >   user = mailnull
> >   }
>
> Sorry, i am confused. There is no similar clock in 10-master.conf
>
> In fact,. the string "stats" does not appear in that file at all. The
> commented line
>
> #default_internal_user = dovecot
>
> is in that file, and that is the dovecot user (as seen in the permissions
> above).
>
> Should I add
>
> service stats {
>   unix_listener stats-writer {
>   user = dovecot
>   }
>   unix_listener stats-reader {
>   user = dovecot
>   }
> }
>
> to my dovecot.conf file?
>
>
Add the two blocks to 10-master.conf, before the last "}"

My dovecot runs as user mailnull. YMMV.




-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: /var/run/dovecot/stats-writer) failed: Permission denied

[Odhiambo Washington via dovecot]

On Wed, 10 Apr 2019 at 17:50, @lbutlr via dovecot 
wrote:

> On 10 Apr 2019, at 08:36, @lbutlr via dovecot  wrote:
> > net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission den))
>
> One other detail:
>
> /var/run/dovecot/stats-writer:
> 0 srw-rw  1 root dovecot 0 Apr 10 08:47 stats-writer
>
>
Edit your 10-master.conf and make sure that the user specified in the
details below matches the dovecot user:


service stats {
  unix_listener stats-writer {
  user = mailnull
  }
  unix_listener stats-reader {
  user = mailnull
  }


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: where shall I enforce sieve and quota plugins

[Odhiambo Washington via dovecot]

 MDA== LDA

On Wed, 3 Apr 2019 at 06:20, luckydog xf via dovecot 
wrote:

> Hello, guys,
>
>I'm going to using sieve and quota plugins, but I'm not sure where
> shall I enforce against properly?
>
>I see somebody uses them against 20-imap.conf, 15-lda.conf, or
> 20-lmtp.conf
>
>I use LMTP as MDA, so where is the correct location to call these
> plugins and why?
>
>Thanks,
>
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

IMAP coredumps for one user

[Odhiambo Washington via dovecot]

FreeBSD-12
Dovecot-2.3.5

I am having problems with one use

Mar 25 21:30:12 imap(gau@crownkenya.com)<91364>:
Fatal: master: service(imap): child 91364 killed with signal 6 (core dumped)
Mar 25 21:30:14 imap(gau@crownkenya.com)<2381>:
Fatal: master: service(imap): child 2381 killed with signal 6 (core dumped)
Mar 26 06:29:26 imap(gau@crownkenya.com)<7644><0aVP7faEI/GaTGQE>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:26 imap(gau@crownkenya.com)<8806>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:26 imap(gau@crownkenya.com)<8493>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:26 imap(gau@crownkenya.com)<9412><2qtP7faEIfGaTGQE>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:28 imap(gau@crownkenya.com)<7644><0aVP7faEI/GaTGQE>:
Fatal: master: service(imap): child 7644 killed with signal 6 (core dumped)
Mar 26 06:29:29 imap(gau@crownkenya.com)<10764><7sW+7faEJvGaTGQE>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:31 imap(gau@crownkenya.com)<8806>:
Fatal: master: service(imap): child 8806 killed with signal 6 (core dumped)
Mar 26 06:29:33 imap(gau@crownkenya.com)<8493>:
Fatal: master: service(imap): child 8493 killed with signal 6 (core dumped)
Mar 26 06:29:36 imap(gau@crownkenya.com)<9412><2qtP7faEIfGaTGQE>:
Fatal: master: service(imap): child 9412 killed with signal 6 (core dumped)
Mar 26 06:29:38 imap(gau@crownkenya.com)<10764><7sW+7faEJvGaTGQE>:
Fatal: master: service(imap): child 10764 killed with signal 6 (core dumped)
Mar 26 06:29:57 imap(gau@crownkenya.com)<13285>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:57 imap(gau@crownkenya.com)<19736>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:57 imap(gau@crownkenya.com)<22060>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:29:57 imap(gau@crownkenya.com)<21367>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:30:00 imap(gau@crownkenya.com)<13285>:
Fatal: master: service(imap): child 13285 killed with signal 6 (core dumped)
Mar 26 06:30:00 imap(gau@crownkenya.com)<49026>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 06:30:02 imap(gau@crownkenya.com)<19736>:
Fatal: master: service(imap): child 19736 killed with signal 6 (core dumped)
Mar 26 06:30:05 imap(gau@crownkenya.com)<22060>:
Fatal: master: service(imap): child 22060 killed with signal 6 (core dumped)
Mar 26 06:30:07 imap(gau@crownkenya.com)<21367>:
Fatal: master: service(imap): child 21367 killed with signal 6 (core dumped)
Mar 26 06:30:10 imap(gau@crownkenya.com)<49026>:
Fatal: master: service(imap): child 49026 killed with signal 6 (core dumped)
Mar 26 07:59:40 imap(gau@crownkenya.com)<27221><06UEMPiESPKaRh6E>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 07:59:40 imap(gau@crownkenya.com)<28883>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 07:59:40 imap(gau@crownkenya.com)<29823><28oEMPiESfKaRh6E>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 07:59:40 imap(gau@crownkenya.com)<27530><04UEMPiER/KaRh6E>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 26 07:59:42 imap(gau@crownkenya.com)<27221><06UEMPiESPKaRh6E>:
Fatal: master: service(imap): child 27221 killed with signal 6 (core dumped)
Mar 26 07:59:42 imap(gau@crownkenya.com)<30775>:
Panic: file mempool-system.c: line 137 

Panic

[Odhiambo Washington via dovecot]

Dovecot-2.3.5, FreeBSD-12 (amd64),

I will wait to see coredumps after setting up things to allow it.


Mar 24 20:56:08 imap(john@crownkenya.com)<82746>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 24 20:56:08 imap(john@crownkenya.com)<82746>:
Fatal: master: service(imap): child 82746 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap {
drop_priv_before_
exec=yes })
Mar 24 20:56:08 imap(john@crownkenya.com)<81688>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 24 20:56:08 imap(john@crownkenya.com)<81688>:
Fatal: master: service(imap): child 81688 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap {
drop_priv_before_
exec=yes })
Mar 24 20:56:08 imap(john@crownkenya.com)<82020>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 24 20:56:08 imap(john@crownkenya.com)<82020>:
Fatal: master: service(imap): child 82020 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap {
drop_priv_before_
exec=yes })
Mar 24 20:56:08 imap(john@crownkenya.com)<83452>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 24 20:56:08 imap(john@crownkenya.com)<83452>:
Fatal: master: service(imap): child 83452 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap {
drop_priv_before_
exec=yes })
Mar 24 20:56:08 imap(john@crownkenya.com)<84305><9vV0zdqEzueaTXHr>:
Panic: file mempool-system.c: line 137 (pool_system_realloc): assertion
failed: (old_size == (size_t)-1 || mem == NULL || old_size <=
malloc_usable_size(mem))
Mar 24 20:56:08 imap(john@crownkenya.com)<84305><9vV0zdqEzueaTXHr>:
Fatal: master: service(imap): child 84305 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap {
drop_priv_before_
exec=yes })

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: sieve vacation to an alias group

[Odhiambo Washington via dovecot]

On Wed, 13 Mar 2019 at 11:16, Monis Monther via dovecot 
wrote:

> Hi,
>
> Is there a solution for this? Not necessarily with vacation , even with
> another tool. It feels like this should be a normal use case, but no one
> has a solution to it. Any help would be appreciated.
>
> Thanks
> Monis
>

Look for the solution within your MTA.
Really, what you are looking for has nothing to do with vacation. It's just
an autoresponder which you would do natively within you MTA or use procmail.
The perfect tool though is Request Tracker, which I suggested a few days
ago. Well, I suggested RT just because I am kinda familiar with it. There
are others.

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: sieve vacation to an alias group

[Odhiambo Washington via dovecot]

I think you should run a true ticketing system like RT (
https://bestpractical.com/request-tracker)

On Sun, Mar 10, 2019, 13:40 Monis Monther via dovecot 
wrote:

> Hi Yassine,
>
> Thanks for the effort, unfortunately, we cannot turn it into an actual
> mailbox, this is a long story that I don't want to include here. but it
> would not be a valid option in our environment. Any other ideas
>
> Is it possible to do it with vacation? Is there another auto responder or
> plugin that can achieve this? How do ticketing systems handle this?
>
> Thanks
> Monis
>
> On Sun, Mar 10, 2019 at 11:13 AM Yassine Chaouche via dovecot <
> dovecot@dovecot.org> wrote:
>
>>
>> On 3/10/19 9:07 AM, Yassine Chaouche via dovecot wrote:
>>
>> On 3/9/19 12:41 PM, Monis Monther via dovecot wrote:
>>
>> Hi,
>>
>> We have an alias group named x...@example.com, this alias group has 3
>> actual users a...@example.com, b...@example.com and c...@example.com
>>
>> We set vacation rule on the generic sieve rule, the problem is that 3
>> responses are sent to the original sender. (obviously because the rule is
>> being executed with each user in the alias group)
>>
>> Is it possible to set auto response only once, we tried the ( :days 1)
>> option but still all 3 respond back.
>>
>> How can such a setup be achieved. (Single auto response to an alias group)
>>
>> CentOS 7.5
>> dovecot-pigeonhole-2.3.4.1-1.x86_64
>> dovecot-2.3.4.1-1.x86_64
>> postfix 2.10-1
>>
>>
>> --
>> Best Regards
>> Monis
>>
>> Hello Monis,
>>
>> As a workaround, you can turn x...@example.com into an actual mailbox and
>> give a...@example.com, b...@example.com and c...@example.com read-only shared
>> folder access.
>>
>> Yassine.
>>
>>
>> As a request for comments and improvements, here's a my script to share
>> folders via acl files and symlinks (dovecot must be configured accordingly)
>> :
>>
>> root@messagerie[10.10.10.19] /usr/local/scripts/mail # cat
>> sharemailbox.single
>> #!/bin/bash
>>
>> function create_link {
>> l_src=$1
>> l_dst=$2
>> l_maildir=$3
>> t_maildir=$(echo "$3" | tr . ․)
>> t_dst="$l_dst"/.shared."$t_maildir"
>> echo pointing "$t_dst" to "$l_src"
>> echo ln -s "$l_src/" "$t_dst"
>> ln -s "$l_src/" "$t_dst"
>>
>> }
>>
>>
>> function verifier_email {
>> l_email=$1
>> if ! searchmailbox.strict.sql $l_email > /dev/null
>> then
>> echo "l'utilisateur $l_email n'a pas pu être trouvé dans la base
>> de données." >&2
>> return 1
>> fi
>> return 0
>> }
>>
>> function set_acl {
>> l_maildir=$1
>> l_email=$2
>> echo "giving $l_email access to $l_maildir"
>> if [ ! -d $l_maildir ]
>> then
>> #.Sent isn't there yet.
>> return
>> fi
>> acl_file="$l_maildir/dovecot-acl"
>> echo "echo user=$l_email lr >> $acl_file"
>> echo user="$l_email" lr >> "$acl_file"
>> chown vmail:vmail "$acl_file"
>> }
>>
>>
>> if [ "$#" -lt 2 ]
>> then
>> echo "usage : $0 part...@domain.com us...@domain.com us...@domain.com
>> ... "
>> exit 1
>> fi
>>
>> email="$1"
>> inbox="${email%@*}"
>> domain="${email#*@}"
>> src="/var/vmail/$domain/$inbox"
>> if ! verifier_email "$email"
>> then
>> echo "exit at 1"
>> exit 1
>> fi
>>
>>
>> shift
>> for share_email in $@
>> do
>> if ! verifier_email $share_email
>> then
>> continue
>> fi
>> share_inbox="${share_email%@*}"
>> share_domain="${share_email#*@}"
>> share_maildir=/var/vmail/"$share_domain"/"$share_inbox"
>> #echo grep "$share_email" "$src"/dovecot-acl
>> if grep "$share_email" "$src"/dovecot-acl > /dev/null 2>&1
>> then
>> # then is executed when exit status is 0
>> # exist status is 0 when there is a match
>> echo "$share_email" has already access to "$email"
>> else
>> set_acl $src $share_email
>> create_link $src $share_maildir $inbox
>> fi
>> done
>> root@messagerie[10.10.10.19] /usr/local/scripts/mail #
>>
>>
>
> --
> Best Regards
> Monis
>

Re: sieve vacation to an alias group

[Odhiambo Washington via dovecot]

On Sat, 9 Mar 2019 at 14:41, Monis Monther via dovecot 
wrote:

> Hi,
>
> We have an alias group named x...@example.com, this alias group has 3
> actual users a...@example.com, b...@example.com and c...@example.com
>
> We set vacation rule on the generic sieve rule, the problem is that 3
> responses are sent to the original sender. (obviously because the rule is
> being executed with each user in the alias group)
>
> Is it possible to set auto response only once, we tried the ( :days 1)
> option but still all 3 respond back.
>
> How can such a setup be achieved. (Single auto response to an alias group)
>
> CentOS 7.5
> dovecot-pigeonhole-2.3.4.1-1.x86_64
> dovecot-2.3.4.1-1.x86_64
> postfix 2.10-1
>
>
> --
> Best Regards
> Monis
>

If the whole "group" (alias) isn't on vacation, then why are you doing
this? Let a,b or c activate their rules individually. K.I.S.S principle.

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: migrating/cloning 2.2 > 2.3?

[Odhiambo Washington via dovecot]

On Sun, 3 Mar 2019 at 08:29, Voytek Eymont via dovecot 
wrote:

>
> > 11:30:12 auth-worker(32307): Warning: sqlpool(mysql): Query failed,
> > retrying: Unknown column 'mailbox.enableimaptls' in 'where clause'
> > Mar 03 11:30:12 auth-worker(32307): Error:
> > sql(voy...@sbt.net.au,110.175.246.167,): User query
> > failed: Unknown column 'mailbox.enableimaptls' in 'where clause'
>
> I've found a page with SQL table mods that seems to have fixed some of my
> issues, after modifying SQL, I can log in
>
> Mar 03 16:23:34 master: Info: Dovecot v2.3.4.1 (3c0b8769e) starting up for
> pop3,
>  imap, sieve (core dumps disabled)
> Mar 03 16:23:56 config: Warning: please set ssl_dh= Mar 03 16:23:56 config: Warning: You can generate it with: dd
> if=/var/lib/doveco
> t/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der >
> /etc/dovecot/d
> h.pem
> Mar 03 16:23:57 imap-login: Info: Login: user=,
> method=PLAIN,
>  rip=110.175.246.167, lip=103.106.168.106, mpid=2757, TLS,
> session=<283B2CmDccdu
> r/an>
>
> I'll do the dh.pem next
>
> //these are SQL mods I've done
>
> ALTER TABLE mailbox ADD COLUMN enableimaptls TINYINT(1) NOT NULL DEFAULT 1;
> ALTER TABLE mailbox ADD INDEX (enableimaptls);
> ALTER TABLE mailbox ADD COLUMN enablepop3tls TINYINT(1) NOT NULL DEFAULT 1;
> ALTER TABLE mailbox ADD INDEX (enablepop3tls);
> ALTER TABLE mailbox ADD COLUMN enablesievetls TINYINT(1) NOT NULL DEFAULT
> 1;
> ALTER TABLE mailbox ADD INDEX (enablesievetls);//
>
> --
> Voytek
>
>
What you did is quite practical. All you have to do is:
1. Make sure the static files named in the configs are moved to the
destination server
2. All account names used in Dovecot config are adjusted or created in the
destination server
and the permissions/access levels are right
3. Dump mysql database and import the dump in the destination server
I have done the same before, and just made sure that I went through all the
files in /etc/dovecot/ with
a toothcomb. I've missed one or two things depending on the level of
distraction/concentration (which is
normal), but it always ends up working, especially if the migration is
about the same domain names.
That is how it's supposed to work with virtual users I suppose.
Regarding your MySQL issues, you'll notice that we all have different MySQL
schemas out here, Unless
the one you refer to is the standard one for CentOS, every man to their own
when it comes to virtual users :)


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Assistance with doveadm backup...

[Odhiambo Washington via dovecot]

On Thu, 21 Feb 2019 at 07:11, SH Development via dovecot <
dovecot@dovecot.org> wrote:

> I am having trouble locating examples of how to use doveadm backup.  All
> the examples I see are for sync.  I simply want to create a backup to a
> network volume of the email server's vmail folders.  The goal here is to
> have a reasonably current backup should the main drive on the email server
> go south.
>
> We currently authenticate our users from a mysql database.  User’s
> mailboxes are stored as domainname/username/Maildir
>
> I assume what I will wind up on the network volume is a duplicate
> directory structure as the vmail folder on the email server?
>
> Can someone help get me started here?
>
> Jeff


In my previous life as a SysAdmin, I solved this kind of problem easily
using the MTA.
Exim is my MTA of choice and has a facility to do concurrent delivery to
two storage locations using shadow_transport.
I am guessing your MTA is Postfix (or maybe Sendmail). Try and see if they
have such a capability or switch to Exim.



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Migrate mail data from Dovecot to Dovecot

[Odhiambo Washington via dovecot]

On Tue, 19 Feb 2019 at 11:39, Aki Tuomi  wrote:

>
> > On 19 February 2019 10:38 Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
> >
> >
> > I have built a new server (FreeBSD-12) running dovecot-2.3.4.
> > My old server (FreeBSD-9.3) is running dovecot-2.3.4 as well.
> > The configurations are 1:1 identical.
> > The are about 250 users on this server, all virtual. They are mostly
> POP3 users, but they do "leave a copy of message on the server"
> > for set various number of days.
> >
> > Now, to migrate the mail data, can I simply rsync the mail directories
> between the old and the new server? Would that create a pitfall??
> >
> > What is the recommended method?
> >
> > --
> >
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.",grep ^[^#] :-)
>
> If you are using maildir, rsync should work.
>
>
Thank you.

rsync it is.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Migrate mail data from Dovecot to Dovecot

[Odhiambo Washington via dovecot]

I have built a new server (FreeBSD-12) running dovecot-2.3.4.
My old server (FreeBSD-9.3) is running dovecot-2.3.4 as well.
The configurations are 1:1 identical.
The are about 250 users on this server, all virtual. They are mostly POP3
users, but they do "leave a copy of message on the server"
for set various number of days.

Now, to migrate the mail data, can I simply rsync the mail directories
between the old and the new server? Would that create a pitfall??

What is the recommended method?

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Migrate Mail Data from Dovecot to Dovecot

[Odhiambo Washington via dovecot]

I have built a new server (FreeBSD-12) running dovecot-2.3.4.
My old server (FreeBSD-9.3) is running dovecot-2.3.4 as well.
The configurations are 1:1 identical.
The are about 250 users on this server, all virtual. They are mostly POP3
users, but they do "leave a copy of message on the server"
for set various number of days.

Now, to migrate the mail data, can I simply rsync the mail directories
between the old and the new server? Would that create a pitfall??

What is the recommended method?

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Using SHA256/512 for SQL based password

[Odhiambo Washington via dovecot]

On Sun, 17 Feb 2019 at 11:34, Marc Weustink via dovecot 
wrote:

> Jean-Daniel Dupas via dovecot wrote:
> >
> >
> >> Le 13 févr. 2019 à 14:54, Robert Moskowitz via dovecot
> >> mailto:dovecot@dovecot.org>> a écrit :
> >>
> >>
> >>
> >> On 2/13/19 8:30 AM, Aki Tuomi wrote:
> >>> On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote:
> 
>  On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote:
> >
> > Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz
> > mailto:r...@htt-consult.com>>:
> >
> >> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote:
> >>> Am 12.02.2019 um 17:05 schrieb Robert Moskowitz via dovecot:
>  I have trying to find how to set the dovecot-sql.conf for using
>  SHA256/512.  I am going to start clean with the stronger format,
> not
>  migrate from the old MD5.  It seems all I need is:
> >>> you maybe would like to have a look to the hashing algo ARGON2I
> >>> which is
> >>> currently recommended for new developments and deployments.
> >> Recommended by whom?
> >>
> >> Can you provide a link?
> > Sure, please see here:
> > https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
> >
> >>
> >> And if I was adventurous about hashes, I would be looking more at
> >> Keccak.
> >>
> >>
> >> Check out my Internet Draft:
> >>
> >>
> >> draft-moskowitz-small-crypto-00.txt
> > Thanks for the tip, will have a look for into it.
>  Keccak is a general hashing function.  It was the first? of the
>  hashing 'sponge' functions, that many have followed.  It is the basis
>  of SHA3 (at Keccak's greatest strength).
> 
>  Argon2 seems to be special-built for password hashing.  Thing is it is
>  not supported on my CentOS7 system:
> 
>  # doveadm pw -l
>  MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN
>  CLEAR CLEARTEXT PLAIN-TRUNC CRAM-MD5 SCRAM-SHA-1 HMAC-MD5 DIGEST-MD5
>  PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY RPA PBKDF2 CRYPT
>  SHA256-CRYPT SHA512-CRYPT
> 
>  Of course SHA3 is not listed either...
> 
> 
> >>> ARGON2 support is added in dovecot v2.3. It also needs to be enabled
> >>> when compiling dovecot, so varying from packagers it might or not be
> >>> available. The CRYPT ones are available if crypt(3) supports them. In
> >>> dovecot v2.3 we have added bcrypt support regardless of crypt(3)
> support.
> >>
> >> CentOS7 is on dovecot 2.2.36:
> >>
> >> # doveadm pw -s ARGON2-CRYPT -p secret
> >> Fatal: Unknown scheme: ARGON2-CRYPT
> >> # doveadm pw -s ARGON2 -p secret
> >> Fatal: Unknown scheme: ARGON2
> >>
> >> I tend to stay with the distro's rpms and not take on building and
> >> maintaining myself.
> >
> > And for the record, the hash names are ARGON2I and ARGON2ID (see doveadm
> > pw -l )
> >
> > With dovecot from the dovecot.org  repo:
> >
> > # doveadm pw -s ARGON2I -p secret
> >
> {ARGON2I}$argon2i$v=19$m=32768,t=4,p=1$bt96TSr3nVrho2SRhnNP0A$h7LYiqkw/4s6d1d+0Xpe+VUE3aISPnkYq/R7QqPRntk
>
> Also from dovecot.org  repo:
>
> doveadm pw -s ARGON2I -p secret
> Fatal: Unknown scheme: ARGON2I
>
> 
>
> Marc
>

It works for me over here:

[wash@waridi ~]#/opt/dovecot2.3/bin/doveadm pw -s ARGON2I -p secret
{ARGON2I}$argon2i$v=19$m=32768,t=4,p=1$9pggnQBea9F3h3O31HoJEA$0zZZgwEuMRVZ3Mc/v6ckpalzVRVCr+GLBWnb8OrgsxU


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Release notify (2.2.36.1 and 2.3.4.1)

[Odhiambo Washington via dovecot]

Bueno.

I don't even remember well.

Wasn't that issue about mysql-8.0.12 to 8.0.13??



On Tue, 5 Feb 2019 at 23:46, Larry Rosenman  wrote:

> 2.3.4 had the same compile issues
>
>
> On Tue, Feb 5, 2019 at 2:44 PM Odhiambo Washington 
> wrote:
>
>> Noted.
>>
>> I will wait for dovecot-2.3.4.2 tarball then.
>>
>> In all the servers I listed (+2 more), I never use the mail/dovecot port.
>>
>> I rely on mail/dovecot port on my own prototype (FreeBSD 12) which I have
>> built in preparation for the upgrade of all the servers I currently have
>> (except the 11.2).
>> So for now, they have to run with 2.3.4, because of that reason - I am
>> not using the port. And yes, I know about DESTDIR :-)
>>
>>
>> On Tue, 5 Feb 2019 at 23:35, Larry Rosenman  wrote:
>>
>>> the patches are already in git master.  I've pulled them into the
>>> mail/dovecot port.
>>>
>>> The dovecot guys/gals will release it eventually, but the port works
>>> TODAY.
>>>
>>>
>>> On Tue, Feb 5, 2019 at 2:33 PM Odhiambo Washington 
>>> wrote:
>>>
>>>> I have always been able to compile manually, even from RCs so I believe
>>>> I should be able to compile from the tarball as well.
>>>> Something is broken,
>>>>
>>>> On Tue, 5 Feb 2019 at 23:29, Larry Rosenman  wrote:
>>>>
>>>>> pull the patches from the port.
>>>>>
>>>>>
>>>>> On Tue, Feb 5, 2019 at 2:28 PM Odhiambo Washington via dovecot <
>>>>> dovecot@dovecot.org> wrote:
>>>>>
>>>>>> Oh, so manual compile should NOT work and it's okay or am I missing
>>>>>> something?
>>>>>>
>>>>>> On Tue, 5 Feb 2019 at 23:26, The Doctor 
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Feb 05, 2019 at 11:18:45PM +0300, Odhiambo Washington via
>>>>>>> dovecot wrote:
>>>>>>> > On Tue, 5 Feb 2019 at 20:32, Aki Tuomi via dovecot <
>>>>>>> dovecot@dovecot.org>
>>>>>>> > wrote:
>>>>>>> >
>>>>>>> > > Due to DMARC issues some people have failed to receive the
>>>>>>> latest security
>>>>>>> > > information, so here it is repeated for both releases:
>>>>>>> > >
>>>>>>> > > 2.3.4.1
>>>>>>> > >
>>>>>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz
>>>>>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig
>>>>>>> > > <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig>
>>>>>>> > > Binary packages in https://repo.dovecot.org/
>>>>>>> > >
>>>>>>> > > * CVE-2019-3814: If imap/pop3/managesieve/submission client
>>>>>>> has
>>>>>>> > >   trusted certificate with missing username field
>>>>>>> > >   (ssl_cert_username_field), under some configurations
>>>>>>> Dovecot
>>>>>>> > >   mistakenly trusts the username provided via authentication
>>>>>>> instead
>>>>>>> > >   of failing.
>>>>>>> > > * ssl_cert_username_field setting was ignored with external
>>>>>>> SMTP AUTH,
>>>>>>> > >   because none of the MTAs (Postfix, Exim) currently send the
>>>>>>> > >   cert_username field. This may have allowed users with
>>>>>>> trusted
>>>>>>> > >   certificate to specify any username in the authentication.
>>>>>>> This bug
>>>>>>> > >   didn't affect Dovecot's Submission service.
>>>>>>> > >
>>>>>>> >
>>>>>>> > FreeBSD-11.2 (amd64):
>>>>>>> >
>>>>>>> > gmake[2]: Entering directory
>>>>>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
>>>>>>> > gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib
>>>>>>> -I../../src/lib-dns
>>>>>>> > -I../../src/lib-test -I../../src/lib-settings
>>>>>>> -I../../src/lib-ssl-iostream
>>&g

Re: Release notify (2.2.36.1 and 2.3.4.1)

[Odhiambo Washington via dovecot]

Noted.

I will wait for dovecot-2.3.4.2 tarball then.

In all the servers I listed (+2 more), I never use the mail/dovecot port.

I rely on mail/dovecot port on my own prototype (FreeBSD 12) which I have
built in preparation for the upgrade of all the servers I currently have
(except the 11.2).
So for now, they have to run with 2.3.4, because of that reason - I am not
using the port. And yes, I know about DESTDIR :-)


On Tue, 5 Feb 2019 at 23:35, Larry Rosenman  wrote:

> the patches are already in git master.  I've pulled them into the
> mail/dovecot port.
>
> The dovecot guys/gals will release it eventually, but the port works TODAY.
>
>
> On Tue, Feb 5, 2019 at 2:33 PM Odhiambo Washington 
> wrote:
>
>> I have always been able to compile manually, even from RCs so I believe I
>> should be able to compile from the tarball as well.
>> Something is broken,
>>
>> On Tue, 5 Feb 2019 at 23:29, Larry Rosenman  wrote:
>>
>>> pull the patches from the port.
>>>
>>>
>>> On Tue, Feb 5, 2019 at 2:28 PM Odhiambo Washington via dovecot <
>>> dovecot@dovecot.org> wrote:
>>>
>>>> Oh, so manual compile should NOT work and it's okay or am I missing
>>>> something?
>>>>
>>>> On Tue, 5 Feb 2019 at 23:26, The Doctor 
>>>> wrote:
>>>>
>>>>> On Tue, Feb 05, 2019 at 11:18:45PM +0300, Odhiambo Washington via
>>>>> dovecot wrote:
>>>>> > On Tue, 5 Feb 2019 at 20:32, Aki Tuomi via dovecot <
>>>>> dovecot@dovecot.org>
>>>>> > wrote:
>>>>> >
>>>>> > > Due to DMARC issues some people have failed to receive the latest
>>>>> security
>>>>> > > information, so here it is repeated for both releases:
>>>>> > >
>>>>> > > 2.3.4.1
>>>>> > >
>>>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz
>>>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig
>>>>> > > <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig>
>>>>> > > Binary packages in https://repo.dovecot.org/
>>>>> > >
>>>>> > > * CVE-2019-3814: If imap/pop3/managesieve/submission client has
>>>>> > >   trusted certificate with missing username field
>>>>> > >   (ssl_cert_username_field), under some configurations Dovecot
>>>>> > >   mistakenly trusts the username provided via authentication
>>>>> instead
>>>>> > >   of failing.
>>>>> > > * ssl_cert_username_field setting was ignored with external
>>>>> SMTP AUTH,
>>>>> > >   because none of the MTAs (Postfix, Exim) currently send the
>>>>> > >   cert_username field. This may have allowed users with trusted
>>>>> > >   certificate to specify any username in the authentication.
>>>>> This bug
>>>>> > >   didn't affect Dovecot's Submission service.
>>>>> > >
>>>>> >
>>>>> > FreeBSD-11.2 (amd64):
>>>>> >
>>>>> > gmake[2]: Entering directory
>>>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
>>>>> > gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
>>>>> > -I../../src/lib-test -I../../src/lib-settings
>>>>> -I../../src/lib-ssl-iostream
>>>>> > -DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
>>>>> > -DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
>>>>> > -DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
>>>>> > -DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2
>>>>> > -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall
>>>>> -W
>>>>> > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
>>>>> > -Wchar-subscripts -Wformat=2 -Wbad-function-cast
>>>>> -fno-builtin-strftime
>>>>> > -Wstrict-aliasing=2 -I/usr/local/include   -MT test-event-stats.o
>>>>> -MD -MP
>>>>> > -MF .deps/test-event-stats.Tpo -c -o test-event-stats.o
>>>>> test-event-stats.c
>>>>> > test-event-stats.c: In function 'kill_stats_child':
>>>>> > test-event-

Re: Release notify (2.2.36.1 and 2.3.4.1)

[Odhiambo Washington via dovecot]

I have always been able to compile manually, even from RCs so I believe I
should be able to compile from the tarball as well.
Something is broken,

On Tue, 5 Feb 2019 at 23:29, Larry Rosenman  wrote:

> pull the patches from the port.
>
>
> On Tue, Feb 5, 2019 at 2:28 PM Odhiambo Washington via dovecot <
> dovecot@dovecot.org> wrote:
>
>> Oh, so manual compile should NOT work and it's okay or am I missing
>> something?
>>
>> On Tue, 5 Feb 2019 at 23:26, The Doctor  wrote:
>>
>>> On Tue, Feb 05, 2019 at 11:18:45PM +0300, Odhiambo Washington via
>>> dovecot wrote:
>>> > On Tue, 5 Feb 2019 at 20:32, Aki Tuomi via dovecot <
>>> dovecot@dovecot.org>
>>> > wrote:
>>> >
>>> > > Due to DMARC issues some people have failed to receive the latest
>>> security
>>> > > information, so here it is repeated for both releases:
>>> > >
>>> > > 2.3.4.1
>>> > >
>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz
>>> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig
>>> > > <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig>
>>> > > Binary packages in https://repo.dovecot.org/
>>> > >
>>> > > * CVE-2019-3814: If imap/pop3/managesieve/submission client has
>>> > >   trusted certificate with missing username field
>>> > >   (ssl_cert_username_field), under some configurations Dovecot
>>> > >   mistakenly trusts the username provided via authentication
>>> instead
>>> > >   of failing.
>>> > > * ssl_cert_username_field setting was ignored with external SMTP
>>> AUTH,
>>> > >   because none of the MTAs (Postfix, Exim) currently send the
>>> > >   cert_username field. This may have allowed users with trusted
>>> > >   certificate to specify any username in the authentication.
>>> This bug
>>> > >   didn't affect Dovecot's Submission service.
>>> > >
>>> >
>>> > FreeBSD-11.2 (amd64):
>>> >
>>> > gmake[2]: Entering directory
>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
>>> > gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
>>> > -I../../src/lib-test -I../../src/lib-settings
>>> -I../../src/lib-ssl-iostream
>>> > -DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
>>> > -DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
>>> > -DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
>>> > -DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2
>>> > -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W
>>> > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
>>> > -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime
>>> > -Wstrict-aliasing=2 -I/usr/local/include   -MT test-event-stats.o -MD
>>> -MP
>>> > -MF .deps/test-event-stats.Tpo -c -o test-event-stats.o
>>> test-event-stats.c
>>> > test-event-stats.c: In function 'kill_stats_child':
>>> > test-event-stats.c:101:2: warning: implicit declaration of function
>>> 'kill'
>>> > [-Wimplicit-function-declaration]
>>> >   (void)kill(stats_pid, SIGKILL);
>>> >   ^
>>> > test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in
>>> this
>>> > function)
>>> >   (void)kill(stats_pid, SIGKILL);
>>> > ^
>>> > test-event-stats.c:101:24: note: each undeclared identifier is reported
>>> > only once for each function it appears in
>>> > gmake[2]: *** [Makefile:638: test-event-stats.o] Error 1
>>> > gmake[2]: Leaving directory
>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
>>> > gmake[1]: *** [Makefile:565: install-recursive] Error 1
>>> > gmake[1]: Leaving directory
>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src'
>>> > gmake: *** [Makefile:683: install-recursive] Error 1
>>> >
>>> >
>>>
>>>
>>> Ports wokred for me.
>>>
>>> >
>>> >
>>> > FreeBSD-9.3:
>>> >
>>> > gmake[3]: Entering directory
>>> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1

Re: Release notify (2.2.36.1 and 2.3.4.1)

[Odhiambo Washington via dovecot]

Oh, so manual compile should NOT work and it's okay or am I missing
something?

On Tue, 5 Feb 2019 at 23:26, The Doctor  wrote:

> On Tue, Feb 05, 2019 at 11:18:45PM +0300, Odhiambo Washington via dovecot
> wrote:
> > On Tue, 5 Feb 2019 at 20:32, Aki Tuomi via dovecot 
> > wrote:
> >
> > > Due to DMARC issues some people have failed to receive the latest
> security
> > > information, so here it is repeated for both releases:
> > >
> > > 2.3.4.1
> > >
> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz
> > > https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig
> > > <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig>
> > > Binary packages in https://repo.dovecot.org/
> > >
> > > * CVE-2019-3814: If imap/pop3/managesieve/submission client has
> > >   trusted certificate with missing username field
> > >   (ssl_cert_username_field), under some configurations Dovecot
> > >   mistakenly trusts the username provided via authentication
> instead
> > >   of failing.
> > > * ssl_cert_username_field setting was ignored with external SMTP
> AUTH,
> > >   because none of the MTAs (Postfix, Exim) currently send the
> > >   cert_username field. This may have allowed users with trusted
> > >   certificate to specify any username in the authentication. This
> bug
> > >   didn't affect Dovecot's Submission service.
> > >
> >
> > FreeBSD-11.2 (amd64):
> >
> > gmake[2]: Entering directory
> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
> > gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
> > -I../../src/lib-test -I../../src/lib-settings
> -I../../src/lib-ssl-iostream
> > -DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
> > -DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
> > -DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
> > -DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2
> > -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W
> > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
> > -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime
> > -Wstrict-aliasing=2 -I/usr/local/include   -MT test-event-stats.o -MD -MP
> > -MF .deps/test-event-stats.Tpo -c -o test-event-stats.o
> test-event-stats.c
> > test-event-stats.c: In function 'kill_stats_child':
> > test-event-stats.c:101:2: warning: implicit declaration of function
> 'kill'
> > [-Wimplicit-function-declaration]
> >   (void)kill(stats_pid, SIGKILL);
> >   ^
> > test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in this
> > function)
> >   (void)kill(stats_pid, SIGKILL);
> > ^
> > test-event-stats.c:101:24: note: each undeclared identifier is reported
> > only once for each function it appears in
> > gmake[2]: *** [Makefile:638: test-event-stats.o] Error 1
> > gmake[2]: Leaving directory
> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
> > gmake[1]: *** [Makefile:565: install-recursive] Error 1
> > gmake[1]: Leaving directory
> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src'
> > gmake: *** [Makefile:683: install-recursive] Error 1
> >
> >
>
>
> Ports wokred for me.
>
> >
> >
> > FreeBSD-9.3:
> >
> > gmake[3]: Entering directory
> > '/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
> > gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
> > -I../../src/lib-test -I../../src/lib-settings
> -I../../src/lib-ssl-iostream
> > -DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
> > -DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
> > -DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
> > -DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2 -fstack-protector
> > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes
> > -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2
> > -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2
> > -I/usr/local/include   -MT test-event-stats.o -MD -MP -MF
> > .deps/test-event-stats.Tpo -c -o test-event-stats.o test-event-stats.c
> > test-event-stats.c: In function 'kill_stats_child':
> > test-event-stats.c:101: warning: implicit declaration of function 'kill'
> > test-event-stats.c:101: error: 'SIGKILL' un

Re: Release notify (2.2.36.1 and 2.3.4.1)

[Odhiambo Washington via dovecot]

On Tue, 5 Feb 2019 at 20:32, Aki Tuomi via dovecot 
wrote:

> Due to DMARC issues some people have failed to receive the latest security
> information, so here it is repeated for both releases:
>
> 2.3.4.1
>
> https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz
> https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig
> 
> Binary packages in https://repo.dovecot.org/
>
> * CVE-2019-3814: If imap/pop3/managesieve/submission client has
>   trusted certificate with missing username field
>   (ssl_cert_username_field), under some configurations Dovecot
>   mistakenly trusts the username provided via authentication instead
>   of failing.
> * ssl_cert_username_field setting was ignored with external SMTP AUTH,
>   because none of the MTAs (Postfix, Exim) currently send the
>   cert_username field. This may have allowed users with trusted
>   certificate to specify any username in the authentication. This bug
>   didn't affect Dovecot's Submission service.
>

FreeBSD-11.2 (amd64):

gmake[2]: Entering directory
'/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
-I../../src/lib-test -I../../src/lib-settings -I../../src/lib-ssl-iostream
-DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
-DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
-DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
-DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2
-fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime
-Wstrict-aliasing=2 -I/usr/local/include   -MT test-event-stats.o -MD -MP
-MF .deps/test-event-stats.Tpo -c -o test-event-stats.o test-event-stats.c
test-event-stats.c: In function 'kill_stats_child':
test-event-stats.c:101:2: warning: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
  (void)kill(stats_pid, SIGKILL);
  ^
test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in this
function)
  (void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: note: each undeclared identifier is reported
only once for each function it appears in
gmake[2]: *** [Makefile:638: test-event-stats.o] Error 1
gmake[2]: Leaving directory
'/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
gmake[1]: *** [Makefile:565: install-recursive] Error 1
gmake[1]: Leaving directory
'/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src'
gmake: *** [Makefile:683: install-recursive] Error 1




FreeBSD-9.3:

gmake[3]: Entering directory
'/usr/home/wash/Tools/Dovecot/2.3/dovecot-2.3.4.1/src/lib-master'
gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/lib -I../../src/lib-dns
-I../../src/lib-test -I../../src/lib-settings -I../../src/lib-ssl-iostream
-DPKG_RUNDIR=\""/opt/dovecot2.3/var/run/dovecot"\"
-DPKG_STATEDIR=\""/opt/dovecot2.3/var/lib/dovecot"\"
-DSYSCONFDIR=\""/opt/dovecot2.3/etc/dovecot"\"
-DBINDIR=\""/opt/dovecot2.3/bin"\"   -std=gnu99 -g -O2 -fstack-protector
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2
-Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2
-I/usr/local/include   -MT test-event-stats.o -MD -MP -MF
.deps/test-event-stats.Tpo -c -o test-event-stats.o test-event-stats.c
test-event-stats.c: In function 'kill_stats_child':
test-event-stats.c:101: warning: implicit declaration of function 'kill'
test-event-stats.c:101: error: 'SIGKILL' undeclared (first use in this
function)
test-event-stats.c:101: error: (Each undeclared identifier is reported only
once
test-event-stats.c:101: error: for each function it appears in.)
test-event-stats.c: In function 'test_no_merging2':
test-event-stats.c:361: warning: format '%lu' expects type 'long unsigned
int', but argument 2 has type 'uint64_t'
test-event-stats.c: In function 'test_no_merging3':
test-event-stats.c:387: warning: format '%lu' expects type 'long unsigned
int', but argument 2 has type 'uint64_t'
test-event-stats.c:387: warning: format '%lu' expects type 'long unsigned
int', but argument 4 has type 'uint64_t'
test-event-stats.c:387: warning: format '%lu' expects type 'long unsigned
int', but argument 6 has type 'uint64_t'
test-event-stats.c: In function 'test_merge_events2':
test-event-stats.c:452: warning: format '%lu' expects type 'long unsigned
int', but argument 2 has type 'uint64_t'
test-event-stats.c: In function 'test_skip_parents':
test-event-stats.c:484: warning: format '%lu' expects type 'long unsigned
int', but argument 2 has type 'uint64_t'
test-event-stats.c:484: warning: format '%lu' expects type 'long unsigned
int', but argument 4 has type 'uint64_t'
test-event-stats.c:484: warning: format '%lu' expects type 'long unsigned
int', but argument 6 has type 'uint64_t'