Re: Design Check
On Wed, 27 Oct 2021, Felix Ingram wrote:
[...]
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 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).
[...]
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.
Of course, you could use a wildcard MX, but my understanding is that this can
cause problems (but I'd have to check in RFC1912 and RFC4592).
Cheers.
Re: Design Check
On 10-27-2021 11:10 pm, justina colmena ~biz wrote: Interesting. Have you looked at this? https://serverfault.com/questions/133190/host-wildcard-subdomains-using-postfix That makes sense and would work, setting domains and user addresses with perl regex expressions.
Re: Design Check
Interesting. Have you looked at this?
https://serverfault.com/questions/133190/host-wildcard-subdomains-using-postfix
[People have too much "flair" and rep points and I can't participate in those
stackexchange discussions or ask or answer like I used to.]
On October 27, 2021 3:15:01 PM AKDT, dove...@ptld.com 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
>
>
>
>> one stumbling block could be that we don't
>> know the various subdomains ahead of time.
>>
>> 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
>
>Best to my knowledge this is not possible with postfix. But ask the
>postfix mailing list to get a definitive answer. In postfix you have to
>tell it the domains it accepts mail for, anything else it considers
>relaying. Otherwise how does postfix know that email is meant to be
>saved here or it is just passing through and you want postfix to query
>DNS to find out where it goes (if relaying is even allowed).
>
>
>
>> 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.
>
>
>
>> 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.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Design Check
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
one stumbling block could be that we don't
know the various subdomains ahead of time.
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
Best to my knowledge this is not possible with postfix. But ask the
postfix mailing list to get a definitive answer. In postfix you have to
tell it the domains it accepts mail for, anything else it considers
relaying. Otherwise how does postfix know that email is meant to be
saved here or it is just passing through and you want postfix to query
DNS to find out where it goes (if relaying is even allowed).
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.
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.
Re: Design Check
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
BUG: imapsieve with virtual mailboxes
Hi,
I've configured virtual mailboxes and it is working well, including the
setting of the real mailbox that will receive messages moved to it.
Problem starts when I try to use imapsieve plugin with this setup, I
receive a panic on the log and the action isn't executed.
To make the problem appears, all that its needed is to have a virtual
folder defined with the real mailbox configured (! prefix on the virtual
configuration file), having the imapsieve options enabled on dovecot
configuration and a sieve script defined.
Error occurs even if the sieve script is empty.
This error was already reported back in 2017:
https://www.dovecot.org/list/dovecot/2017-September/109445.html
This is the relevant configuration for imapsieve:
plugin {
imapsieve_mailbox1_before = file:/etc/wwmail/antispamsieve/learn.sieve
imapsieve_mailbox1_causes = COPY APPEND
imapsieve_mailbox1_name = *
sieve_global_path = /var/lib/dovecot/sieve/default.sieve
sieve_pipe_bin_dir = /etc/wwmail/antispamsieve/
sieve_plugins = sieve_imapsieve sieve_extprograms
}
This is the error received:
Oct 27 16:25:06 lab dovecot:
imap(moni...@lab.wwmail.app)<28726>:
Panic: file mail-index-map.c: line 558 (mail_index_map_lookup_seq_range):
assertion failed: (first_uid > 0)
Oct 27 16:25:06 lab dovecot:
imap(moni...@lab.wwmail.app)<28726>:
Error: Raw backtrace:
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7f8f68fe1b52] ->
/usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f8f68fe1c6e] ->
/usr/lib/dovecot/libdovecot.so.0(+0xff41b) [0x7f8f68ff041b] ->
/usr/lib/dovecot/libdovecot.so.0(+0xff4b1) [0x7f8f68ff04b1] ->
/usr/lib/dovecot/libdovecot.so.0(+0x5427c) [0x7f8f68f4527c] ->
/usr/lib/dovecot/libdovecot-storage.so.0(+0x49e07) [0x7f8f69104e07] ->
/usr/lib/dovecot/libdovecot-storage.so.0(+0xf00a9) [0x7f8f691ab0a9] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mail_index_lookup_seq+0xf)
[0x7f8f691b3e0f] ->
/usr/lib/dovecot/modules/lib20_virtual_plugin.so(+0x829c) [0x7f8f68b1029c]
-> /usr/lib/dovecot/libdovecot-storage.so.0(mail_set_uid+0x35)
[0x7f8f6910a9a5] ->
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so(+0x8cf2)
[0x7f8f68b01cf2] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x56)
[0x7f8f69117806] -> dovecot/imap(+0x1584d) [0x56322e61784d] ->
dovecot/imap(command_exec+0xa4) [0x56322e621cf4] -> dovecot/imap(+0x25bbf)
[0x56322e627bbf] -> dovecot/imap(+0x25c6b) [0x56322e627c6b] ->
dovecot/imap(+0x25f04) [0x56322e627f04] ->
dovecot/imap(client_handle_input+0x1b5) [0x56322e6280d5] ->
dovecot/imap(client_input+0x70) [0x56322e628490] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f8f690067d9] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132)
[0x7f8f69008642] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) [0x7f8f690086f0]
-> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) [0x7f8f690088b0] ->
/usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f8f68f78dd3]
-> dovecot/imap(main+0x500) [0x56322e613fc0] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f8f68d4cd0a] ->
dovecot/imap(_start+0x2a) [0x56322e6140ba]
I am using packages of Debian Bookworm (testing) but the problem already
occured on Debian Buster.
Packages installed
# dpkg --list | grep dovecot | awk '{print $2 " " $3}'
dovecot-antispam 2.0+20171229-1+b8
dovecot-core 1:2.3.16+dfsg1-3
dovecot-imapd 1:2.3.16+dfsg1-3
dovecot-lmtpd 1:2.3.16+dfsg1-3
dovecot-managesieved 1:2.3.16+dfsg1-3
dovecot-mysql 1:2.3.16+dfsg1-3
dovecot-pop3d 1:2.3.16+dfsg1-3
dovecot-sieve 1:2.3.16+dfsg1-3
Please take a look at it.
I can help provide more information if needed, but I think all relevant
information to reproduce the bug is here.
Best regards,
Claudemir
Dovecot does not start on MacOS 12.01
I've been happily running Dovecot on my Mac for many years (installed via
Homebrew). After upgrading to Monterey (MacOS 12.01), it no longer starts:
$ sw_vers
ProductName:macOS
ProductVersion: 12.0.1
BuildVersion: 21A559
$ uname -a
Darwin dfelicia-mac 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23
PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
$ sudo dovecot -F
Oct 27 10:11:18 service(log): Fatal: setrlimit(RLIMIT_DATA, 268435456): Invalid
argument
$ mount
/dev/disk1s2s1 on / (apfs, sealed, local, read-only, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s5 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime,
nobrowse)
/dev/disk1s3 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk1s6 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
/dev/disk1s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
$ sudo dovecot -n
# 2.3.16 (7e2e900c1a): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.16 (09c29328)
# OS: Darwin 21.1.0 x86_64 apfs
# Hostname: dfelicia-mac
default_internal_group = mail
default_internal_user = _dovecot
default_login_user = _dovenull
first_valid_uid = 100
listen = 127.0.0.1
log_path = /var/log/dovecot.log
mail_location = maildir:/usr/local/var/mail/%u
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace inbox {
inbox = yes
location mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix }
passdb {
args = login
driver = pam
}
protocols = imap
service imap-login {
inet_listener imap {
address = 127.0.0.1
port = 143
}
inet_listener imaps {
address = 127.0.0.1
ssl = no
}
}
ssl = no
userdb {
driver = passwd
}
$ ulimit -Ha
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) unlimited
pipe size(512 bytes, -p) 1
stack size (kbytes, -s) 65532
cpu time (seconds, -t) unlimited
max user processes (-u) 2784
virtual memory (kbytes, -v) unlimited
dovecot-sysreport-dfelicia-mac-1635346907.tgz
Description: Binary data
Re: Design Check
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. 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".
Design Check
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
Re: dovecot oauth
On 26/10/21 17:48, Aki Tuomi wrote: >> On 26/10/2021 16:04 la.jolie@paquerette wrote: >> >> >> Hello, >> >> I upgraded my servers from Debian Buster (v10) to Bullseye (v11). >> Before the upgrade, I had Roundcube / Dovecot working with LemonLdap >> (via OAuth). >> >> After the upgrade, i can't connect to Roundcube anymore. >> >> - roundcube (v1.5-rc) stayed the same >> - Dovecot upgraded from v1:2.3.4.1-5+deb10u6 to v1:2.3.13+dfsg1-2 >> >> I already discussed on the LemonLdap mailing list and the analysis was: >> "Seems like your app is not sending client_id and client_secret >> correctly then >> It can do that either as POST parameters or in the Authorization header" >> >> I downgraded Dovecot to Buster version (v1:2.3.4.1-5+deb10u6) and >> Roundcube / Dovecot are working again. >> >> What could have change between these 2 versions to have that error? >> >> My dovecot Oauth config: >> >> debug = yes >> >> ## url for verifying token validity. Token is appended to the URL >> tokeninfo_url = https://auth.mydomain.name/oauth2/userinfo?access_token= >> >> ## introspection endpoint, used to gather extra fields and other >> information. >> introspection_url = https://auth.mydomain.name/oauth2/introspect >> >> ## How introspection is made, valid values are >> ## auth = GET request with Bearer authentication >> ## get = GET request with token appended to URL >> ## post = POST request with token=bearer_token as content >> introspection_mode = post >> >> ## TLS settings >> tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt >> >> ## username attribute in response (default: email) >> username_attribute = email > I cannot see client_id or client_secret here. They are added automatically as > POST fields when present in the config file. > > Aki Hello Aki, Indeed, it seems to be compulsory to have client_id & client_secret in the dovecot-oauth file with bullseye version of dovecot. NB: For those who were in the same situation, don't forget to protect your dovecot-oauth file as it has now a secret. -rw-r- 1 dovecot dovecot 1152 oct 27 14:09 /etc/dovecot/dovecot-oauth2.conf.ext Big thanks for your help. Best, Kenny
