Re: Enable push notifications for all users

2022-01-06 Thread Felix Ingram



> On 6 Jan 2022, at 17:27, Aki Tuomi  wrote:
> 
> 
>> On 06/01/2022 01:34 Felix Ingram  wrote:
>> 
>> 
>> Hello all,
>> 
>> Is there a way to enable push notifications for all users, rather than 
>> having to enable them one by one?
>> 
>> My thinking was to set mail_attribute_dict to a static file but I can’t work 
>> out what I would need to put in it.
>> 
>> (I’ve now realised that that will not allow me to have other attributes to 
>> be different per user, but that’s not a real issue with my use case)
>> 
>> If a flat file isn’t the answer, then is a SQL dict my best bet?
>> 
>> Thanks in advance,
>> 
>> Felix
> 
> This is pretty driver dependant thing. Which driver are you using? Push 
> notifications are always enabled when push notification plugin is loaded with 
> a driver, it is up to the driver to send those.
> 

Thanks Aki,

I was using the Ox driver as then I can talk directly to my web API but it was 
complaining that the mailbox needed to have IMAP Attributes enabled. I thought 
this was the case for all drivers but it appears that I can use the Lua driver 
without having attributes enabled, so I’ve recreated the web request in Lua and 
that seems to be working. 

Hopefully I’m not missing some key difference between the two. 

Regards,

Felix 

Re: Enable push notifications for all users

2022-01-06 Thread Felix Ingram


> On 5 Jan 2022, at 23:34, Felix Ingram  wrote:
> 
> Hello all,
> 
> Is there a way to enable push notifications for all users, rather than having 
> to enable them one by one?
> 
> My thinking was to set mail_attribute_dict to a static file but I can’t work 
> out what I would need to put in it.
> 
> (I’ve now realised that that will not allow me to have other attributes to be 
> different per user, but that’s not a real issue with my use case)
> 
> If a flat file isn’t the answer, then is a SQL dict my best bet?

I’ve switched to using a SQL dictionary for the mail attributes (via a proxy 
dictionary, as that seems required) but dovecot isn’t performing any lookups. 
The logs are saying that the key isn’t mapped, and it looks like it needs a 
user-specific part of the key to be included.

My current map:

map {
  pattern = private/vendor/vendor.dovecot/http-notify
  table = mailbox
  username_field = username
  value_field = username
}

Is there a way to work around this? My issue is that I’m creating users on the 
fly and therefore they won’t exist until their first mail arrives. I’m thinking 
that I’m going to need to call out to the doveadm API in order to set the 
attribute. Does that sound doable?

Thanks in advance,

Felix

P.S. Apologies if replying to myself is messing up the thread.

Enable push notifications for all users

2022-01-05 Thread Felix Ingram
Hello all,

Is there a way to enable push notifications for all users, rather than having 
to enable them one by one?

My thinking was to set mail_attribute_dict to a static file but I can’t work 
out what I would need to put in it.

(I’ve now realised that that will not allow me to have other attributes to be 
different per user, but that’s not a real issue with my use case)

If a flat file isn’t the answer, then is a SQL dict my best bet?

Thanks in advance,

Felix

Shared folders - dovecot.index.pvt view is inconsistent

2021-11-03 Thread Felix Ingram
Hello all,

As part of the system I'm cobbling together, I have a need for sharing
folders between users. I've followed the various pieces of documentation
and seem to have something working but have encountered an odd issue.

When user1 shares a folder with user2, then on first access user2 gets a
"permission denied" error when trying to access the folder. If I
immediately try to access the folder again, then everything is okay. The
logs talk about the index.pvt files being inconsistent, which seems to
result in the error the first time but allows access the second.

I've searched the mailing lists and it seems that this was seen a few years
ago and is due to the index files being empty but there didn't seem to be a
resolution.

At the moment, I am filing messages into folders under INBOX, which means
that the INBOX itself is empty (though I've seen the same behaviour if I
put some messages in there as well).

Can anyone suggest a fix/workaround? I've included my config and some log
entries below. In the logs, the "tester@..." user is trying to access the
folder "INBOX/tester2" shared by "foo123@...".

(Bonus question: can anyone suggest a mail client that allows easy access
to shared folders? For the life of me I can't see how to do it in
Thunderbird, so I'm using a python script at the moment.)

Thanks in advance,

Felix

# 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.7.2 ()
# OS: Linux 5.10.16.3-microsoft-standard-WSL2 x86_64 Ubuntu 20.04.3 LTS
overlay
# Hostname: ptm-dovecot-5b466fb667-gk6f7
auth_debug = yes
auth_debug_passwords = yes
auth_master_user_separator = *
auth_username_chars =
auth_verbose = yes
dict {
  acl = pgsql:/etc/dovecot/conf.d/dovecot-dict-sql.conf.ext
}
disable_plaintext_auth = no
log_path = /dev/stderr
mail_debug = yes
mail_location = maildir:/home/vmail/%u
mail_plugins = acl
master_user_separator = *
namespace {
  inbox = yes
  location =
  prefix =
  separator = /
  type = private
}
namespace {
  list = children
  location = maildir:/home/vmail/%%u:INDEXPVT=~/Maildir/shared/%%u
  prefix = shared/%%u/
  separator = /
  subscriptions = no
  type = shared
}
passdb {
  args = /etc/dovecot/conf.d/dovecot-sql.conf.ext
  driver = sql
}
plugin {
  acl = vfile:/etc/dovecot/dovecot-acl:cache_secs=6
  acl_defaults_from_inbox = yes
  acl_shared_dict = proxy::acl
  sieve_default = /etc/dovecot/conf.d/user-to-folder.sieve
}
protocols = imap lmtp
service auth {
  unix_listener auth-userdb {
group = vmail
mode = 0600
user = vmail
  }
  user = root
}
service lmtp {
  inet_listener lmtp {
address = 0.0.0.0
port = 24
  }
}
userdb {
  args = /etc/dovecot/conf.d/dovecot-sql.conf.ext
  driver = sql
}
protocol lmtp {
  log_path = /home/vmail/dovecot-deliver.log
  mail_plugins = acl sieve
  postmaster_address = ad...@mydomain.com
}
protocol imap {
  mail_plugins = acl imap_acl
}


Log output:

Nov 03 14:38:27 : Debug: acl: initializing backend with data:
vfile:/etc/dovecot/dovecot-acl:cache_secs=6
Nov 03 14:38:27 : Debug: acl: acl username = tes...@dovecot.mydomain.com
Nov 03 14:38:27 : Debug: acl: owner = 1
Nov 03 14:38:27 : Debug: acl vfile: Global ACL file:
/etc/dovecot/dovecot-acl
Nov 03 14:38:27 : Debug: Namespace : type=shared, prefix=shared/%u/, sep=/,
inbox=no, hidden=no, list=children, subscriptions=no
location=maildir:/home/vmail/%u:INDEXPVT=~/Maildir/shared/%u
Nov 03 14:38:27 : Debug: shared: root=/var/run/dovecot, index=, indexpvt=,
control=, inbox=, alt=
Nov 03 14:38:27 : Debug: acl: initializing backend with data:
vfile:/etc/dovecot/dovecot-acl:cache_secs=6
Nov 03 14:38:27 : Debug: acl: acl username = tes...@dovecot.mydomain.com
Nov 03 14:38:27 : Debug: acl: owner = 0
Nov 03 14:38:27 : Debug: acl vfile: Global ACL file:
/etc/dovecot/dovecot-acl
Nov 03 14:38:27 : Debug: Mailbox INBOX: Mailbox opened because: SELECT
Nov 03 14:38:27 : Debug: acl vfile: file /home/vmail/
tes...@dovecot.mydomain.com/dovecot-acl not found
Nov 03 14:38:27 : Debug: Namespace : /home/vmail/tes...@dovecot.mydomain.com
doesn't exist yet, using default permissions
Nov 03 14:38:27 : Debug: Namespace : Using permissions from /home/vmail/
tes...@dovecot.mydomain.com: mode=0700 gid=default
Nov 03 14:38:27 : Debug: acl vfile: file /home/vmail/
tes...@dovecot.mydomain.com/dovecot-acl not found
Nov 03 14:38:27 : Debug: auth-master: userdb lookup(
foo...@dovecot.mydomain.com): Started userdb lookup
Nov 03 14:38:27 : Debug: auth-master: conn
unix:/var/run/dovecot/auth-userdb: Connecting
Nov 03 14:38:27 : Debug: auth-master: conn
unix:/var/run/dovecot/auth-userdb: Client connected (fd=18)
Nov 03 14:38:27 auth: Debug: master in: USER 1 foo...@dovecot.mydomain.com
service=imap
Nov 03 14:38:27 auth: Debug: sql(foo...@dovecot.mydomain.com): Performing
userdb lookup
Nov 03 14:38:27 auth: Debug: sql(foo...@dovecot.mydomain.com): SELECT home,
uid, gid FROM users WHERE userid = 'foo123' AND domain = '
dovecot.mydomain.com'
Nov 03 14:38:27 auth: Debug: sql(foo...@dovecot.mydomain.com): 

Re: Design Check

2021-10-31 Thread Felix Ingram
On Thu, 28 Oct 2021 at 08:29, Felix Ingram  wrote:

> On Thu, 28 Oct 2021 at 00:15,  wrote:
>
>> [...]
>
> > I think my "creating users" was me wanting to make sure that when
>> > postfix
>> > passes an email for "bar...@mydomain.com" to Dovecot, then Dovecot
>> will
>> > store it and wait for
>> > someone to come along and impersonate barbaz. i.e. "barbaz" doesn't
>> > have to exist as a user
>> > already before Dovecot will store the mail.
>>
>> If you are using LMTP dovecot will only accept emails from postfix that
>> it can lookup the /directory/path to from one of the userdb{} or
>> passdb{} sections. If dovecot can not find a match in any of the
>> userdb{} or passdb{} it will reject the email as user unknown causing
>> postfix to send a undeliverable notice email back to the envelope sender
>> address, also known as back-scatter. I am not aware of a way to use
>> wildcard addresses in dovecot userdb{}, i don't think its possible but i
>> don't know what i don't know.
>>
>
> So I think this will be the main issue now - there's no way of knowing the
> addresses ahead of time, so it sounds like I'll need to add them to
> userdb{} when they
> hit postfix and before they get passed to dovecot.
>

Just to close the loop on this - I managed to get this working using
postfix's virtual aliases. I use
a postgresql function in the alias lookup that transforms '
tes...@foobar.mydomain.com' into
'foo...@mydomain.com' and at the same time inserts 'foo...@mydomain.com'
into the
Dovecot users table. I then have a separate passdb for master users that
can log in and
impersonate the foobar user.

So far this seems to work.

Thanks again to everyone for the help.

Felix


Re: Design Check

2021-10-28 Thread Felix Ingram
On Thu, 28 Oct 2021 at 00:15,  wrote:

> > I think your approach would work, however, if I set
> > up aliases similar to:
> >
> > @barbaz.mydomain.com -> bar...@mydomain.com.
> >
> > I believe I can do that in postfix with some regex magic.
>
> Yes, that would work perfectly without any regex.
> You just point the catchall alias to the "user".
> @barbaz.mydomain.com -> bar...@mydomain.com
>
>
I've managed to get this working in postfix - I needed the regex rather
than
a static map, as I need to extract the unknown subdomain portion but it
seems
to be working. I have been able to get postfix to save it to a file as well
and it seems
to work as I expected.


> [..]
> > The purpose of the system is that users can create disposable/temporary
> > email addresses for various testing jobs.
>
> Are you aware of postfix recipient_delimiter? It allows for disposable /
> wild card addresses. If enabled in postfix, you setup a mailbox user
> like bar...@mydomain.com and any address with that user and the
> delimiter would still get delivered to that user.
>
> bar...@mydomain.com -> bar...@mydomain.com
> barbaz+randomt...@mydomain.com -> bar...@mydomain.com
> barbaz+te...@mydomain.com -> bar...@mydomain.com
>
> You can change the + to any symbol you want postfix to look out for.
>

We were using this approach on a different domain but our issue was that we
have
multiple people on the same piece of work and so they needed to share
access to
all of the mails. We decided on the approach I'm describing as we also
wanted to
have control at the DNS level to do this such as expiring addresses.


>
> > I think my "creating users" was me wanting to make sure that when
> > postfix
> > passes an email for "bar...@mydomain.com" to Dovecot, then Dovecot will
> > store it and wait for
> > someone to come along and impersonate barbaz. i.e. "barbaz" doesn't
> > have to exist as a user
> > already before Dovecot will store the mail.
>
> If you are using LMTP dovecot will only accept emails from postfix that
> it can lookup the /directory/path to from one of the userdb{} or
> passdb{} sections. If dovecot can not find a match in any of the
> userdb{} or passdb{} it will reject the email as user unknown causing
> postfix to send a undeliverable notice email back to the envelope sender
> address, also known as back-scatter. I am not aware of a way to use
> wildcard addresses in dovecot userdb{}, i don't think its possible but i
> don't know what i don't know.
>

So I think this will be the main issue now - there's no way of knowing the
addresses ahead of time, so it sounds like I'll need to add them to
userdb{} when they
hit postfix and before they get passed to dovecot.

For my sins I'm building this on Kubernetes so dovecot is on a separate
"machine" at the
moment. The userdb will be in postgres, as I'm using that for other things,
so I guess I'll need
to update that in postfix somewhere. This is a fairly low volume system, so
I can probably take
the hit of a DB query per email.

Currently postfix doesn't even seem to be attempting to talk to dovecot but
that's one for the
postfix list.

Thanks again for the help.

Cheers,

Felix


Re: Design Check

2021-10-28 Thread Felix Ingram
On Thu, 28 Oct 2021 at 07:40, Bernardo Reino  wrote:

>
> > [...]
>
> Further to the responses you have received already, I'd like to note that
> if you
> want to receive mail at {alias}@{user}.mydomain.com then, at the time of
> *sending* the e-mail there needs to be an MX record for user, as otherwise
> the
> sender won't be able to connect to your (postfix) server.
>
> That means that the users will have to exist *before* postfix receives the
> message, and thus clearly before dovecot receives it.. so you may have to
> reconsider your requirement of adding users of on-the-fly.
>

Excellent point. So we are also using a DNS server with this (CoreDNS with
some custom plugins).
This means we are able to handle the dynamic MX records (plus also allowing
us to expire domains if
we need to).

Cheers,

Felix


Re: Design Check

2021-10-27 Thread Felix Ingram
On Wed, 27 Oct 2021 at 18:27,  wrote:

> > On 10-27-2021 12:06 pm, Felix Ingram wrote:
> >
> > us...@foobar.mydomain.com
> > us...@foobar.mydomain.com
> > us...@barbaz.mydomain.com
> > us...@barbaz.mydomain.com
> >
> > I would like all emails to the "foobar" subdomain to end up in their
> > own mailbox and all emails to the "barbaz" subdomain to go to their own
> > mailbox.
>
> Your question might be more suited to the postfix mailing list. Dovecot
> doesn't receive mail from the internet, which i believe you understand
> as you said "have postfix accepting the emails before passing them to
> Dovecot".
>
> On the postfix side, one option would be using one mailbox and one
> catchall for each subdomain.
>
> Setup a user: catch...@foobar.mydomain.com
> Setup an alias: @foobar.mydomain.com -> catch...@foobar.mydomain.com
>
> Setup a user: catch...@barbaz.mydomain.com
> Setup an alias: @barbaz.mydomain.com -> catch...@barbaz.mydomain.com
>
> On the dovecot side, you can setup each person with their own login user
> and all of those users access the same IMAP inbox. Or you could just
> give everyone the password to the same one mailbox
> catch...@foobar.mydomain.com.
>
>
So I think this would make sense, though one stumbling block could be that
we don't
know the various subdomains ahead of time. The purpose of the system is
that users
can create disposable/temporary email addresses for various testing jobs.
The subdomain
can be any value that the user wants, and we don't want them to have to
precreate them before
they can use an address (we have an existing system that works this way,
and so we want to
keep that behaviour). I think your approach would work, however, if I set
up aliases similar to:

@barbaz.mydomain.com -> bar...@mydomain.com.

I believe I can do that in postfix with some regex magic.
I would then want users to log in as "barbaz", and get access to all of the
emails. I believe that
if I create Dovecot users for my system users, and then set them as master
users, then they will
be able to log into Dovecot with something like:

barbaz*

as their username.


Not sure "dovecot creating users" is the right way to think about it.
> Dovecot simply looks for IMAP files where its told to look. In dovecot
> config you setup flat files or databases that tell dovecot if someone
> logs in with this user:pass then look in this /server/path for emails.
> Other than that config, which you could point to a different
> /server/path changing their inbox, there are no "accounts".
>

I think my "creating users" was me wanting to make sure that when postfix
passes an email for
"bar...@mydomain.com" to Dovecot, then Dovecot will store it and wait for
someone to come along
and impersonate barbaz. i.e. "barbaz" doesn't have to exist as a user
already before Dovecot will store the
mail.

Thanks again for the pointers - I shall play with postfix local delivery
before trying to wire up Dovecot.

Regards,

Felix


Design Check

2021-10-27 Thread Felix Ingram
Hello all,

I'm building a mail system and would like to check whether my design is
feasible. I'm fairly certain that it is but I think I don't have the right
words and concepts lined up properly in my head.

The end system will provide temporary/disposable email addresses that can
be accessed by multiple people.

People would be able to send email to addresses that match the following
format:

us...@foobar.mydomain.com
us...@foobar.mydomain.com

us...@barbaz.mydomain.com
us...@barbaz.mydomain.com

I would like all emails to the "foobar" subdomain to end up in their own
mailbox and all emails to the "barbaz" subdomain to go to their own
mailbox. (I think that means I need a foobar and barbaz user on Dovecot).
Users of the system should be able to see all of the emails, including the
original addresses they were sent to.

e.g. us...@foobar.mydomain.com and us...@foobar.mydomain.com both get
delivered to the "foobar" mailbox, and users can see all emails, including
that they were sent to "user1" and "user2"

The users of the system would be able to access any of the foobar, barbaz,
etc mailboxes - I believe that means that they would need to be set as
master users.

I will be creating a web interface for users to get/set their credentials,
so can add those users on an adhoc basis, but I will need to have the
"foobar", "barbaz", etc users created whenever an email arrives (we won't
know ahead of time).

The plan is to have postfix accepting the emails before passing them to
Dovecot. I don't believe postfix needs to do much processing but that this
would be the place to transform the address into the correct user/mailbox
name.

So my questions are:

1. Does the above sound reasonable?
2. Can Dovecot auto-create users as needed?
3. Will I be able to preserve the original email?
4. Are master users the right approach?

There is no strong requirement for privacy between mailboxes - there is no
issue with one user being able to read all email.
There is also no requirement to be able to send email but that is a feature
request for the future - we would want people to be able to send as the
original address when that's implemented.

Any pointers gratefully received.

Thanks in advance,

Felix