RE: submission_host auth

[k v]

> There is no way for a forwarded email to SASL authenticate because no one is 
> logged in or involved in the process of LMTP receiving mail for delivery from 
> "the world". How is the MTA supposed to know the SASL password for 
> st...@work.com?

dovecot auth with "master user" when sending emails via sumbission_host;
postfix:
1. using smtpd_sender_login_maps allow master user send messages with any mail 
from, like that:
smtpd_sender_login_maps = regexp:/etc/postfix/login_map.regexp
---
login_map.regexp:
/^mas...@example.com$/ .*

OR

2. in postfix master.cf declare dedicatet submission port allowed only for 
dovecot, without reject_sender_login_mismatch, like that:
2525   inet  n   -   n   -   -   smtpd
   -o smtpd_helo_restrictions=permit_sasl_authenticated
   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
   -o smtpd_sender_restrictions=permit_sasl_authenticated

I think it's better than
mynetworks = 10.0.1.0/24 #whole subnet, container ip assigned dynamically :(
with
smtpd_sender_restrictions =
   permit_mynetworks
smtpd_relay_restrictions =
   permit_mynetworks

What about SPF in the described scenario, you are right, SPF will be broken. 
Well.. its implementation feature





От: dovecot  от имени dove...@ptld.com 

Отправлено: 17 января 2023 г. 23:18
Кому: dovecot@dovecot.org 
Тема: Re: submission_host auth

> Let's say we have dovecot + sieve plugin container.
> Dovecot configured to use remote SMTP submission host to send messages:
> submission_host = postfix.example.com:587


I reviewed my config to see how i did it. I think you are right and SASL isn't 
used here. I have dovecot and postfix on the same machine and in dovecot i set
 submission_host = localhost:25

Then in my sieve filters i set
 sieve_redirect_envelope_from = sender

I use SPF, DKIM, and DMARC

To test this i have (fictitious) st...@work.com with a forward filter to 
perso...@home.com
I sent an email from custo...@random.com to st...@work.com
@work.com server then sends a forwarded email to perso...@home.com with 
To:st...@work.com and From:custo...@random.com

Checking the @home.com logs i can see that SPF failed because @work.com server 
sent an email from @random.com, however it had valid DKIM signatures from both 
@work.com and @random.com so DMARC passed and the email was accepted.

I guess if the @random.com mail server only implemented SPF and not included a 
DKIM signature and DMARC policy then the @home.com server would have rejected 
the forwarded email.

I know this might not be the best solution you are looking for, but it is the 
best i could figure out to allow sieve forwarding. There is no way for a 
forwarded email to SASL authenticate because no one is logged in or involved in 
the process of LMTP receiving mail for delivery from "the world". How is the 
MTA supposed to know the SASL password for st...@work.com?

UNSUBSCRIBE

[Andreas Boschke]

> On Jan 17, 2023, at 2:49 PM, Gerben Wierda  wrote:
> 
> It might have a noticeable effect on clients.
> 
> I encountered (probably triggered by this in some way?) that I was unable to 
> het the 'read' bit set in macOS Mail.app. Maybe (as I am doing HA with round 
> robin) the Mail.app client got to one dovecot repository on one tcp 
> connection and then on the other.
> 
> Is there a reason why syncing tis move from new to cur is a bad idea?
> 
> Gerben Wierda (LinkedIn )
> R&A IT Strategy  (main site)
> Book: Chess and the Art of Enterprise Architecture 
> 
> Book: Mastering ArchiMate 
> 
>> On 17 Jan 2023, at 22:41, Gerben Wierda > > wrote:
>> 
>> I can confirm this in a slightly different setting, but still using two-way 
>> sync between two dovecots. On e is 2.3.19.1 running on macOS Monterey, the 
>> other is 2.3.20 running in an alpine container on Ubuntu.
>> 
>> Gerben Wierda (LinkedIn )
>> R&A IT Strategy  (main site)
>> Book: Chess and the Art of Enterprise Architecture 
>> 
>> Book: Mastering ArchiMate 
>> 
>>> On 15 Jan 2023, at 23:12, Tomaz Kavcic >> > wrote:
>>> 
>>> Hello,
>>> 
>>> I have a question in regards to specific dovecot replication behaviour and 
>>> I'm just wondering if this is actually an expected/normal behaviour, or 
>>> just a version issue.
>>> 
>>> I'm using dovecot 2.3.16 which is packed by default with latest Ubuntu 
>>> 22.04.1 LTS server release. I setup dovecot replication pair (mx1 - mx2) 
>>> which is working ok. MX1 has priority 10, MX2 has priority 20. I use 
>>> maildir (postfix + dovecot lmtp).
>>> 
>>> The "strange" behaviour is this. When new mail arrives, it's by default 
>>> delivered into "new" folder inside user directory. This email is then 
>>> replicated to both servers (mx1 and mx2). When I login to mx1 via IMAP 
>>> client (roundcube, outlook, etc.) that specific email is moved from "new" 
>>> to "cur" folder on server mx1 and it's flagged also with "S", which 
>>> probably means read flag. On server mx2, that email filename is also 
>>> flagged with "S", but the email stays inside the "new" folder and it's not 
>>> moved to "cur". If I want this email to be moved to "cur" on mx2 server, I 
>>> have to login to that IMAP server as well, click on that email (which is 
>>> already flagged as read), and after click, the email is also moved to "cur" 
>>> on server mx2.
>>> 
>>> Simply said, all new mails on mx1 server are moved to "cur" when accessed, 
>>> but the stay in "new" folder on server mx2 until they're physically 
>>> accessed there as well. Is this normal behaviour?
>>> 
>>> I tried setup with TCP and SSH replication, and the situation is the same 
>>> in all cases. Lastly, I tried TCPS (with SSL) as well, but that option has 
>>> issues in 2.3.16, which is probably known already as I found multiple posts 
>>> about these issues in this version.
>>> 
>>> Thank you in advance for your answer and kind regards, Tomaz Kavcic.
>>> 
>>> ---
>>> 
>>> As suggested by mr. Timo Sarainen, this should be synced, so I'm posting 
>>> doveconf -n as attachment for both servers as well.
>>> 
>>> 
>> 
> 

Re: dovecot replication - new and cur folders on mx1 and mx2

[Gerben Wierda]

It might have a noticeable effect on clients.

I encountered (probably triggered by this in some way?) that I was unable to 
het the 'read' bit set in macOS Mail.app. Maybe (as I am doing HA with round 
robin) the Mail.app client got to one dovecot repository on one tcp connection 
and then on the other.

Is there a reason why syncing tis move from new to cur is a bad idea?

Gerben Wierda (LinkedIn )
R&A IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 17 Jan 2023, at 22:41, Gerben Wierda  wrote:
> 
> I can confirm this in a slightly different setting, but still using two-way 
> sync between two dovecots. On e is 2.3.19.1 running on macOS Monterey, the 
> other is 2.3.20 running in an alpine container on Ubuntu.
> 
> Gerben Wierda (LinkedIn )
> R&A IT Strategy  (main site)
> Book: Chess and the Art of Enterprise Architecture 
> 
> Book: Mastering ArchiMate 
> 
>> On 15 Jan 2023, at 23:12, Tomaz Kavcic > > wrote:
>> 
>> Hello,
>> 
>> I have a question in regards to specific dovecot replication behaviour and 
>> I'm just wondering if this is actually an expected/normal behaviour, or just 
>> a version issue.
>> 
>> I'm using dovecot 2.3.16 which is packed by default with latest Ubuntu 
>> 22.04.1 LTS server release. I setup dovecot replication pair (mx1 - mx2) 
>> which is working ok. MX1 has priority 10, MX2 has priority 20. I use maildir 
>> (postfix + dovecot lmtp).
>> 
>> The "strange" behaviour is this. When new mail arrives, it's by default 
>> delivered into "new" folder inside user directory. This email is then 
>> replicated to both servers (mx1 and mx2). When I login to mx1 via IMAP 
>> client (roundcube, outlook, etc.) that specific email is moved from "new" to 
>> "cur" folder on server mx1 and it's flagged also with "S", which probably 
>> means read flag. On server mx2, that email filename is also flagged with 
>> "S", but the email stays inside the "new" folder and it's not moved to 
>> "cur". If I want this email to be moved to "cur" on mx2 server, I have to 
>> login to that IMAP server as well, click on that email (which is already 
>> flagged as read), and after click, the email is also moved to "cur" on 
>> server mx2.
>> 
>> Simply said, all new mails on mx1 server are moved to "cur" when accessed, 
>> but the stay in "new" folder on server mx2 until they're physically accessed 
>> there as well. Is this normal behaviour?
>> 
>> I tried setup with TCP and SSH replication, and the situation is the same in 
>> all cases. Lastly, I tried TCPS (with SSL) as well, but that option has 
>> issues in 2.3.16, which is probably known already as I found multiple posts 
>> about these issues in this version.
>> 
>> Thank you in advance for your answer and kind regards, Tomaz Kavcic.
>> 
>> ---
>> 
>> As suggested by mr. Timo Sarainen, this should be synced, so I'm posting 
>> doveconf -n as attachment for both servers as well.
>> 
>> 
> 

Re: replicator: Panic: data stack: Out of memory when allocating 268435496 bytes

[Gerben Wierda]

> On 6 Jan 2023, at 08:53, Aki Tuomi  wrote:
> 
> 
> 
> On January 6, 2023 3:56:39 AM GMT+02:00, Gerben Wierda  
> wrote:
>> One step further in my quest to create a replacement mail server.
>> 
>> I now have my old mail server (2.3.19.1, macOS + MacPorts) and my new 
>> (2.3.20, Alpine Linux, Docker, apk package). When I turn on replication it 
>> works, but, after a while I see:
>> 
>> Jan 06 00:50:31 replicator: Panic: data stack: Out of memory when allocating 
>> 268435496 bytes
>> Jan 06 00:50:32 replicator: Fatal: master: service(replicator): child 133 
>> killed with signal 6 (core dumped)
>> Jan 06 00:50:32 lmtp(pid 195 user sysbh): Warning: replication(sysbh): Sync 
>> failure: 
>> Jan 06 00:50:32 lmtp(pid 195 user sysbh): Warning: replication(sysbh): 
>> Remote sent invalid input: -
>> 
>> I've removed synchronous operation for now (found a message on the net 
>> suggesting that) but is this known and what does it mean?
>> 
>> Gerben Wierda (LinkedIn )
>> R&A IT Strategy  (main site)
>> Book: Chess and the Art of Enterprise Architecture 
>> 
>> Book: Mastering ArchiMate 
>> 
> 
> Dovecot default memory limit is 256M. You should probably set
> 
> service replicator {
>  vsz_limit = 2G
> }
> 
> because replicator might have to use more memory, especially for larger 
> indexes. 
> 
> Aki

Coming back to this one. doveadm config says everything is vsz_limit = 
18446744073709551615 B

Isn't that more than 2G already (nd certainly more than 256M?)?

I also tried putting

default_vsz_limit = 2G

in dovecot.conf but that doesn't change anything either.

What am I missing?

Re: dovecot replication - new and cur folders on mx1 and mx2

[Gerben Wierda]

I can confirm this in a slightly different setting, but still using two-way 
sync between two dovecots. On e is 2.3.19.1 running on macOS Monterey, the 
other is 2.3.20 running in an alpine container on Ubuntu.

Gerben Wierda (LinkedIn )
R&A IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 15 Jan 2023, at 23:12, Tomaz Kavcic  wrote:
> 
> Hello,
> 
> I have a question in regards to specific dovecot replication behaviour and 
> I'm just wondering if this is actually an expected/normal behaviour, or just 
> a version issue.
> 
> I'm using dovecot 2.3.16 which is packed by default with latest Ubuntu 
> 22.04.1 LTS server release. I setup dovecot replication pair (mx1 - mx2) 
> which is working ok. MX1 has priority 10, MX2 has priority 20. I use maildir 
> (postfix + dovecot lmtp).
> 
> The "strange" behaviour is this. When new mail arrives, it's by default 
> delivered into "new" folder inside user directory. This email is then 
> replicated to both servers (mx1 and mx2). When I login to mx1 via IMAP client 
> (roundcube, outlook, etc.) that specific email is moved from "new" to "cur" 
> folder on server mx1 and it's flagged also with "S", which probably means 
> read flag. On server mx2, that email filename is also flagged with "S", but 
> the email stays inside the "new" folder and it's not moved to "cur". If I 
> want this email to be moved to "cur" on mx2 server, I have to login to that 
> IMAP server as well, click on that email (which is already flagged as read), 
> and after click, the email is also moved to "cur" on server mx2.
> 
> Simply said, all new mails on mx1 server are moved to "cur" when accessed, 
> but the stay in "new" folder on server mx2 until they're physically accessed 
> there as well. Is this normal behaviour?
> 
> I tried setup with TCP and SSH replication, and the situation is the same in 
> all cases. Lastly, I tried TCPS (with SSL) as well, but that option has 
> issues in 2.3.16, which is probably known already as I found multiple posts 
> about these issues in this version.
> 
> Thank you in advance for your answer and kind regards, Tomaz Kavcic.
> 
> ---
> 
> As suggested by mr. Timo Sarainen, this should be synced, so I'm posting 
> doveconf -n as attachment for both servers as well.
> 
> 

RE: Quota Clone Plugin

[Marc]

> >
> > > For all of you who don't know this plugin.
> > > https://doc.dovecot.org/configuration_manual/quota_clone_plugin/
> > >
> >
> > Not really on topic, but does the quota support multiple filesystems?
> 
> quota count plugin is the one we recommend to use. It is not filesystem
> dependent.
> 

Merci!

2.4 ballpark release date?

[Shawn Heisey]

I'm wondering whether there is a ballpark release date for Dovecot 2.4. 
I know an exact release date is probably not available, but can it at 
least be narrowed to a specific quarter?  Is it likely in 2023?


I have seen on previous messages that an Ubuntu repository for 22.04 
(jammy) will appear with the 2.4 release.


My mail server in AWS is running Ubuntu 20.04 (focal), which I have 
avoided upgrading for various reasons, including websites that don't 
work with PHP 8.1.


Now the last remaining hurdle is the fact that there is no dovecot 
repository for jammy.  I would prefer the official Dovecot repo over 
dovecot packages included with Ubuntu, because it's likely to be a newer 
release, and built from vanilla project code.  At the moment jammy 
includes dovecot 2.3.16, which is even older than the 2.3.20 that I am 
running on focal from the official dovecot repo.


Again, I know that a precise release date won't be possible.  I'm just 
hoping for something like "soon" or "in about six months."


Thanks,
Shawn

Re: submission_host auth

[dovecot]

Let's say we have dovecot + sieve plugin container.
Dovecot configured to use remote SMTP submission host to send messages:
submission_host = postfix.example.com:587



I reviewed my config to see how i did it. I think you are right and SASL isn't 
used here. I have dovecot and postfix on the same machine and in dovecot i set
submission_host = localhost:25

Then in my sieve filters i set
sieve_redirect_envelope_from = sender

I use SPF, DKIM, and DMARC

To test this i have (fictitious) st...@work.com with a forward filter to 
perso...@home.com
I sent an email from custo...@random.com to st...@work.com
@work.com server then sends a forwarded email to perso...@home.com with 
To:st...@work.com and From:custo...@random.com

Checking the @home.com logs i can see that SPF failed because @work.com server 
sent an email from @random.com, however it had valid DKIM signatures from both 
@work.com and @random.com so DMARC passed and the email was accepted.

I guess if the @random.com mail server only implemented SPF and not included a 
DKIM signature and DMARC policy then the @home.com server would have rejected 
the forwarded email.

I know this might not be the best solution you are looking for, but it is the best i 
could figure out to allow sieve forwarding. There is no way for a forwarded email to SASL 
authenticate because no one is logged in or involved in the process of LMTP receiving 
mail for delivery from "the world". How is the MTA supposed to know the SASL 
password for st...@work.com?

RE: submission_host auth

[k v]

Thanks for the reply, postfix + dovecot sasl configured and working properly. 
My question is about "adding dovecot authentication when sending emails via 
submission_host".

Let's say we have dovecot + sieve plugin container.
Dovecot configured to use remote SMTP submission host to send messages:
submission_host = postfix.example.com:587

User f...@example.com has the following sieve script:
require ["fileinto", "copy", "vacation", "date", "relational"] ;
redirect :copy "b...@example.com";
keep;

b...@example.com sending email to f...@example.com

dovecot lmtp log:
lmtp(f...@example.com)<7670>: Info: sieve: 
msgid=<63fce409f26b1a67785a475a00034...@mail.example.com>: redirect action: 
failed to redirect message to : 
smtp(postfix.example.com:587): RCPT TO failed: 554 5.7.1 : 
Recipient address rejected: Access denied (permanent failure)
lmtp(f...@example.com)<7670>: Info: sieve: 
msgid=<63fce409f26b1a67785a475a00034...@mail.example.com>: stored mail into 
mailbox 'INBOX'
lmtp(f...@example.com)<7670>: Info: sieve: Execution of 
script /var/dovecot/example.com/foo/foo.sieve failed, but implicit keep was 
successful (user logfile /var/dovecot/example.com/foo/foo.sieve.log may reveal 
additional details)

sieve.log
error: msgid=<63fce409f26b1a67785a475a00034...@mail.example.com>: redirect 
action: failed to redirect message to : 
smtp(postfix.example.com:587): RCPT TO failed: 554 5.7.1 : 
Recipient address rejected: Access denied (permanent failure).

postfix log:
NOQUEUE: reject: RCPT from unknown[10.0.1.4]: 554 5.7.1 : 
Recipient address rejected: Access denied; from= 
to=

redirect :copy action failed, its expected behavior, dovecot do not auth when 
sending email via submisson_host.
If there is setting like
submission_host_master_user = mas...@example.com
submission_host_master_password = masterpass
to do authentication as master user in postfix who can send email as any user...




От: dovecot  от имени dove...@ptld.com 

Отправлено: 17 января 2023 г. 18:25
Кому: dovecot@dovecot.org 
Тема: Re: submission_host auth

> When using dovecot container with sieve plugin there is no sendmail to use 
> for sending email for sieve redirect action for example. We can use 
> submission_host instead 
> https://doc.dovecot.org/settings/core/#core_setting-submission_host but there 
> is no way to specify credentials for auth in remote MTA. Submission_relay_* 
> settings e.g. submission_relay_master_user relate to dovecot submission 
> service. Using something like permit_mynetworks in remote MTA is not 
> acceptable for security reasons.
>
> Is it possible to add authorization in the remote MTA using submission_host?


You start the auth service in dovecot, then tell the MTA to use it.
For example, if you use postfix this explains how:

   https://doc.dovecot.org/configuration_manual/howto/postfix_and_dovecot_sasl/

Re: submission_host auth

[dovecot]

When using dovecot container with sieve plugin there is no sendmail to use for 
sending email for sieve redirect action for example. We can use submission_host 
instead https://doc.dovecot.org/settings/core/#core_setting-submission_host but 
there is no way to specify credentials for auth in remote MTA. 
Submission_relay_* settings e.g. submission_relay_master_user relate to dovecot 
submission service. Using something like permit_mynetworks in remote MTA is not 
acceptable for security reasons.

Is it possible to add authorization in the remote MTA using submission_host?



You start the auth service in dovecot, then tell the MTA to use it.
For example, if you use postfix this explains how:

  https://doc.dovecot.org/configuration_manual/howto/postfix_and_dovecot_sasl/

submission_host auth

[k v]

When using dovecot container with sieve plugin there is no sendmail to use for 
sending email for sieve redirect action for example. We can use submission_host 
instead https://doc.dovecot.org/settings/core/#core_setting-submission_host but 
there is no way to specify credentials for auth in remote MTA. 
Submission_relay_* settings e.g. submission_relay_master_user relate to dovecot 
submission service. Using something like permit_mynetworks in remote MTA is not 
acceptable for security reasons.

Is it possible to add authorization in the remote MTA using submission_host?