I wonder if I can just copy the compiled binaries over to the working
server? Or should I build a new server from scratch and compile Dovecot
again? If it's possible to copy over, which files will be required? Just
'dovecot'? Also, in my testing environment I used a Dovecot apt package
for
Thanks, worked like a charm!
I wonder if I can just copy the compiled binaries over to the working
server? Or should I build a new server from scratch and compile Dovecot
again? If it's possible to copy over, which files will be required? Just
'dovecot'? Also, in my testing environment I used
On Thu, Oct 13, 2022 at 5:40 PM Serveria Support
wrote:
> Hi,
>
> Unfortunately, after running autogen.sh and ./configure the file is
> still not there. I understand that this is not a Dovecot issue, but
> perhaps someone can help me with this?
1. mkdir ~reinob/Sources
2. cd ~reinob/Sources
3.
Hi,
Unfortunately, after running autogen.sh and ./configure the file is
still not there. I understand that this is not a Dovecot issue, but
perhaps someone can help me with this?
On 2022-10-12 08:54, Bernardo Reino wrote:
On Tue, 11 Oct 2022, Serveria Support wrote:
I'm sorry but I wasn't
Am 12.10.22 um 15:21 schrieb Stuart Henderson:
On 2022-10-11, Bernardo Reino wrote:
Please please stop top-posting. Makes a mess of everything!
I think everything that can be said in this thread, already has been said...
But not by everybody...
--
Cheers
spi
On 2022-10-11, Bernardo Reino wrote:
> Please please stop top-posting. Makes a mess of everything!
I think everything that can be said in this thread, already has been said...
On Tue, 11 Oct 2022, Serveria Support wrote:
I'm sorry but I wasn't able to find src/config/all-settings.c file.
all-settings.h is there but all-settings.c is missing. I checked on
Github (thought maybe some files failed to extract) and it's missing
there too.
When building from git, you
> "Serveria" == Serveria Support writes:
> Yes, there is a tiny problem letting the attacker change this value back
> to yes and instantly get access to users' passwords in plain text. Apart
> from that - no problems at all. :)
Honestly, if the attacker has penetrated you to such an
I'm sorry but I wasn't able to find src/config/all-settings.c file.
all-settings.h is there but all-settings.c is missing. I checked on
Github (thought maybe some files failed to extract) and it's missing
there too.
On 2022-10-11 22:15, Bernardo Reino wrote:
Please please stop top-posting.
Please please stop top-posting. Makes a mess of everything!
On Tue, 11 Oct 2022, Serveria Support wrote:
Ok, this is something... let me check...
If you're you referring to these pieces of code:
[...]
I'm not a programmer, let alone a C guru, but these extracts look like
password failure
Ok, this is something... let me check...
If you're you referring to these pieces of code:
if (path != NULL) {
/* log this as error, since it probably is */
str = t_strdup_printf("%s (%s missing?)", str, path);
On 11.10.22 18:04, John Tulp wrote:
in mitigating such risk, why not go for the "low hanging fruit" by
simply not storing passwords on disk in clear text ? unless there is
some reason why clear text passwords actually have to be written to
disk.
Authentication schemes like CRAM-MD5 require
If someone has root they can just read the email storage files, no
password needed.
We are discussing Dovecot with encrypted mail storage here.
If someone has root, and dovecot has no code showing passwords in
logs, the attacker can build THEIR OWN version of dovecot that
"key-logs" all
What i'm saying is...
if the attackers goal is only to get passwords, you will not be dealing
with a bigger problem. In that hypothetical there would not be a bigger
problem or any other problem.
the only problem is passwords leaking in that case.
The attacker goes out of their way to not
Yeah, it's such an obvious vulnerability, I'm kinda surprised most people here
don't see an issue with that.
What people are trying to explain is the scenario you describe requires an
attacker to have root privileges on the target server. If someone has root
access to a server then your
@Tulp - the attacker has to 0wn your server first. In which case they
will have found a password to SSH in - regardless of dovecot being there or
not.
You will be dealing with a bigger problem than dovecot.
On Tue, Oct 11, 2022 at 5:39 PM John Tulp wrote:
> I find this conversation
Bingo! Great to see some like-minded person here John!
Yeah, it's such an obvious vulnerability, I'm kinda surprised most
people here don't see an issue with that. If I were a Dovecot Pro OX
customer, I'd be very concerned with this "feature".
Imagine hacking Protonmail's server, getting
I find this conversation "interesting".
Serveria, i think some can't see the attack scenario where the
attacker's goal is simply to get email passwords, and nothing else. it
would make sense for their strategy to do nothing else "bad" on the
server to attract attention to their intrusion. In
Odhiambo Washington skrev den 2022-10-11 15:49:
If you don't store cleartext passwords in your backend, how will an
intruder get them??
auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = yes
then read log files if thats with world access
all the above
On Mon, 10 Oct 2022, Serveria Support wrote:
I checked the source code on Github and discussed this with a C developer.
There seem to be too many files... perhaps somebody can guide me where should
I look? Aki?
You should search for "given password" in the source.
Hint:
If you don't store cleartext passwords in your backend, how will an
intruder get them??
On Tue, Oct 11, 2022 at 3:45 PM Serveria Support
wrote:
> Yes, I realize that. But I can't think of a reason this password is
> necessary in the logs. It's kind of a backdoor and has to be removed
> from
Yes, I realize that. But I can't think of a reason this password is
necessary in the logs. It's kind of a backdoor and has to be removed
from code. Why make intruder's life easier?
On 2022-10-11 13:39, Arjen de Korte wrote:
Citeren Serveria Support :
Yes, there is a tiny problem letting the
Citeren Serveria Support :
Yes, there is a tiny problem letting the attacker change this value
back to yes and instantly get access to users' passwords in plain
text. Apart from that - no problems at all. :)
If an attacker is able to modify your Dovecot configuration, you have
bigger
Serveria Support skrev den 2022-10-11 10:44:
Yes, there is a tiny problem letting the attacker change this value
back to yes and instantly get access to users' passwords in plain
text. Apart from that - no problems at all. :)
where is this problem ?, are the attacher one with full root access
Yes, there is a tiny problem letting the attacker change this value back
to yes and instantly get access to users' passwords in plain text. Apart
from that - no problems at all. :)
On 2022-10-11 12:15, Benny Pedersen wrote:
Serveria Support skrev den 2022-10-11 10:37:
Thanks, but I suspect
Serveria Support skrev den 2022-10-11 10:37:
Thanks, but I suspect you've missed a part of this discussion
if you set all to no, is there any problem to solve ?
i am only human, not perfect
On 2022-10-11 01:25, Benny Pedersen wrote:
Serveria Support skrev den 2022-10-10 23:18:
Hi Benny,
Thanks, but I suspect you've missed a part of this discussion
On 2022-10-11 01:25, Benny Pedersen wrote:
Serveria Support skrev den 2022-10-10 23:18:
Hi Benny,
Sorry I must have missed your email. Here's the output of doveconf -P
| grep auth:
doveconf: Warning: NOTE: You can get a new clean
Serveria Support skrev den 2022-10-10 23:18:
Hi Benny,
Sorry I must have missed your email. Here's the output of doveconf -P
| grep auth:
doveconf: Warning: NOTE: You can get a new clean config file with:
doveconf -Pn > dovecot-new.conf
doveconf: Warning: Obsolete setting in
Hi Benny,
Sorry I must have missed your email. Here's the output of doveconf -P |
grep auth:
doveconf: Warning: NOTE: You can get a new clean config file with:
doveconf -Pn > dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25:
'imaps' protocol is no longer
Serveria Support skrev den 2022-10-10 20:05:
I checked the source code on Github and discussed this with a C
developer. There seem to be too many files... perhaps somebody can
guide me where should I look? Aki?
you ask for help ?, and i have sayed "doveconf -P | grep auth" how can i
help more
I checked the source code on Github and discussed this with a C
developer. There seem to be too many files... perhaps somebody can guide
me where should I look? Aki?
On 2022-10-10 11:03, Serveria Support wrote:
Hi, thanks, this sounds like a great idea! Will try this and let you
guys know...
On 2022-10-10 08:03, Serveria Support wrote:
Hi, thanks, this sounds like a great idea! Will try this and let you
guys know...
On 2022-10-10 10:52, George Asenov wrote:
Dovecot is opensource so you can download source edit the log format
removing the passwords and compile it.
On 09-Oct-22
Hi, thanks, this sounds like a great idea! Will try this and let you
guys know...
On 2022-10-10 10:52, George Asenov wrote:
Dovecot is opensource so you can download source edit the log format
removing the passwords and compile it.
On 09-Oct-22 8:47 PM, Serveria Support wrote:
Like I've
Dovecot is opensource so you can download source edit the log format
removing the passwords and compile it.
On 09-Oct-22 8:47 PM, Serveria Support wrote:
Like I've already mentioned in my reply to Aki, I generally agree, but
many of these methods require much time and expertise some bad guys
Like I've already mentioned in my reply to Aki, I generally agree, but
many of these methods require much time and expertise some bad guys
don't have. You can also bruteforce the passwords but it can take years.
With passwords showing in logs all they need to do is make a few clicks
and enable
Yes, I agree, but why make bad guy's life easier? I mean you can do many
things including renting a GPU cluster and bruteforcing the passwords
but it takes time to do it and also expertise. Right now, all they need
to do is make a few clicks and enable auth logging. Why don't just
eliminate
Serveria Support skrev den 2022-10-09 19:12:
Turn on auth_debug=yes and see, you'll see passwords being masked.
I have this value set to yes already and the passwords are not being
masked. Perhaps you meant auth_debug_passwords = no?
both need to be no imho
but can be diffrent in diffrent
Passwords are hidden in logs, mostly. Debug logging unfortunately can
leak some password information.
So why not just get rid of this attack vector? Who needs users'
plaintext passwords in debug logs anyway? I can't think of a situation
when this is necessary. But that's just me of course.
On Sun, 9 Oct 2022, Serveria Support wrote:
So this means passwords cannot be masked/hidden in the logs? You realize that
it actually defeats the whole idea of encrypted storage? It's useless. I can
think of lots of scenarios: malicious system administrator reading users
mails and
Serveria Support skrev den 2022-10-09 11:53:
Dovecot does it's best to hide passwords in logs, but unfortuntely
this isn't perfect.
doveconf -P | grep auth
maybe the issue is decrypt ?
To add few more comments...
You speak about privacy that either you have it or not.
If you are not your own admin, the administrator will always be able to access
your mails, there are only very limited ways for you to make it hard enough.
With mail crypt, everything and all boils down to key
> On 09/10/2022 12:53 EEST Serveria Support wrote:
>
>
> Sometimes not. If the data stored in mail accounts is more valuable than
> the server and control over it.
>
> So this means passwords cannot be masked/hidden in the logs?
Passwords are hidden in logs, mostly. Debug logging
Sometimes not. If the data stored in mail accounts is more valuable than
the server and control over it.
So this means passwords cannot be masked/hidden in the logs? You realize
that it actually defeats the whole idea of encrypted storage? It's
useless. I can think of lots of scenarios:
If you have intruder that is able to enable logs for your server, then you have
bigger issues than someone enabling logs to see passwords.
Dovecot does it's best to hide passwords in logs, but unfortuntely this isn't
perfect.
Aki
> On 08/10/2022 23:49 EEST Serveria Support wrote:
>
>
>
Hi, sorry I meant Sogo Groupware. The one from their website, not the
one bundled with iREDMAIL. I'm only using it for webmail, that's why I
called it webmail. Sorry for misleading you.
On 2022-10-09 10:47, mabi wrote:
I have rebuilt the entire project from scratch, using vanilla versions
of
> I have rebuilt the entire project from scratch, using vanilla versions
> of Dovecot, Postfix, SOGO webmail etc and everything works as expected:
Hi, just wondering where do you find the vanilla version of only SOGO webmail?
I thought SOGO webmail was distributed as a whole server package...
Hi,
I'm here with a follow-up. I have managed to fix this issue!
I have rebuilt the entire project from scratch, using vanilla versions
of Dovecot, Postfix, SOGO webmail etc and everything works as expected:
emails are getting encrypted, I'm able to send, receive and read emails
in webmail.
Ok, big progress here! Specifying user password explicitly did the
trick! The command that works is this:
doveadm -o plugin/mail_crypt_private_password=xx -Dv fetch -u
u...@mydomain.xyz text 1
Now I have to adjust/write a query which does the same in order to
read/decrypt emails via
> On 14/09/2022 19:34 EEST Serveria Support wrote:
>
>
> Thanks for your help. Do you know in which folder the keys are stored?
> I'd like to check the permissions...
>
Some notes here, after reading this thread again:
- Keys are stored in mail_attributes file, which depends on your
Thanks for your help. Do you know in which folder the keys are stored?
I'd like to check the permissions...
On 2022-09-14 18:56, hi@zakaria.website wrote:
On 2022-09-14 16:04, Serveria Support wrote:
Oh, I thought that section is for the global keys. I'm trying to use
per-user/per-folder
Oh, I thought that section is for the global keys. I'm trying to use
per-user/per-folder keys. I used this command:
doveadm -o plugin/mail_crypt_private_password=xx mailbox
cryptokey generate -u u...@mydomain.xyz -URf
On 2022-09-14 17:47, hi@zakaria.website wrote:
On 2022-09-14
How can I set the global private key in conf? I was following the
official mail-crypt tutorial. This is what I have in dovecot.conf
mail-crypt section:
mail_crypt_curve = secp521r1
mail_crypt_save_version = 2
mail_crypt_require_encrypted_user_key = yes
On 2022-09-14 17:23,
Hi,
This log shows no errors. Running doveadm fetch command gives me this:
doveadm(u...@mydomain.xyz): Error: fetch(text) failed for box=INBOX
uid=15: read() failed:
I tried it but it doesn't seem to make any difference at all.
Can someone please assist me with reading logs? Does this log below mean
Dovecot is trying to use master_user again or simply reading master_user
password file?
Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from
password_query = SELECT \
username as user, password, \
'%w' AS userdb_mail_crypt_private_password \
FROM mailbox WHERE username="%u";
Try if using ' instead of " makes a difference.
FROM mailbox WHERE username='%u';
Still banging my head against the wall...
Upon running this query: SELECT username as user, password, '%w' AS
userdb_mail_crypt_private_password FROM mailbox;
I'm getting the following output:
That's exactly what I'm trying to do. Both userdb and passwdb are
referring to dovecot-mysql.conf:
userdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
passdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
dovecot-mysql.conf contains the following query only:
You need to return the private password in your passdb query, like
SELECT '%w' AS userdb_mail_crypt_private_password ...
not in your userdb query, as %w will not be available there.
Aki
> On 30/08/2022 15:33 EEST Serveria Support wrote:
>
>
> Update: I managed to remove the master
Update: I managed to remove the master user query so users are not
getting marked as master_user on login. However, that doesn't seem to
affect anything. I'm still unable to read encoded emails in webmail. No
new errors are showing up in the log. I have even created a brand new
user and all
Upon closer review, it seems you're probably right: both users are in
fact marked master_user. How is that possible? I haven't marked new user
as a master_user. Are users marked master_user by default? What's even
more interesting, /etc/dovecot/dovecot-master-users doesn't contain this
user's
Hard to say.
If you are logging is master_user, there will be different password than normal
user. Usually. With your setup, you can only access user's mail if you are
using the exact same password that the user was using.
Your logs seem to indicate that you are logging as master_user, so you
Emm, sorry for the confusion, there are two users authenticating -
master user "postmaster" and the second user called "test". I have just
obfuscated users by replacing usernames with myuser. So no, this
shouldn't be the issue.
Any other suggestions?
On 2022-08-29 10:30, Aki Tuomi wrote:
On
> On 29/08/2022 09:26 EEST Serveria Support wrote:
>
>
> It's a testing install my main goal is to make it work. I will play
> around with password encryption before going live.
>
> I have enabled all possible debugging yet I can's see the value you
> mentioned in the log file. Could you
> On 28/08/2022 09:20 EEST Serveria Support wrote:
>
>
> I'm trying to setup Dovecot with mail-crypt plugin with per-user
> encryption.
>
> I have configured mail-crypt plugin as per official guide here:
> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
>
> After that I
I'm trying to setup Dovecot with mail-crypt plugin with per-user
encryption.
I have configured mail-crypt plugin as per official guide here:
https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
After that I created a user and an encrypted key by running this
command: doveadm -o
65 matches
Mail list logo
