Re: regarding ssl certificates

[Joseph Tam via dovecot]

On Thu, 14 Mar 2019, John Tulp wrote:


Encryption is just really not that much of a barrier any more.


Spoken like someone who hasn't actually tried breaking any of these
algorithms.  It's not like every, or event most, cryptologists who
designs these algorithms, or analyzes them for weaknesses, are in the
pocket of the NSA or private interests.  Lots of people try really,
really hard to find even the slightest flaw.

If you're saying it's easier to do an end-run around it, then yes, but
that just emphasizes breaking encryption is much harder than alternate
methods.

Gary wrote:


Is there some reason to use a mail.domain.com cert for mail rarher than
just using domain.com for everything?


If you want all your SSL enabled services tied to one fully-qualified
domain name, then sure.

Even if you have a single swiss-army knife server, you may still want to
use multiple-service names for flexibility.  For example, you may want
to scale out in the future by offloading/autsourcing to another server.
You may want to transition to a replacement platform without having to
migrate all your services in one fell swoop.

Having service hostnames allow you to dissociate a service from the
server's hostname.

Michael A. Peters writes:


With SMTP, the hostname should match the reverse IP though often it
does not.


In the context of certificate authenticity, a forward DNS mapping
suffices.  Even for spam scoring, FcRDNS is only a weak inference to
authenticity.

Joseph Tam 

lua policy for Weakforce and web mail failed login attempts

[Robert Kudyba via dovecot]

The good news is I believe I got Weakforce running
1) curl -X GET http://127.0.0.1:8084/?command=ping -u wforce:ourpassword
{"status":"ok"}[

2) after running the sample for loop:
for a in {1..101};   do curl -X POST -H "Content-Type:
application/json" --data '{"login":"ahu", "remote": "127.0.0.1",
"pwhash":"1234'$a'", "success":"false"}'
http://127.0.0.1:8084/?command=report -u wforce:ourpassword;   done

The result is:

{"status":"ok"}{"status":"ok"}{"status":"ok"}{

3) So checking the stats:

curl -X POST -H "Content-Type: application/json" --data
'{"ip":"127.0.0.1"}' http://127.0.0.1:8084/?command=getDBStats -u
wforce:ourpassword

{"bl_expire": "", "bl_reason": "", "blacklisted": false, "ip": "127.0.0.1",
"stats": {"OneHourDB": {"diffFailedPasswords": 93}}}

Notice the 93.

4) the reset works but I believe there's a bug in Getdbstats v2.0.0 where
"blacklisted" is always shown:
curl -X POST -H "Content-Type: application/json" --data
'{"ip":"127.0.0.1"}' http://127.0.0.1:8084/?command=getDBStats -u
wforce:ourpassword

{"bl_expire": "", "bl_reason": "", "blacklisted": false, "ip": "127.0.0.1",
"stats": {"OneHourDB": {"diffFailedPasswords": 0}}}[

5)
wforce -c
Read configuration from '/usr/local/etc/wforce.conf'
Connecting to 127.0.0.1:4004
> stats()
101 reports, 0 allow-queries (0 denies)

The 3 big questions I have:
a: how do I know IP's are being banned/rejected? Is there an alert creation
or a way to see in the logs that the rules are in affect?
b: since I installed via Git and ran "make" how to I get wforce --daemon to
start on reboot? Is there a systemd file available?
c: How do I create a lua policy that would catch these web dovecot login
attempts?

Feb 27 08:19:53 ourserver auth[15085]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 08:19:53 ourserver auth[15085]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
u...@ourserver.ourdomain.edu rhost=177.72.0.158
Feb 27 08:20:35 ourserver auth[15085]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 08:20:35 ourserver auth[15085]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=user
rhost=213.156.111.236
Feb 27 08:27:07 ourserver auth[16831]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 08:27:07 ourserver auth[16831]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
nob...@ourserver.ourdomain.edu rhost=79.106.35.59
Feb 27 08:27:27 ourserver auth[16831]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=nobody
rhost=95.38.212.65  user=nobody
Feb 27 08:27:27 ourserver auth[16831]: pam_succeed_if(dovecot:auth):
requirement "uid >= 1000" not met by user "nobody"
Feb 27 08:31:12 ourserver auth[17875]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 08:31:12 ourserver auth[17875]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
ouru...@ourserver.ourdomain.edu rhost=80.78.70.1
Feb 27 08:31:33 ourserver auth[17875]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=ouruser
rhost=45.225.236.198  user=ouruser
Feb 27 09:32:22 ourserver auth[32689]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 09:32:22 ourserver auth[32689]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
nob...@ourserver.ourdomain.edu rhost=37.205.81.41
Feb 27 09:32:42 ourserver auth[32689]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=nobody
rhost=201.148.100.198  user=nobody
Feb 27 09:32:42 ourserver auth[32689]: pam_succeed_if(dovecot:auth):
requirement "uid >= 1000" not met by user "nobody"
Feb 27 09:44:09 ourserver auth[3271]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 09:44:09 ourserver auth[3271]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
otheru...@ourserver.ourdomain.edu rhost=177.69.145.193
Feb 27 09:44:35 ourserver auth[3271]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 09:44:35 ourserver auth[3271]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=otheruser
rhost=175.143.51.221
Feb 27 09:47:32 ourserver auth[4048]: pam_unix(dovecot:auth): check pass;
user unknown
Feb 27 09:47:32 ourserver auth[4048]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=
yetanotheru...@ourserver.ourdomain.edu rhost=162.245.81.231
Feb 27 09:47:56 ourserver auth[4048]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot
ruser=yetanotheruser rhost=83.243.88.236  user=yetanotheruser
Feb 27 20:44:41 ourserver auth[5828]: pam_unix(dovecot:auth):
authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=ouruser
rhost=166.171.184.200  user=ouruser

Re: ACL Folders are open but not being displayed ? [2.3.3]

[Kunal A. via dovecot]

Hey Aki,
Many thanks for helping out. All the error messages are gone but it still
isn't working. Is it possible for you to see the debug message and advise?
Many Thanks

Maillog Output:

Mar 15 05:57:18 e480machine dovecot[6364]: master: Dovecot v2.3.3
(dcead646b) starting up for imap, pop3
Mar 15 14:37:41 e480machine dovecot[6368]: imap-login: Login: user=<
ema...@example.com>, method=PLAIN, rip=::1, lip=::1, mpid=7044, secured,
session=
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Loading modules from directory: /usr/lib64/dovecot
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Module loaded: /usr/lib64/dovecot/lib01_acl_plugin.so
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Module loaded: /usr/lib64/dovecot/lib02_imap_acl_plugin.so
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Module loaded: /usr/lib64/dovecot/lib10_quota_plugin.so
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Module loaded: /usr/lib64/dovecot/lib11_imap_quota_plugin.so
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Effective uid=5000, gid=5000, home=/var/mail/vhosts/
example.com/email1
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: quota: No quota setting - plugin disabled
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Namespace inbox: type=private, prefix=INBOX/, sep=/, inbox=yes,
hidden=no, list=yes, subscriptions=yes location=maildir:~/Maildir
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: maildir++: root=/var/mail/vhosts/example.com/email1/Maildir, index=,
indexpvt=, control=, inbox=/var/mail/vhosts/example.com/email1/Maildir, alt=
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: initializing backend with data: vfile
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: acl username = ema...@example.com
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: owner = 1
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl vfile: Global ACLs disabled
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Namespace : type=public, prefix=Public/, sep=/, inbox=no, hidden=no,
list=children, subscriptions=yes
location=maildir:/mnt/5ea86261-cfae-4e17-b21f-3a6c1a03d795/Email/fastmail:LAYOUT=fs
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: fs: root=/mnt/5ea86261-cfae-4e17-b21f-3a6c1a03d795/Email/fastmail,
index=, indexpvt=, control=, inbox=, alt=
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: initializing backend with data: vfile
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: acl username = ema...@example.com
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl: owner = 0
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl vfile: Global ACLs disabled
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Namespace : type=private, prefix=, sep=, inbox=no, hidden=yes,
list=no, subscriptions=no location=fail::LAYOUT=none
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: none: root=, index=, indexpvt=, control=, inbox=, alt=
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: Mailbox INBOX: Mailbox opened because: SELECT
Mar 15 14:37:41 e480machine dovecot[6368]:
imap(ema...@example.com)<7044>:
Debug: acl vfile: file /var/mail/vhosts/
example.com/email1/Maildir/dovecot-acl not found



On Fri, Mar 15, 2019 at 5:36 AM Aki Tuomi 
wrote:

> It's a file, `touch subscriptions`
>
> Aki
> On 15.3.2019 11.36, Kunal A. wrote:
>
> Oh okay. How do correct this? Create the file/folder for this?  ie mkdir
> suscriptions ?
>
>
> On Fri, Mar 15, 2019 at 5:29 AM Aki Tuomi 
> wrote:
>
>> Nevertheless, the subscriptions file needs to be there.
>>
>> Aki
>> On 15.3.201911.28, Kunal A. wrote:
>>
>> Dear Aki,
>> Got it corrected. Many thanks for pointing it out. There is another error
>> about suscriptions. I don't have any folder with subscriptions. See the
>> error below :-
>>
>> Mar 15 05:22:10 machine dovecot[4804]: 
>> imap(ema...@example.com)<4970>:
>> Error: stat(/mnt/computer/Email/fastmail/subscriptions) failed: Permission
>> denied
>>
>> dr-xr-xr-x root  root  /
>> drwxr-xr-x root  root  mnt
>> drwxr-xr-x vmail vmail computer
>> drwxrwxr-x vmail vmail Email
>> drwxrwxr-x vmail vmail fastmail
>>subscriptions - No such file or directory
>>
>> Best Regards
>>
>>
>> On Fri, Mar 15, 2019 at 3:02 AM Aki Tuomi 
>> wrote:
>>
>>>
>>> On 15.3.2019 8.40, Kunal A. via dovecot wrote:
>>>
>>> Hey,
>>> Could

Re: Double quota calulation when special folder is present

[Mark Moseley via dovecot]

On Wed, Mar 13, 2019 at 4:46 AM Bernd Wurst via dovecot 
wrote:

> Hello,
>
> we're operating dovecot on a small server. Some years ago, we migrated
> from courier IMAP to dovecot. Therefore, we defined our default
> Namespace "inbox" with prefix "INBOX." to have this compatible. I found
> this in some migration docs those days. Generally, everything worked as
> expected.
>
> Our only namespace is configured like this:
>
> namespace inbox {
>  separator = .
>   prefix = INBOX.
>   inbox = yes
> }
>
> Regularly, there is no folder named INBOX or .INBOX in the file system,
> I suppose this is correct.  But I found a special corner case today when
> it comes to quota calculation.
>
> When - for whatever reason - a folder .INBOX.foo (for arbitrary values
> of foo) exists, the whole mailbox is counted twice in quota
> recalculation. Just creating .INBOX does nothing but a subfolder
> triggers the problem.
>
> This is my shell view (replaced username and file path and deleted
> unnecessary debug output)
>
> $ cat maildirsize
> 268435456S
> 14697 17
> $ maildirmake .INBOX.foo
> $ sudo doveadm -D quota recalc -u 
> [...]
> doveadm(): Debug: Namespace inbox: type=private, prefix=INBOX.,
> sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes
> location=maildir:/home/.../test
> doveadm(): Debug: maildir++: root=/home/.../test, index=,
> indexpvt=, control=, inbox=/home/.../test, alt=
> doveadm(): Debug: Namespace : type=private, prefix=, sep=,
> inbox=no, hidden=yes, list=no, subscriptions=no location=fail::LAYOUT=none
> doveadm(): Debug: none: root=, index=, indexpvt=, control=,
> inbox=, alt=
> doveadm(): Debug: quota: quota_over_flag check: quota_over_script
> unset - skipping
> doveadm(): Debug: Quota root User quota: Recalculated relative
> rules with bytes=268435456 count=0. Now grace=26843545
> doveadm(): Debug: Namespace INBOX.: Using permissions from
> /home/.../test: mode=0700 gid=default
>
> $ cat maildirsize
> 268435456S
> 29394 34
>
>
> So the used quota has exactly been doubled by just creating an empty
> subfolder.
>
> Do you have any pointers for fixing my configuration or is this a bug in
> dovecot?
>
>
I coincidentally resurrected a months-old thread with this same issue a few
days ago. I'm seeing the exact same after upgrading from 2.2.32 to 2.2.36.

The original poster (who also narrowed it down to something in 2.2.34)
mentioned a workaround that does indeed work, namely setting
mailbox_list_index=no:

> doveadm -o 'mailbox_list_index=no' quota recalc -u myuser

I've been staring at diffs of 2.2.33 and 2.2.34 without anything jumping
out at me (not a C guy, sadly). Maybe src/lib-storage/index/index-storage.c
or src/lib-storage/list/mailbox-list-fs-iter.c or
src/lib-storage/list/mailbox-list-index-iter.c
or src/lib-storage/list/mailbox-list-index.c?

The latter few have some added strcmp's against "INBOX". Then again,
there's a lot of new code in the diffs under src/lib-storage that
references INBOX specifically.

Re: Upgrading to 2.3

[John Fawcett via dovecot]

On 09/03/2019 14:10, Christian Schmidt via dovecot wrote:
> Hi,
>
> @lbutlr via dovecot, 08.03.19:
>> On 8 Mar 2019, at 05:54, Aki Tuomi via dovecot 
>> wrote:
>>> https://wiki.dovecot.org/Upgrading
>>
>> Duh. I wasn't looking for a URL that was specific.
>
> https://wiki2.dovecot.org/Upgrading/2.3 ;-)
>
> Kind Regards
> Christian
>
Noticed a small typo in the wiki for upgrading to 2.3

recipient_delimiters

should read

recipient_delimiter

John

Re: ACL Folders are open but not being displayed ? [2.3.3]

[Aki Tuomi via dovecot]

It's a file, `touch subscriptions`

Aki

On 15.3.2019 11.36, Kunal A. wrote:
> Oh okay. How do correct this? Create the file/folder for this?  ie
> mkdir suscriptions ?
>
>
> On Fri, Mar 15, 2019 at 5:29 AM Aki Tuomi  > wrote:
>
> Nevertheless, the subscriptions file needs to be there.
>
> Aki
>
> On 15.3.201911.28, Kunal A. wrote:
>> Dear Aki,
>> Got it corrected. Many thanks for pointing it out. There is
>> another error about suscriptions. I don't have any folder with
>> subscriptions. See the error below :-
>>
>> Mar 15 05:22:10 machine dovecot[4804]: imap(ema...@example.com
>> )<4970>:
>> Error: stat(/mnt/computer/Email/fastmail/subscriptions) failed:
>> Permission denied
>>
>> dr-xr-xr-x root  root  /
>> drwxr-xr-x root  root  mnt
>> drwxr-xr-x vmail vmail computer
>> drwxrwxr-x vmail vmail Email
>> drwxrwxr-x vmail vmail fastmail
>>    subscriptions - No such file or directory
>>
>> Best Regards
>>
>>
>> On Fri, Mar 15, 2019 at 3:02 AM Aki Tuomi
>> mailto:aki.tu...@open-xchange.com>>
>> wrote:
>>
>>
>> On 15.3.2019 8.40, Kunal A. via dovecot wrote:
>>> Hey,
>>> Could someone help figure out whats wrong with my config
>>> based on the debug below?
>>>
>>> What I am trying to achieve is to get ema...@example.com
>>>  to read emails in the Public
>>> directory that is stored on
>>> /run/media/computer/Storage/Email/fastmail/Archive with the
>>> preface Public/Archive  .
>>>
>>> The ACL has been set for anyone with permissions to
>>> lookup,read,write as shown below:-
>>>
>>> doveadm acl get -u ema...@example.com
>>>  Public/Archive
>>> ID Global
>>> Rights   
>>> anyone    lookup read write
>>>
>>> But when I try to access the emails for ema...@example.com
>>>  , there are no folders.
>>> Could someone here help review my debug log and advise what
>>> could be causing this (dovecot -n output is provided below
>>> the debug message)
>>>
>>> Many thanks for assistance.
>>> Thanks
>>>
>>
>>> Mar 15 01:29:28 machine dovecot[2100]:
>>> imap(ema...@example.com
>>> 
>>> )<5167>:
>>> Error:
>>> open(/run/media/computer/Storage/Email/fastmail/dovecot-acl-list)
>>> failed: Permission denied
>>
>>> Mar 15 01:29:28 machine dovecot[2100]:
>>> imap(ema...@example.com
>>> 
>>> )<5167>:
>>> Error: stat(/run/media/computer/Storage/Email/fastmail)
>>> failed: Permission denied (euid=5000(vmail) egid=5000(vmail)
>>> missing +w perm: /run/media/computer/Storage/Email/fastmail
>>> stat(/run/media/computer/Storage/Email/fastmail) failed:
>>> Permission denied, dir owned by 0:0 mode=0775)
>>
>>> Mar 15 01:29:28 machine dovecot[2100]:
>>> imap(ema...@example.com
>>> 
>>> )<5167>:
>>> Error:
>>> 
>>> stat(/run/media/computer/Storage/Email/fastmail/.temp.e480machine.5167.a6506e27bd37a68a)
>>> failed: Permission denied
>>
>>> Mar 15 01:30:14 machine dovecot[2100]:
>>> imap(ema...@example.com
>>> 
>>> )<5167>:
>>> Error: mkdir(/run/media/computer/Storage/Email/fastmail)
>>> failed: Permission denied (euid=5000(vmail) egid=5000(vmail)
>>> missing +w perm: /run/media/computer, we're not in group
>>> 0(root), dir owned by 0:0 mode=0775)
>>>
>>
>> Maybe try fix these?
>>
>>
>> Aki
>>

Re: Re: regarding ssl certificates

[Jochen Bern via dovecot]

On 03/15/2019 06:03 AM, Gary wrote:
> Is there some reason to use a mail.domain.com cert for mail rarher than
> just using domain.com for everything? 
> 
> Historically the subdomain were used because they were on different
> hardware. That is www was on one machine and mail was on another.

Actually *THE* original approach was
a) to make ftp.mydom.ain a CNAME to machine4711.mydom.ain or similar,
b) attaching that latter (usually by A and PTR RRs) to the physical
   hardware for its lifetime, and
c) use the naked mydom.ain for e-mail addresses and thus, since MX RRs
   did not yet exist back then, have its A or CNAME RR point to your
   incoming SMTP server.

When it became apparent that using the domain name - typically
representing your organization as a whole - for a specific service
wasn't *that* bright an idea, the e-mail aspect was repaired by the
introduction of MX RRs. During the time that took to get implemented
everywhere, other services still used ftp.*, gopher.*, what have you,
even the early www.* .

Then came the day when Eric Allman decided that the new version of
sendmail shall replace CNAMEs in e-mail addresses, local admin's opinion
on the matter and existing working setups be damned. As far as I can
tell, *that's* what ended the era of the "functional names shall be
CNAMEs" paradigm.

*Today* web designers opine that an organization's website is *so*
important that it merits repeating the old error of putting it under
mydom.ain instead of www.mydom.ain, even if it's hosted someplace that's
not under *your* control in the first place. I'm fighting that wherever
I can (and unlike many of those "professionals", I *do* have the
technology at hand to have something respond to HTTP(S) at mydom.ain and
throw back a HTTP redirect to www.mydom.ain).

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACL Folders are open but not being displayed ? [2.3.3]

[Aki Tuomi via dovecot]

Nevertheless, the subscriptions file needs to be there.

Aki

On 15.3.201911.28, Kunal A. wrote:
> Dear Aki,
> Got it corrected. Many thanks for pointing it out. There is another
> error about suscriptions. I don't have any folder with subscriptions.
> See the error below :-
>
> Mar 15 05:22:10 machine dovecot[4804]: imap(ema...@example.com
> )<4970>:
> Error: stat(/mnt/computer/Email/fastmail/subscriptions) failed:
> Permission denied
>
> dr-xr-xr-x root  root  /
> drwxr-xr-x root  root  mnt
> drwxr-xr-x vmail vmail computer
> drwxrwxr-x vmail vmail Email
> drwxrwxr-x vmail vmail fastmail
>    subscriptions - No such file or directory
>
> Best Regards
>
>
> On Fri, Mar 15, 2019 at 3:02 AM Aki Tuomi  > wrote:
>
>
> On 15.3.2019 8.40, Kunal A. via dovecot wrote:
>> Hey,
>> Could someone help figure out whats wrong with my config based on
>> the debug below?
>>
>> What I am trying to achieve is to get ema...@example.com
>>  to read emails in the Public
>> directory that is stored on
>> /run/media/computer/Storage/Email/fastmail/Archive with the
>> preface Public/Archive  .
>>
>> The ACL has been set for anyone with permissions to
>> lookup,read,write as shown below:-
>>
>> doveadm acl get -u ema...@example.com 
>> Public/Archive
>> ID Global Rights   
>> anyone    lookup read write
>>
>> But when I try to access the emails for ema...@example.com
>>  , there are no folders.
>> Could someone here help review my debug log and advise what could
>> be causing this (dovecot -n output is provided below the debug
>> message)
>>
>> Many thanks for assistance.
>> Thanks
>>
>
>> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
>> )<5167>:
>> Error:
>> open(/run/media/computer/Storage/Email/fastmail/dovecot-acl-list)
>> failed: Permission denied
>
>> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
>> )<5167>:
>> Error: stat(/run/media/computer/Storage/Email/fastmail) failed:
>> Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w
>> perm: /run/media/computer/Storage/Email/fastmail
>> stat(/run/media/computer/Storage/Email/fastmail) failed:
>> Permission denied, dir owned by 0:0 mode=0775)
>
>> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
>> )<5167>:
>> Error:
>> 
>> stat(/run/media/computer/Storage/Email/fastmail/.temp.e480machine.5167.a6506e27bd37a68a)
>> failed: Permission denied
>
>> Mar 15 01:30:14 machine dovecot[2100]: imap(ema...@example.com
>> )<5167>:
>> Error: mkdir(/run/media/computer/Storage/Email/fastmail) failed:
>> Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w
>> perm: /run/media/computer, we're not in group 0(root), dir owned
>> by 0:0 mode=0775)
>>
>
> Maybe try fix these?
>
>
> Aki
>

Re: Unable to set quota-fs plugin [fixed]

[Eric Grammatico via dovecot]

The issue was in the systemd service file. The option PrivateDevices was 
setted. It prevents the service to have access to physical devices. I removed 
this option and from there, quota is reported without errors.

Thanks for your support

Regards,

-
Eric Grammatico _/)


14 mars 2019 16:42 "Eric Grammatico"  a écrit:
> Sure !!
> 
> I got it ! I have connected with kmail, which keeps the imap opened and which 
> has generated the
> error several times during the session. Please find attached the strace.
> 
> Not sure this strace will help. I executed '/usr/libexec/dovecot/imap -u 
> eric' and typed the same
> command as in the strace and it worked
> 
> Could someone have a look in the strace and suggest some ideas to progress ?
> 
> Thanks and best regards,
> 
> -
> Eric Grammatico _/)
> 
> 14 mars 2019 16:08 "Yassine Chaouche via dovecot"  a 
> écrit:
> 
>> How I'd love if I could just launch dovecot (with symbols) in a debugger, 
>> set a breakpoint in the
>> right function call, and login from Rainloop. Then I could run the process 
>> one step at a time and
>> inspect everything...
>> 
>> Yassine.
>> 
>> On 3/14/19 3:59 PM, Eric Grammatico via dovecot wrote:
>> 
>>> The error is generated when a user get connect from a client (RainLoop, a 
>>> web UI). I don't know if
>>> the client request the quota or if it's automagically pushed from the imap 
>>> process. I'd say the
>>> client requests. My problem is the process imap generating the error is 
>>> launched just before and
>>> stopped right after the error is raised and thus quite difficult to trace 
>>> the process.
>>> 
>>> -
>>> Eric Grammatico _/)
>>> 
>>> 14 mars 2019 15:46 "Yassine Chaouche via dovecot"  a 
>>> écrit:
 On 3/14/19 3:40 PM, Eric Grammatico via dovecot wrote:
 
> Hi there,
> 
> Well.. I didn't find a way to strace imap. If I well understood, the 
> faulty IMAP is launched by
> dovecot from or after a succesfull imap-login process. I have executed 
> manually
> '/usr/libexec/dovecot/imap -u eric' and typed getquotaroot "INBOX" which 
> didn't reproduce the error
> seen in the dovecot logs and reported the correct quota.
> 
> Any idea how to find the imap command generating the error
> 
> imap(eric)<3085>: Error: Failed to get quota resource 
> STORAGE: quota-fs:
> quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or directory
> 
> Thanks and regards,
> -
> Eric Grammatico _/)
 
 How did you get that error in the first place ? :p
 
 Yassine.

Re: regarding ssl certificates

[Gary via dovecot]

I do whatever Google requires not to look like spam. Fortunately the don't 
insist on DANE. 

I was just concerned about the encryption being secure. I used to use a self 
signed cert until Google made it to your advantage to use encryption on 
websites. Once I set up Let's Encrypt, it seemed dumb to use the self signed 
cert. 

On a quarterly basis the email agents warns about the cert change. If Let's 
Encrypt goes to monthly cert renewal, this is going to get a little tiresome. I 
recently modified the bash based ACME to reload Dovecot and Postfix. The 
programs eventually adjusted to the cert update, but the email agents weren't 
happy for an hour or two. The GitHub documentation for the ACME script 
indicates how to do this. 


  Original Message  



From: dovecot@dovecot.org
Sent: March 15, 2019 12:07 AM
To: dovecot@dovecot.org
Reply-to: mpet...@domblogger.net
Subject: Re: regarding ssl certificates


With PKIX validation the certificate should match the hostname.

With SMTP, the hostname should match the reverse IP though often it does
not.

Using subdomains gives you flexibility.

with DANE validation, it is DNSSEC that validates the fingerprint to the
hostname so I do not believe there is a need for the hostname in the
cert to match anything, but DANE validation is currently not used by any
mail user agents, only PKIX validation is used by mail user agents.

DANE is used to MTA to MX quite frequently however, so it may come to
mail user agents in the near future (near being within a decade or so).

On 3/14/19 10:03 PM, Gary via dovecot wrote:
> Is there some reason to use a mail.domain.com cert for mail rarher than just 
> using domain.com for everything?
>
> Historically the subdomain were used because they were on different hardware. 
> That is www was on one machine and mail was on another.
>
>
>
>
>
>   Original Message
>
>
>
> From: dovecot@dovecot.org
> Sent: March 14, 2019 3:56 PM
> To: dovecot@dovecot.org
> Reply-to: jtam.h...@gmail.com
> Subject: Re: regarding ssl certificates
>
>
> mick crane wrote:
>
>> Apache2 default install has this snake oil certificate
>> Can make a new one for apache
>
> I won't go over some of the excellent points in previous posts,
> but I will mention SAN as a third type of certificate you can make.
> LetsEncrypt supports this type of certificate.
>
> This is halfway between single CN and wildcard certificate where you can
> combine many hostnames (up to 1000?) into one certificate.  This may
> be useful if you want the convenience of handling fewer certificates,
> without having an unbounded wildcard certificate (the latter also requires
> control over your DNS).  I use this for SMTPAUTH, POP3, IMAP and webmail
> services since they are all on one server.
>
> Then Stephan von Krawczynski wrote:
>
>> Sorry I have to write this, but this is again pointing people in a fake
>> security direction.
>> The only valid authority for a certificate is the party using it. Any third
>> party with unknown participants cannot be a "Certificate Authority" in its
>> true sense. This is why you should see "Let's Encrypt" simply as a cheap way
>> to fake security. It is a US entity, which means it _must_ hand out all
>> necessary keys to fake certificates to the US authorities _by law_.
>> Now probably you can imagine why they are giving the certificates out for
>> free. US authorities can compromise all of them - without any "open 
>> knowledge".
>
> Wow, you packed a lot of fear, uncertainty and doubt (and some
> misinformation) into one paragraph.  I'll leave it at that.
>
> Joseph Tam 
>

Dovecot logrotation - old journal files are still in use (second attempt)

[Denis V Razumovskiy via dovecot]

Hi all

Sorry, it is the second attempt due to wrong format of the first message.
 
In my Dovecot there are 3 files of logging (debug, info and .log) While 
executing logrotation, the new files are created, but the previos ones, namely 
dovecot.*.1 are still in use by the process

Here is the logger process in memory:
root 19140 0.0 0.0 4140 1576 ? S Mar12 0:06 dovecot/log
 
Here the files it uses after the daily logrotation had happened:
# lsof -p19140 |grep log
...
log 19140 root   33w   REG9,3  811  417675 
/var/log/dovecot.log.1
log 19140 root   34w   REG9,3  2842123  417681 
/var/log/dovecot.info.1
log 19140 root   35w   REG9,3 14853918  417683 
/var/log/dovecot.debug.1
...

After the manual issue 'doveadm log reopen` command the files are changed to
# lsof -p19140 |grep dovecot\\\.
...
log 19140 root   33w   REG9,3   0  417651 /var/log/dovecot.log
log 19140 root   34w   REG9,3  121374  417690 /var/log/dovecot.info
log 19140 root   35w   REG9,3  916153  417691 /var/log/dovecot.debug
 
as it is expected to be.
 
I use the logrotate config for dovecot instance:
/var/log/dovecot.log /var/log/dovecot.info /var/log/dovecot.debug {
  daily
  rotate 14
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
doveadm log reopen
chmod 666 /var/log/dovecot.log
chmod 666 /var/log/dovecot.info
chmod 666 /var/log/dovecot.debug
  endscript
}

At the same time, dovecot itself still uses previous logs:

# lsof |grep var\/log\/dovecot\.
dovecot   19138   root8w  REG9,3 12962 417613 
/var/log/dovecot.log.1 (deleted)
dovecot   19138   root9w  REG9,3   4097250 416836 
/var/log/dovecot.info.1 (deleted)
dovecot   19138   root   10w  REG9,3  23816347 417603 
/var/log/dovecot.debug.1 (deleted)



What can be the root of the issue?
 
I use Dovecot as LDA for Postfix with system users, mbox mail format. System 
Slackware 12.0 x86, Postfix 2.4.5, Dovecot 2.2.36. Interconnect Postfix-Dovecot 
has been made via `mailbox_command = ...'
Dovecot was compiled from sources
 
Logging configuration (file conf.d/10-logging.conf) contains the following:

log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot.info
debug_log_path = /var/log/dovecot.debug

auth_verbose = yes
auth_verbose_passwords = yes
auth_debug = yes
mail_debug = yes
verbose_ssl = yes

plugin {
}

Could the fact, that Postfix require Dovecot logs to be accessible someway, 
result in such a weird behavior? To allow other processes to access Dovecot 
logs I had to chmod 0666 all the current logs while integrating Dovecot into 
Postfix delivery (please see `chmod' commands in the logrotate config above)
 

Please ignore my previos post 
https://dovecot.org/pipermail/dovecot/2019-March/115075.html
 
Thank you
Denis Razoumovskiy

Re: regarding ssl certificates

[Michael A. Peters via dovecot]

With PKIX validation the certificate should match the hostname.

With SMTP, the hostname should match the reverse IP though often it does 
not.


Using subdomains gives you flexibility.

with DANE validation, it is DNSSEC that validates the fingerprint to the 
hostname so I do not believe there is a need for the hostname in the 
cert to match anything, but DANE validation is currently not used by any 
mail user agents, only PKIX validation is used by mail user agents.


DANE is used to MTA to MX quite frequently however, so it may come to 
mail user agents in the near future (near being within a decade or so).


On 3/14/19 10:03 PM, Gary via dovecot wrote:

Is there some reason to use a mail.domain.com cert for mail rarher than just 
using domain.com for everything?

Historically the subdomain were used because they were on different hardware. 
That is www was on one machine and mail was on another.





  Original Message



From: dovecot@dovecot.org
Sent: March 14, 2019 3:56 PM
To: dovecot@dovecot.org
Reply-to: jtam.h...@gmail.com
Subject: Re: regarding ssl certificates


mick crane wrote:


Apache2 default install has this snake oil certificate
Can make a new one for apache


I won't go over some of the excellent points in previous posts,
but I will mention SAN as a third type of certificate you can make.
LetsEncrypt supports this type of certificate.

This is halfway between single CN and wildcard certificate where you can
combine many hostnames (up to 1000?) into one certificate.  This may
be useful if you want the convenience of handling fewer certificates,
without having an unbounded wildcard certificate (the latter also requires
control over your DNS).  I use this for SMTPAUTH, POP3, IMAP and webmail
services since they are all on one server.

Then Stephan von Krawczynski wrote:


Sorry I have to write this, but this is again pointing people in a fake
security direction.
The only valid authority for a certificate is the party using it. Any third
party with unknown participants cannot be a "Certificate Authority" in its
true sense. This is why you should see "Let's Encrypt" simply as a cheap way
to fake security. It is a US entity, which means it _must_ hand out all
necessary keys to fake certificates to the US authorities _by law_.
Now probably you can imagine why they are giving the certificates out for
free. US authorities can compromise all of them - without any "open knowledge".


Wow, you packed a lot of fear, uncertainty and doubt (and some
misinformation) into one paragraph.  I'll leave it at that.

Joseph Tam 

Re: ACL Folders are open but not being displayed ? [2.3.3]

[Aki Tuomi via dovecot]

On 15.3.2019 8.40, Kunal A. via dovecot wrote:
> Hey,
> Could someone help figure out whats wrong with my config based on the
> debug below?
>
> What I am trying to achieve is to get ema...@example.com
>  to read emails in the Public directory
> that is stored on /run/media/computer/Storage/Email/fastmail/Archive
> with the preface Public/Archive  .
>
> The ACL has been set for anyone with permissions to lookup,read,write
> as shown below:-
>
> doveadm acl get -u ema...@example.com 
> Public/Archive
> ID Global Rights   
> anyone    lookup read write
>
> But when I try to access the emails for ema...@example.com
>  , there are no folders.
> Could someone here help review my debug log and advise what could be
> causing this (dovecot -n output is provided below the debug message)
>
> Many thanks for assistance.
> Thanks
>

> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
> )<5167>:
> Error:
> open(/run/media/computer/Storage/Email/fastmail/dovecot-acl-list)
> failed: Permission denied

> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
> )<5167>:
> Error: stat(/run/media/computer/Storage/Email/fastmail) failed:
> Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm:
> /run/media/computer/Storage/Email/fastmail
> stat(/run/media/computer/Storage/Email/fastmail) failed: Permission
> denied, dir owned by 0:0 mode=0775)

> Mar 15 01:29:28 machine dovecot[2100]: imap(ema...@example.com
> )<5167>:
> Error:
> stat(/run/media/computer/Storage/Email/fastmail/.temp.e480machine.5167.a6506e27bd37a68a)
> failed: Permission denied

> Mar 15 01:30:14 machine dovecot[2100]: imap(ema...@example.com
> )<5167>:
> Error: mkdir(/run/media/computer/Storage/Email/fastmail) failed:
> Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm:
> /run/media/computer, we're not in group 0(root), dir owned by 0:0
> mode=0775)
>

Maybe try fix these?


Aki