dovecot - Aug 2022 - Is this safe?

> srw-rw---- 1 root dovecot 0 Aug 21 20:47 /var/run/dovecot/anvil
> Then my service can run under the user "dovecot" and access the
socket.

My educated guess is, no this doesn't create any extra vulnerability. If
someone could exploit the user dovecot, then don't they already have access
to dovecot, that socket and everything else? An extra step you can do if you are
not comfortable running the policy script as user dovecot is run the policy
script under its own user, then add that user to the dovecot group. But i am far
from being an expert and doing that might not be adding any extra
'safety'.

     usermod -a -G policy_user dovecot


Now for my 2 cents;
Why? Not all clients keep active connections open to IMAP between fetching mail
and then sending to submission.
Postfix can validate user/pass credentials with dovecot when accepting mail for
submission.
Why add extra moving parts to your system instead of just using the built in
auth checking for submission mail?

     http://www.postfix.org/postconf.5.html#permit_sasl_authenticated
     POSTFIX:
     submission  inet  n  -  n  -  -  smtpd
       ...
       -o smtpd_sasl_type=dovecot
       -o smtpd_sasl_path=private/auth
       -o smtpd_sasl_auth_enable=yes
       -o smtpd_sasl_security_options=noanonymous
       -o
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination
       ...

     DOVECOT:
     service auth {
       unix_listener /var/spool/postfix/private/auth {
         mode = 0660
         user = postfix
         group = postfix
         }
     }

Dnia 25.08.2022 o godz. 10:48:47 dovecot at ptld.com
pisze:
> 
> Now for my 2 cents;
> Why? Not all clients keep active connections open to IMAP between fetching
mail and then sending to submission.
> Postfix can validate user/pass credentials with dovecot when accepting mail
for submission.
> Why add extra moving parts to your system instead of just using the built
in auth checking for submission mail?
Why? Exactly to not allow the connecting client to even go to AUTH phase if
it's not a "regular" user accessing mail on this server.

My server is a very small server and from what I see in the logs, all mail
clients that connect to it open IMAP connection first and then keep it
opened throughout the session. If you know of a commonly used client that
does not behave this way, please let me know - I will try it.

Of course I do use AUTH checking via Dovecot in Postfix, but the intent is -
as I mentioned above - to don't even proceed to the AUTH phase.

Recently I experience authentication attacks that are highly distributed. 
There are almost no IP addresses that repeat, so I can't use fail2ban or
other method to block "repeated offenders", as there are none :). It
looks
so that some IP address is connecting to submission service, tries AUTH on
some user, and disconnects. Then another IP connects and is trying the
same, *on the same user*. And the last part is what worries me. Until now
I have seen a lot of AUTH attacks but these were against random usernames
that didn't even exist on my server. But now they started targeting actual
users. So there is a chance they will possibly crack a password if this will
continue for a long time.

While I see these attacks on submission service, on the contrary I see
virtually no attempts to actually login into the IMAP service (except
legitimate users of course). Hence the idea for checking IMAP-before-SMTP :).
SMTP AUTH is of course still in place, this is just an extra step that
rejects the connection right away if the client does not have an IMAP
connection already established.
-- 
Regards,
   Jaroslaw Rafa
   raj at rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once
there
was a Hushpuppy, and she lived with her daddy in the Bathtub."