<div dir="ltr">No reason to tell me about security, I just need chmod for my tests. Where to change it ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 25, 2018 at 12:00 PM,  <span dir="ltr"><<a href="mailto:dovecot-request@dovecot.org" target="_blank">dovecot-request@dovecot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send dovecot mailing list submissions to<br>
        <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://dovecot.org/mailman/listinfo/dovecot" rel="noreferrer" target="_blank">https://dovecot.org/mailman/<wbr>listinfo/dovecot</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:dovecot-request@dovecot.org">dovecot-request@dovecot.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:dovecot-owner@dovecot.org">dovecot-owner@dovecot.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of dovecot digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Panic: data stack: Out of memory when allocating bytes<br>
      (Josef 'Jeff' Sipek)<br>
   2. Re: 777 permissions on mailbox, subfolders subfiles new<br>
      emails (Nikolai Lusan)<br>
   3. Re: problem with lda (Stephan Bosch)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 24 Jan 2018 17:39:36 -0500<br>
From: Josef 'Jeff' Sipek <<a href="mailto:jeff.sipek@dovecot.fi">jeff.sipek@dovecot.fi</a>><br>
To: Thomas Robers <<a href="mailto:robers@tutech.de">robers@tutech.de</a>><br>
Cc: <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a><br>
Subject: Re: Panic: data stack: Out of memory when allocating bytes<br>
Message-ID: <20180124223936.GE14966@meili><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote:<br>
> Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek:<br>
> > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote:<br>
> > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote:<br>
...<br>
> > > 1. Do you have any idea what the imap process was doing at the time of the<br>
> > >     allocation failure?<br>
><br>
> Yes perhaps. We use shared mailboxes and at the time of failure the<br>
> imap process is reading acl files in a shared mailbox (and subfolder).<br>
> This shared mailbox has about 2800 subfolder and the acl files are read<br>
> in about 10sec and and during this reading the imap process dies with<br>
> the already mentioned error. It seems it has something to do with the<br>
> shared mailbox, because since yesterday morning 5 core dumps have been<br>
> created, 4 of them by one user accessing the shared mailbox and 1<br>
> by the user who is the owner of the shared mailbox. No other mailboxes<br>
> are affected until now.<br>
<br>
Based on the stack trace, the client was creating a new mailbox, which<br>
caused an acl list rebuild, which ended up triggering this oddly sized<br>
allocation.<br>
<br>
> > > 2. You snipped all the important parts of the back trace. :)  It *starts* on<br>
> > >     the line:<br>
> > >   #0  0x00007f73f1386495 in raise () from /lib64/libc.so.6<br>
> ><br>
> > In case you haven't used gdb before...  after starting up gdb, run "bt full"<br>
> > at the gdb prompt.  That'll print out a very detailed backtrace.  (You might<br>
> > want to sanity check it to make sure there aren't any user passwords in it<br>
> > before posting it here...)<br>
><br>
> Yes, sorry I'm not very familiar in using gdb, but here is the full<br>
> backtrace:<br>
<br>
It looks like the binaries are stripped.  There should be a "debug" package<br>
you can install with symbol information.  Then, the backtrace should be much<br>
more helpful.<br>
<br>
> > >     Having the backtrace should help answer question number 1.<br>
> > > 3. How big is this process when it dies?<br>
><br>
> I don't know which imap process dies beforehand so how do i get this<br>
> information?<br>
<br>
The size of the core file will give you an general idea.  gdb can also print<br>
out lots of info via "maintenance info sections", but I don't think that'll<br>
help figuring out why things blow up.<br>
<br>
Jeff.<br>
<br>
--<br>
Keyboard not found!<br>
Press F1 to enter Setup<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 25 Jan 2018 13:09:40 +1000<br>
From: Nikolai Lusan <<a href="mailto:nikolai@lusan.id.au">nikolai@lusan.id.au</a>><br>
To: <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a><br>
Subject: Re: 777 permissions on mailbox, subfolders subfiles new<br>
        emails<br>
Message-ID: <<a href="mailto:1516849780.4714.5.camel@lusan.id.au">1516849780.4714.5.camel@<wbr>lusan.id.au</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi,<br>
<br>
On Thu, 2018-01-25 at 00:35 +0200, Matthew Brown wrote:<br>
> What I have to change, so dovecot on new email create, sets chmod 777 on<br>
> Mailbox and all subfolders subfiles all new emails/sent emails etc.<br>
<br>
This is a really bad idea. It is possible to setup in dovecot if you're<br>
using dovecot as your LDA. The only reason I can think of for anything<br>
close to this is virtual mailboxes ... and even then I set things up with a<br>
specific user to own the files and set them as 770 for the directories and<br>
660 for the files. With that setup dovecot limits users to their own mail<br>
directories with values returned via the passdb/userdb.<br>
<br>
As a general rule anything on a *nix system that is chmod 777 is to be<br>
avoided - it's a massive security risk.<br>
<br>
- --<br>
Nikolai Lusan <<a href="mailto:nikolai@lusan.id.au">nikolai@lusan.id.au</a>><br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxd<wbr>Lo4ZaDRV2VL6QFAlppSnQACgkQ4ZaD<wbr>RV2V<br>
L6To/<wbr>BAAjKeTi6reaRrcSClKm6PEbgewtF1<wbr>KvHgO1zr+hv9T2XOnVGFSajeFwSXR<br>
rDSXGQ/<wbr>H9s97KDGZB4VKxuSKZsDRFkF9u7ILt<wbr>tuXOgj8kG8XZl4sqg/w0FIrTC1K<br>
GD8T0TZWSJGFIzrLXTpgzoO1LeQXIu<wbr>XgnZIMbcaneCHKZc1do/<wbr>GwQ4DEFVdUnxRJ<br>
n+76nbs8RdQwZKGXYGGTU/<wbr>BXPniTSW1pmTFxnlruxE7fuWBYeEyQ<wbr>GQRke/CT2rFF<br>
ET+<wbr>d7LlV4Nds6eGjalyf7m5tCNS87Zm78<wbr>xegANuMNaMdzPI8NlbnFO82bAlC7kP<wbr>/<br>
WkCFSfhJL3s9daEnMWT/<wbr>dxY2lNKy3kTyOZssXM6ROkNhOFRipN<wbr>wRr77tO6qzu8l9<br>
pvaVxr8a0pMVQwxGAyW84vS9GWmeMN<wbr>MMiY0k7XdPSBS/<wbr>6CVlQm8eUhnDo6GFZoH9<br>
Tbn4XNkEKysbZEjImjXb6eQpRwQLni<wbr>IULjeyoX8aqmN2sh4kDndLJwjxpz7J<wbr>d6v2<br>
j2tuS7+<wbr>79G9qU8dqpCSwzvWYTteOLJeqJLy6s<wbr>5F+zf8FHGLcHdNasoo+/Sdzg4+E<br>
tZm31wp7iQdzKMwbOnRk9FceYXbb9W<wbr>jxI1QY+7U11Rx25y44UDPzUYYOL+<wbr>ZoWOXJ<br>
zAr/F9fhUP/<wbr>u8AubOgOn6BLaguiWcFK0g6HhCqDkV<wbr>AUibEMzC+0=<br>
=YUek<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 25 Jan 2018 09:35:57 +0100<br>
From: Stephan Bosch <<a href="mailto:stephan@rename-it.nl">stephan@rename-it.nl</a>><br>
To: Infoomatic <<a href="mailto:infoomatic@gmx.at">infoomatic@gmx.at</a>>, <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a><br>
Subject: Re: problem with lda<br>
Message-ID: <<a href="mailto:2544728b-5441-c163-34fd-bd155e28f591@rename-it.nl">2544728b-5441-c163-34fd-<wbr>bd155e28f591@rename-it.nl</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Op 1/24/2018 om 5:30 PM schreef Infoomatic:<br>
> Hello,<br>
><br>
> I am currently testing the upgrade from our dovecot v2.2.23 to 2.3.0. I have a strange problem with lda.<br>
> We use bounce mails for internal users if they try to send virus/spammails. The exact same config works with 2.2.23, but not with 2.3.0.<br>
><br>
> The relevant postfix/<a href="http://master.cf" rel="noreferrer" target="_blank">master.cf</a> part:<br>
> dovecot   unix  -       n       n       -       -       pipe<br>
>   flags=DRhu user=vmail:vmail argv=/opt/dovecot/libexec/<wbr>dovecot/deliver -d ${recipient} -f ${sender}<br>
><br>
> On the same machine, with 2.2.23 I get a bounce mail when trying to send a virus, with the subject "VIRUS in message apparently from you (Eicar-Test-Signature)", to both the users inbox as well as to the mailbox of virusalert@ourdomain.internal<br>
><br>
> With 2.3.0, in the logs I get an error:<br>
><br>
> relay=dovecot, delay=0.01, delays=0/0/0/0, dsn=5.3.0, status=bounced (command line usage error. Command output: lda: Fatal: Invalid -f parameter: Missing domain<br>
><br>
> and the alert message is only sent to virusalert@ourdomain.internal, but not to the user who tried to send the mail.<br>
><br>
> The relevant part of our dovecot.conf:<br>
> protocol lda {<br>
>   mail_plugins = " quota zlib sieve acl mail_log notify"<br>
>   postmaster_address = postmaster@ourdomain.internal<br>
> }<br>
><br>
> Does anyone know how to solve this problem? Or is there a workaround via postfix/amavis/spamassassin? Any hints are highly appreciated, thanks!<br>
<br>
Apparently, the ${sender} has no @domain part. Why?<br>
<br>
Regards,<br>
<br>
Stephan.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
dovecot mailing list<br>
<a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a><br>
<a href="https://dovecot.org/mailman/listinfo/dovecot" rel="noreferrer" target="_blank">https://dovecot.org/mailman/<wbr>listinfo/dovecot</a><br>
<br>
------------------------------<br>
<br>
End of dovecot Digest, Vol 177, Issue 55<br>
******************************<wbr>**********<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><img src="http://cs.wos.lv/templates/images/wos_logo.png">zxzzzzzzzzzzzzz<img src="http://c-s.net.ua/forum/head/csnetua-logo.png"><img src="http://img.foreca.net/i/l/foreca_logo.png"><br></div></div></div></div></div></div>
</div>