Thanks for the detailed anwser.
So it falls under the "feature" section. I will keep that in mind in
future sieves.
And I think you are right, :copy only makes sense in situations where
the flow can lead to other places than the Inbox.
On 24/08/2022 20:04, Sean Kamath wrote:
I recommend rea
The first time when the sieve files and folders get created, the active symlink
is created as a full absolute path
.active_sieve -> /mnt/email/domain/user/_sieve/filters.sieve
After that, if you disable and enable the rule set the symlink gets recreated
as relative
.active_sieve -> fi
User home != mail home?
mail not in the user home? is that the situation?
On 25/08/2022 13:32, dove...@ptld.com wrote:
The first time when the sieve files and folders get created, the
active symlink is created as a full absolute path
.active_sieve -> /mnt/email/domain/user/_sieve/filters.
Hello,
I asked about this a few days ago, but since nobody answered in that thread,
I'd like to bring it up again as a separate thread. Maybe somebody
answers...
I have written a policy service for Postfix that checks whether the
connecting IP address has currently an IMAP session open. For this,
On 08-25-2022 9:10 am, João Silva wrote:
User home != mail home?
mail not in the user home? is that the situation?
Do you mean `/home/user` when you say user home?
No, mail is not stored in `/home/` because these are virtual users.
I would not want to create 1,000+ linux users with home direct
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
dovec
Dnia 25.08.2022 o godz. 10:48:47 dove...@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.
> W
While I see these attacks on submission service, on the contrary I see
virtually no attempts to actually login into the IMAP service
Makes sense, good luck on it.
...until ofcourse the attackers make the effortless change of switching the
port in their bot to IMAP logins instead of Submission
