Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Bernardo Reino

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 need to run ./autogen.sh first.
^^
This is from the instructions in git (INSTALL.md).

This generates, among others, the file I mentioned.


On 2022-10-11 22:15, Bernardo Reino wrote:

 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 logging. Are you sure they are
 recording successful authentications for the logs?


 OK. I thought the code would be the same. I *do* log failed
 passwords,
 so I sort of thought only about that string ("given password: ").

 I enabled debug passwords on my server, to test, so I could see
 how it
 looks like in the log.

 The "keyword" in the code seems to be "hide_pass", so if you
 search
 for that in the code, you find a few instances where passwords
 are
 (selectively) removed/replaced in a given line of text.

 But at this point I think the easiest in this absurd (IMHO) quest
 of
 yours is to patch src/config/all-settings.c, and, around line
 4141:

 static bool login_settings_check(void *_set, pool_t pool,
 const char **error_r ATTR_UNUSED)
 {
  struct login_settings *set = _set;

  set->log_format_elements_split =
   p_strsplit(pool, set->login_log_format_elements, " ");

 /* >>> INSERT HERE */
set->auth_debug_passwords = FALSE;
 /* */

  if (set->auth_debug_passwords)
set->auth_debug = TRUE;
  if (set->auth_debug)
set->auth_verbose = TRUE;
return TRUE;
 }

 If I'm right, this will just turn off the flag whenever dovecot
 checks
 the settings, i.e. regardless of what's in the actual
 dovecot.conf, so
 it should do the trick.

 But at this point this feels like a useless homework assignment,
 so I
 think I'll stop (I used to be good with C, now I'm read/only, and
 my
 time is very limited).

 (I do make a mental note of having a statically linked dovecot
 binary
 with forced password debugging. You never know when/where you
 might
 need it ;-)

 Cheers and good luck,
 Bernardo


 On 2022-10-11 17:07, Bernardo Reino wrote:

  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:
  src/auth/passdb-pam.c, around lines 175-178.
  src/auth/auth-request.c, around lines 2311-2312.

  This is with the latest source (2.3.19.1).

  Cheers.

  PS: But as I noted, nothing prevents $HACKER from bringing
  their own
  dovecot (BYOD :) with all debugging options enabled, etc. As
  others
  have noted, if the intruder owns your server, you have lost.
  Period.






Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread John Stoffel
> "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 extent, then
you're toast anyway, because they can just attach to the dovecot
process with 'gdb' and dump the data directly as well. 

Encryption is not a magic solution here, and there's no real way to
secure the system so well that once an attacker can modify files and
restart processes they are blocked.  Because they honestly looks like
an Admin doing work on the system.  



> On 2022-10-11 12:15, Benny Pedersen wrote:
>> 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,
> 
> 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 necessary, remove it
 
 remove imaps in protocol as it says
 
> auth_debug = yes
> auth_debug_passwords = yes
> auth_verbose = yes
> auth_verbose_passwords = yes
 
 change yes to no
 
 problem solved imho :)


ot: how to t/s TBird problems ?

2022-10-11 Thread Voytek Eymont
I have a Dovecot/Postfix/MariaDB on a Centos, just have a user ask me:

--
I recently upgraded my Thunderbird email client and have experienced
problems since.
It appears that when Tbird polls for new messages it gets held up
waiting for a response from the server
I'm using POP port 995.
Any ideas as to why I'm having a problem ?
---

how to investigate such issue ?

CentOS release 6.10 (Final)
# dovecot --version
2.3.11.3 (502c39af9)
load average on server 0.05/0.01
user log shows like:


Oct 12 10:08:50 pop3-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17371, TLS,
session=
Oct 12 10:09:34 pop3(u...@tld.com.au)<17371>: Info:
Disconnected: Logged out top=0/0, retr=0/0, del=0/114194, size=10616009472
Oct 12 10:14:36 imap-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17460, TLS,
session=
Oct 12 10:14:37 imap(u...@tld.com.au)<17460>: Info:
Logged out in=152 out=69724 deleted=0 expunged=0 trashed=0 hdr_count=0
hdr_bytes=0 body_count=1 body_bytes=68628
Oct 12 10:28:27 pop3-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17714, TLS,
session=<+WsXosrqK/gxw3EW>
Oct 12 10:29:16 pop3(u...@tld.com.au)<17714><+WsXosrqK/gxw3EW>: Info:
Disconnected: Logged out top=0/0, retr=1/76174, del=0/114195,
size=10616085600
Oct 12 10:32:19 imap-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17817, TLS,
session=
Oct 12 10:32:20 imap(u...@tld.com.au)<17817>: Info:
Logged out in=153 out=135592 deleted=0 expunged=0 trashed=0 hdr_count=0
hdr_bytes=0 body_count=1 body_bytes=134503
Oct 12 10:45:58 imap-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=18081, TLS,
session=
Oct 12 10:45:59 imap(u...@tld.com.au)<18081>: Info:
Logged out in=152 out=24602 deleted=0 expunged=0 trashed=0 hdr_count=0
hdr_bytes=0 body_count=1 body_bytes=23514
Oct 12 10:48:49 pop3-login: Info: Login: user=,
method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=18135, TLS,
session=
Oct 12 10:49:53 pop3(u...@tld.com.au)<18135>: Info:
Disconnected: Logged out top=0/0, retr=2/166190, del=0/114197,
size=10616251743
Oct 12 10:50:42 imap(u...@tld.com.au)<3274>: Info:
Logged out in=192516 out=5957294 deleted=0 expunged=0 trashed=0
hdr_count=263 hdr_bytes=358656 body_count=126 body_bytes=5110403
Oct 12 10:50:42 imap(u...@tld.com.au)<3271>: Info:
Logged out in=78324 out=58677 deleted=0 expunged=0 trashed=0 hdr_count=0
hdr_bytes=0 body_count=0 body_bytes=0

Voytek




Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support
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. 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 logging. Are you sure they are recording successful 
authentications for the logs?


OK. I thought the code would be the same. I *do* log failed passwords,
so I sort of thought only about that string ("given password: ").

I enabled debug passwords on my server, to test, so I could see how it
looks like in the log.

The "keyword" in the code seems to be "hide_pass", so if you search
for that in the code, you find a few instances where passwords are
(selectively) removed/replaced in a given line of text.

But at this point I think the easiest in this absurd (IMHO) quest of
yours is to patch src/config/all-settings.c, and, around line 4141:

static bool login_settings_check(void *_set, pool_t pool,
 const char **error_r ATTR_UNUSED)
{
struct login_settings *set = _set;

set->log_format_elements_split =
p_strsplit(pool, set->login_log_format_elements, " ");

/* >>> INSERT HERE */
set->auth_debug_passwords = FALSE;
/* */

if (set->auth_debug_passwords)
set->auth_debug = TRUE;
if (set->auth_debug)
set->auth_verbose = TRUE;
return TRUE;
}

If I'm right, this will just turn off the flag whenever dovecot checks
the settings, i.e. regardless of what's in the actual dovecot.conf, so
it should do the trick.

But at this point this feels like a useless homework assignment, so I
think I'll stop (I used to be good with C, now I'm read/only, and my
time is very limited).

(I do make a mental note of having a statically linked dovecot binary
with forced password debugging. You never know when/where you might
need it ;-)

Cheers and good luck,
Bernardo


On 2022-10-11 17:07, Bernardo Reino wrote:

 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:
 src/auth/passdb-pam.c, around lines 175-178.
 src/auth/auth-request.c, around lines 2311-2312.

 This is with the latest source (2.3.19.1).

 Cheers.

 PS: But as I noted, nothing prevents $HACKER from bringing their own
 dovecot (BYOD :) with all debugging options enabled, etc. As others
 have noted, if the intruder owns your server, you have lost. Period.




Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Bernardo Reino

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 logging. Are you sure they are recording successful 
authentications for the logs?


OK. I thought the code would be the same. I *do* log failed passwords, so I sort 
of thought only about that string ("given password: ").


I enabled debug passwords on my server, to test, so I could see how it looks 
like in the log.


The "keyword" in the code seems to be "hide_pass", so if you search for that in 
the code, you find a few instances where passwords are (selectively) 
removed/replaced in a given line of text.


But at this point I think the easiest in this absurd (IMHO) quest of yours is to 
patch src/config/all-settings.c, and, around line 4141:


static bool login_settings_check(void *_set, pool_t pool,
 const char **error_r ATTR_UNUSED)
{
struct login_settings *set = _set;

set->log_format_elements_split =
p_strsplit(pool, set->login_log_format_elements, " ");

/* >>> INSERT HERE */
set->auth_debug_passwords = FALSE;
/* */

if (set->auth_debug_passwords)
set->auth_debug = TRUE;
if (set->auth_debug)
set->auth_verbose = TRUE;
return TRUE;
}

If I'm right, this will just turn off the flag whenever dovecot checks the 
settings, i.e. regardless of what's in the actual dovecot.conf, so it should do 
the trick.


But at this point this feels like a useless homework assignment, so I think I'll 
stop (I used to be good with C, now I'm read/only, and my time is very limited).


(I do make a mental note of having a statically linked dovecot binary with 
forced password debugging. You never know when/where you might need it ;-)


Cheers and good luck,
Bernardo


On 2022-10-11 17:07, Bernardo Reino wrote:

 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:
 src/auth/passdb-pam.c, around lines 175-178.
 src/auth/auth-request.c, around lines 2311-2312.

 This is with the latest source (2.3.19.1).

 Cheers.

 PS: But as I noted, nothing prevents $HACKER from bringing their own
 dovecot (BYOD :) with all debugging options enabled, etc. As others
 have noted, if the intruder owns your server, you have lost. Period.




Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support

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);
e_error(authdb_event(request), "%s", str);
} else if (status == PAM_AUTH_ERR) {
str = t_strconcat(str, " 
("AUTH_LOG_MSG_PASSWORD_MISMATCH"?)", NULL);
if (request->set->debug_passwords) {
str = t_strconcat(str, " (given password: ",
  request->mech_password,
  ")", NULL);
}

and:

void auth_request_log_login_failure(struct auth_request *request,
const char *subsystem,
const char *message)

I'm not a programmer, let alone a C guru, but these extracts look like 
password failure logging. Are you sure they are recording successful 
authentications for the logs?



On 2022-10-11 17:07, Bernardo Reino wrote:

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:
src/auth/passdb-pam.c, around lines 175-178.
src/auth/auth-request.c, around lines 2311-2312.

This is with the latest source (2.3.19.1).

Cheers.

PS: But as I noted, nothing prevents $HACKER from bringing their own
dovecot (BYOD :) with all debugging options enabled, etc. As others
have noted, if the intruder owns your server, you have lost. Period.


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Jochen Bern

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 the server to have the 
plaintext password *available* for / prior to the authentication (it is 
therefor usually called a "shared secret" instead).


Before you ask, one benefit from using such schemes is that the password 
does not have to go through the wire, not even inside encryption (that a 
MitM may or may not be able to crack), so it's not a clear all-out FAIL 
to use those.


Whether the password is still in cleartext *when written to / read from 
disk* is another question, but that would be a negligible defense 
against someone who rooted your server.


Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH


Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Jochen Bern

On 11.10.22 17:46, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:

ok according to
https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html
SAN is not a valid option along with CN


... I don't see that being said in the page you refer to?

Anyhow, "stop giving a CN, use SANs instead" is a rather recent 
development coming from the CA/Browser Forum - and IIUC still not a 
*requirement*, not even for web browsers/servers. I would be surprised 
if OpenSSL (already) were trying to enforce that policy.


Hmmm, what's our company's "IMAPS server" throwing at my TB again ... ?


$ openssl s_client -connect outlook.office365.com:993 -showcerts | openssl x509 
-noout -text

[...]

Subject: C = US, ST = Washington, L = Redmond, O = Microsoft 
Corporation, CN = outlook.com

[...]
X509v3 Subject Alternative Name: 
DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, [...]


... yeah, no, nothing that Thunderbird (from 69-ish to 102) should get 
indigestion over.


Upoin further testing thunderbird seems to be locking onto the primary 
domain (*.scom.ca) of the server skipp any sni setup ??


You might want to get a network trace of your Thunderbird talking to the 
server to see what cert actually is presented by the server, and 
ideally, what domain is requested by SNI (if at all). That all happens 
before the connection starts to be encrypted, so you should be able to 
read it (say, with Wireshark) without having to crack any crypto ...


Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support

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 passwords to a remote server WITHOUT displaying
passwords in the logs.


Please compare the time needed to: get in, enable debug logging, read 
the log file with: get in, enable debug logging, realize it's not 
working (some will stop here), consider your options, build THEIR OWN 
version of dovecot that "key-logs" all passwords to a remote server 
WITHOUT displaying passwords in the logs?



This is what people mean when they say if someone has root you have
bigger problems then dovecot logging.


I generally agree but only if the mail storage is unencrypted. With 
encrypted storage I can think of many scenarios: corrupt law 
enforcement, malicious freelance admin, social engineering tricks etc 
etc etc when attackers will have not enough time/expertise to grab your 
passwords.


On 2022-10-11 18:16, dove...@ptld.com wrote:
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 fears are moot and the
suggestion to remove code logging passwords offers zero protection.

If someone has root they can just read the email storage files, no
password needed.

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 passwords to a remote server WITHOUT displaying
passwords in the logs.

This is what people mean when they say if someone has root you have
bigger problems then dovecot logging.


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread John Tulp
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 cause any other problems on
the server.

they do this to avoid getting noticed by admins.

as long as admin does not know there is malware on their server, the
malware could run for years harvesting passwords.  That would be the
hypothetical attackers only goal on that server - not to bother
anything, just to harvest user email passwords.

and the admin will not be dealing with a "bigger problem", because the
admin will not know they've been hacked, because hacker does not cause
any problems on the server.  admin will think everything is fine on
their server.

there could be email servers right now that are compromised and yielding
passwords in this way, and if dovecot suddenly started writing those
passwords the logs in some scrambled way - the malware would suddenly
stop being able to harvest clear text passwords.  hacker then could
either quietly go away, or start doing something else on the machine,
which the admins may or may not become aware of.  might get a big
surprise that they've been hacked.

This type of "quiet" malware of course definitely exists in the real
world, for example, on phones.  Many people's phones have been hacked
and they are unaware of it, and they continue using the phone for years
without realizing it's been hacked.

Sometimes attackers mess up the devices they hack, sometimes they don't,
they just quietly use the hacked device for their own purposes (which of
course are the hacks to really worry about).  whenever there are big
announcements of hacks to major organizations, the story always unfolds
that the hackers had access for quite a while before admins became
aware.  this is the timeframe that really puts one's "security efforts"
to the test - after machine is compromised, but before admins are aware.

it makes no sense to make things easy for hackers during this time when
they are operating in the target machines/network and the admins are not
yet aware that devices have been compromised.

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.



-- 
John Tulp 
tulpex

On Tue, 2022-10-11 at 17:58 +0300, Odhiambo Washington wrote:
> @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 "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 that case,
> all  they
> would do is send back the treasure trove of passwords to their
> home
> server(s), and sit there, remaining possibly for years,
> hiding,
> exploiting the fact that dovecot, with no code modification,
> will allow
> them to grab email passwords.  If a dovecot server has
> thousands of
> email accounts, that represents thousands of other devices
> they could
> target, which is worth much more to the attacker than a single
> dovecot
> server.
> 
> Oh well, food for thought.
> 
> 
> On Tue, 2022-10-11 at 15:11 +0300, 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 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 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 problems than leaking your users' password. Much
> bigger...
> 
> 
> 
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)



Re: One-off backup

2022-10-11 Thread Ian Evans
On Tue, Oct 11, 2022, 12:02 PM Tim Dickson, 
wrote:

> you would want to backup your dovecot/postfix config files and mail
> certificates as well, and your database if you are using one for
> authentication, and user list, just in case.
>
>
> Almost forgot about that. Guess I should ask about their snapshot service
and see if that saves me some headaches/time.

>
>


Re: One-off backup

2022-10-11 Thread Tim Dickson
you would want to backup your dovecot/postfix config files and mail 
certificates as well, and your database if you are using one for 
authentication, and user list, just in case.


On 11/10/2022 16:26, justina colmena ~biz wrote:
Is that a divorce? Or else a little bit better spelling and respect 
for the lady is called for? And I don't like criminals serving bogus 
law papers and hacking into my mail any more than anyone else does.


On October 10, 2022 6:57:39 AM AKDT, Ian Evans  
wrote:


I run a small email server for me and the missus. Six dovecot users.

Our host is migrating our server instance. They usually (99.%
lol) go off without a hitch.

As we don't have dovecot running elsewhere, I'm assuming doveadm
is the wrong tool.

If we want to make a one-off backup prior to the migration, is
shutting down postfix and running
tar czf mailstorage.tgz /path/to/mail okay?

Thanks.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Paul Kudla (SCOM.CA Internet Services Inc.)



ok according to

https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html

SAN is not a valid option along with CN

CN is part of the subject ??

Upoin further testing thunderbird seems to be locking onto the primary 
domain (*.scom.ca) of the server skipp any sni setup ??


again thoughts 




Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 9:17 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



ok it appears that all this revolves around openssl

does anyone have explicit instructions on how to generate a proper ssl

key, csr etc file

with the proper SAN & CN etc

i tried

# openssl req -new -nodes -newkey rsa:2048 -config ./openssl.cnf 
-reqexts req_ext -keyout mail.paulkudla.net.key -out mail.paulkudla.net.csr

Error Loading request extension section req_ext

34371092480:error:22075075:X509 V3 
routines:v2i_GENERAL_NAME_ex:unsupported 
option:/usr/src/crypto/openssl/crypto/x509v3/v3_alt.c:534:name=SAN.1


34371092480:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:/usr/src/crypto/openssl/crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=@alt_names


and got the errors above

there not seem to be much on the web about how to generate these certs??



Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 7:47 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



Good morning to all

i guess things have changed yet again

to keep this simple :

i buy a certificate (example) : mail.paulkudla.net

i generated the key / csr as per normal using

data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out 
/tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' 
%(country,state,location,organization,self.domain)


please note the above is done in django

(yes i am running thunderbird v102)

i go buy the certificate

i database the CRT & CA

CSR is :

-BEGIN CERTIFICATE REQUEST-
MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN
BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp
bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY
rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv
lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN
15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc
ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc
juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi
WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4
VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9
7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk
9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu
iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5
yq88NESoIYaO6Do=
-END CERTIFICATE REQUEST-

CRT is :

-BEGIN CERTIFICATE-
MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h
aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr
GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E
r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb
DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB
nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj
HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU
rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF
BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF
BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w
YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW
eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC
igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv
vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct
tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW
Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj
jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u

Re: One-off backup

2022-10-11 Thread justina colmena ~biz
Is that a divorce? Or else a little bit better spelling and respect for the 
lady is called for? And I don't like criminals serving bogus law papers and 
hacking into my mail any more than anyone else does.

On October 10, 2022 6:57:39 AM AKDT, Ian Evans  wrote:
>I run a small email server for me and the missus. Six dovecot users.
>
>Our host is migrating our server instance. They usually (99.% lol) go
>off without a hitch.
>
>As we don't have dovecot running elsewhere, I'm assuming doveadm is the
>wrong tool.
>
>If we want to make a one-off backup prior to the migration, is shutting
>down postfix and running
>tar czf mailstorage.tgz /path/to/mail okay?
>
>Thanks.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread dovecot

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 fears are moot and the suggestion to remove code 
logging passwords offers zero protection.

If someone has root they can just read the email storage files, no password 
needed.

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 passwords to a remote 
server WITHOUT displaying passwords in the logs.

This is what people mean when they say if someone has root you have bigger 
problems then dovecot logging.


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Odhiambo Washington
@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 "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 that case, all  they
> would do is send back the treasure trove of passwords to their home
> server(s), and sit there, remaining possibly for years, hiding,
> exploiting the fact that dovecot, with no code modification, will allow
> them to grab email passwords.  If a dovecot server has thousands of
> email accounts, that represents thousands of other devices they could
> target, which is worth much more to the attacker than a single dovecot
> server.
>
> Oh well, food for thought.
>
>
> On Tue, 2022-10-11 at 15:11 +0300, 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 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 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 problems than leaking your users' password. Much bigger...
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support

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 root access and seeing 
customers' password there in clear text? )))


On 2022-10-11 17:38, John Tulp wrote:


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 that case, all  
they

would do is send back the treasure trove of passwords to their home
server(s), and sit there, remaining possibly for years, hiding,
exploiting the fact that dovecot, with no code modification, will allow
them to grab email passwords.  If a dovecot server has thousands of
email accounts, that represents thousands of other devices they could
target, which is worth much more to the attacker than a single dovecot
server.

Oh well, food for thought.


On Tue, 2022-10-11 at 15:11 +0300, 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 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 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 problems than leaking your users' password. Much bigger...


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread John Tulp
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 that case, all  they
would do is send back the treasure trove of passwords to their home
server(s), and sit there, remaining possibly for years, hiding,
exploiting the fact that dovecot, with no code modification, will allow
them to grab email passwords.  If a dovecot server has thousands of
email accounts, that represents thousands of other devices they could
target, which is worth much more to the attacker than a single dovecot
server.

Oh well, food for thought.


On Tue, 2022-10-11 at 15:11 +0300, 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 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 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 problems than leaking your users' password. Much bigger...



Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Benny Pedersen

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 should be no

first step to secure it

next step is to secure syslogs





Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Bernardo Reino

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:
src/auth/passdb-pam.c, around lines 175-178.
src/auth/auth-request.c, around lines 2311-2312.

This is with the latest source (2.3.19.1).

Cheers.

PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot 
(BYOD :) with all debugging options enabled, etc. As others have noted, if the 
intruder owns your server, you have lost. Period.


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Odhiambo Washington
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 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 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 problems than leaking your users' password. Much bigger...
>


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)


Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Paul Kudla (SCOM.CA Internet Services Inc.)



ok it appears that all this revolves around openssl

does anyone have explicit instructions on how to generate a proper ssl

key, csr etc file

with the proper SAN & CN etc

i tried

# openssl req -new -nodes -newkey rsa:2048 -config ./openssl.cnf 
-reqexts req_ext -keyout mail.paulkudla.net.key -out mail.paulkudla.net.csr

Error Loading request extension section req_ext

34371092480:error:22075075:X509 V3 
routines:v2i_GENERAL_NAME_ex:unsupported 
option:/usr/src/crypto/openssl/crypto/x509v3/v3_alt.c:534:name=SAN.1


34371092480:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:/usr/src/crypto/openssl/crypto/x509v3/v3_conf.c:47:name=subjectAltName, 
value=@alt_names


and got the errors above

there not seem to be much on the web about how to generate these certs??



Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 7:47 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



Good morning to all

i guess things have changed yet again

to keep this simple :

i buy a certificate (example) : mail.paulkudla.net

i generated the key / csr as per normal using

data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out 
/tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' 
%(country,state,location,organization,self.domain)


please note the above is done in django

(yes i am running thunderbird v102)

i go buy the certificate

i database the CRT & CA

CSR is :

-BEGIN CERTIFICATE REQUEST-
MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN
BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp
bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY
rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv
lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN
15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc
ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc
juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi
WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4
VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9
7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk
9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu
iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5
yq88NESoIYaO6Do=
-END CERTIFICATE REQUEST-

CRT is :

-BEGIN CERTIFICATE-
MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h
aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr
GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E
r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb
DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB
nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj
HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU
rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF
BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF
BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w
YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW
eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC
igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv
vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct
tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW
Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj
jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u
AAABgWzEkYoAAAQDAEcwRQIgOYjevKp5RI+c0JhIi6JflaxiNokRTSeXN6LrdIVt
Cf8CIQCG+aLreYVV8xCPV0skr0ats5zMf5PLPN2y8EIxGPPNVTANBgkqhkiG9w0B
AQsFAAOCAQEAJX544qDTgkGGLUOher7tH7yUgEhQFYkBDAirO37MXrhtuzH6pGSp
XfYVNB9e2ydprfmLDh8O8oTaXpaQfp/jwK3U0GfvG57MfdQTLOunpWnCjaMUPUcv
jPU90/mXc5oWlO5iJ6jPDkS/x47K03P6vftSr7AMwnLq4kYwuG9fHLslMHhoojen
9S2G1QjKVp5jkFecmQib+JOZV9Ub9r6iumHICfdcSO+tyBL2IDqWDQhuAVUXgyOV
11O9ZgikoeRhgsMhwiQA1z/Fs6Xqx/XCs6nUciebRiQuuHYm/PUG2H+tg0sLhJ6L
ntIEhjjkumL0oJEfDidP/8wmrsPuwfSDCQ==
-END CERTIFICATE-

CA (INTER) :

-BEGIN CERTIFICATE-
MIIGEzCCA/ugAwIBAgIQfVtRJrR2uhHbdBYLvFMNpzANBgkqhkiG9w0BAQwFADCB

Re: dovecot mailing list (this mailing list), DKIM, SPF and DMARC

2022-10-11 Thread Benny Pedersen

hi@zakaria.website skrev den 2022-10-11 13:42:

On 2022-09-13 13:10, Benny Pedersen wrote:

hi@zakaria.website skrev den 2022-09-13 14:03:



from:from:reply-to:date:date:message-id:message-id:to:to:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references

Thanks to my friend who didnt need a credit, and helped me out in
reaching this solution.


i have no frinds, but it might be related 
https://gitlab.com/fumail/fuglu/-/issues/262


with my conservative list of signed headers it pass


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support
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 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 problems than leaking your users' password. Much bigger...


Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Paul Kudla (SCOM.CA Internet Services Inc.)



Good morning to all

i guess things have changed yet again

to keep this simple :

i buy a certificate (example) : mail.paulkudla.net

i generated the key / csr as per normal using

data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out 
/tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' 
%(country,state,location,organization,self.domain)


please note the above is done in django

(yes i am running thunderbird v102)

i go buy the certificate

i database the CRT & CA

CSR is :

-BEGIN CERTIFICATE REQUEST-
MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN
BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp
bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY
rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv
lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN
15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc
ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc
juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi
WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4
VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9
7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk
9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu
iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5
yq88NESoIYaO6Do=
-END CERTIFICATE REQUEST-

CRT is :

-BEGIN CERTIFICATE-
MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h
aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr
GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E
r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb
DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB
nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj
HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU
rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF
BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF
BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w
YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW
eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC
igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv
vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct
tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW
Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj
jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u
AAABgWzEkYoAAAQDAEcwRQIgOYjevKp5RI+c0JhIi6JflaxiNokRTSeXN6LrdIVt
Cf8CIQCG+aLreYVV8xCPV0skr0ats5zMf5PLPN2y8EIxGPPNVTANBgkqhkiG9w0B
AQsFAAOCAQEAJX544qDTgkGGLUOher7tH7yUgEhQFYkBDAirO37MXrhtuzH6pGSp
XfYVNB9e2ydprfmLDh8O8oTaXpaQfp/jwK3U0GfvG57MfdQTLOunpWnCjaMUPUcv
jPU90/mXc5oWlO5iJ6jPDkS/x47K03P6vftSr7AMwnLq4kYwuG9fHLslMHhoojen
9S2G1QjKVp5jkFecmQib+JOZV9Ub9r6iumHICfdcSO+tyBL2IDqWDQhuAVUXgyOV
11O9ZgikoeRhgsMhwiQA1z/Fs6Xqx/XCs6nUciebRiQuuHYm/PUG2H+tg0sLhJ6L
ntIEhjjkumL0oJEfDidP/8wmrsPuwfSDCQ==
-END CERTIFICATE-

CA (INTER) :

-BEGIN CERTIFICATE-
MIIGEzCCA/ugAwIBAgIQfVtRJrR2uhHbdBYLvFMNpzANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgx
MTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBjzELMAkGA1UEBhMCR0IxGzAZBgNV
BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UE
ChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5TZWN0aWdvIFJTQSBEb21haW4g
VmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA1nMz1tc8INAA0hdFuNY+B6I/x0HuMjDJsGz99J/LEpgPLT+N
TQEMgg8Xf2Iu6bhIefsWg06t1zIlk7cHv7lQP6lMw0Aq6Tn/2YHKHxYyQdqAJrkj
eocgHuP/IJo8lURvh3UGkEC0MpMWCRAIIz7S3YcPb11RFGoKacVPAXJpz9OTTG0E
oKMbgn6xmrntxZ7FN3ifmgg0+1YuWMQJDgZkW7w33PGfKGioVrCSo1yfu4iYCBsk
Haswha6vsC6eep3BwEIc4gLw6uBK0u+QDrTBQBbwb4VCSmT3pDCg/r8uoydajotY
uK3DGReEY+1vVv2Dy2A0xHS+5p3b4eTlygxfFQIDAQABo4IBbjCCAWowHwYDVR0j
BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFI2MXsRUrYrhd+mb
+ZsF4bgBjWHhMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAbBgNVHSAEFDASMAYGBFUdIAAw
CAYGZ4EMAQIBMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0

dovecot mailing list (this mailing list), DKIM, SPF and DMARC

2022-10-11 Thread hi

On 2022-09-13 13:10, Benny Pedersen wrote:

hi@zakaria.website skrev den 2022-09-13 14:03:


least to must pass Signature Verification. Have anyone managed to
configure EXIM to verify more than one DKIM Signature header?


postfix smtpd_milter_maps with a list of ips that is known maillists 
ips is best for software that are brokken, use DISABLE as results pr ip 
that is maillist ips, that will disabled opendmarc and other milters 
when client ip is a maillist, postfix be happy until trusted domain 
have updated and stable milters


use rspamd if possible, with is imho the only stable milters with solve 
it all, i hate to write that but it might be right for time being, 
while spamassassin v4 is on the way


Another update yet with a solution.

I found the causing issue with DKIM and DMARC failure when a signed 
email pass through mailing list such as dovecot as I expected, it has 
nothing to do with the mailing list but it's to do with DKIM signing 
headers set. It's due to one of or several headers in the DKIM signing 
set, getting added or modified after signing at dovecot end.


Anyhow, here is the DKIM signing headers set in this mailing list, that 
it should work and it will prevent the batch of DMARC emails and bad 
signature from happening again.


from:from:reply-to:date:date:message-id:message-id:to:to:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references

Thanks to my friend who didnt need a credit, and helped me out in 
reaching this solution.


Zakaria.


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Arjen de Korte

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 problems than leaking your users' password. Much bigger...




Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Benny Pedersen

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 or 
not ?


if thats the case i will just suggest make your own problem


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread 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. :)


On 2022-10-11 12:15, Benny Pedersen wrote:

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,

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 necessary, remove it


remove imaps in protocol as it says


auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = yes


change yes to no

problem solved imho :)


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Benny Pedersen

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,

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 necessary, remove it


remove imaps in protocol as it says


auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = yes


change yes to no

problem solved imho :)


Re: Dovecot mail-crypt webmail can't read encrypted messages

2022-10-11 Thread Serveria Support

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 config file with:
doveconf -Pn > dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25:
'imaps' protocol is no longer necessary, remove it


remove imaps in protocol as it says


auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = yes


change yes to no

problem solved imho :)


Re: One-off backup

2022-10-11 Thread Odhiambo Washington
On Tue, Oct 11, 2022 at 11:26 AM Cristiano Deana 
wrote:

> Il 10/10/2022 16:57, Ian Evans ha scritto:
>
> > is shutting down postfix and running
> > tar czf mailstorage.tgz /path/to/mail okay?
>
> remember -p to preserve permissions.
>

I have never imagined that tar requires a -p to preserve permissions.
Are you talking about cp?


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)


Re: One-off backup

2022-10-11 Thread Cristiano Deana

Il 10/10/2022 16:57, Ian Evans ha scritto:


is shutting down postfix and running
tar czf mailstorage.tgz /path/to/mail okay?


remember -p to preserve permissions.

--

###
# Cristiano Deana #
# #
# Senior Network Engineer #
# Digital Response Team #
# CittaStudi S.p.a. #
# off. +39 015 855 1172 #
# cell +39 328 310 6392 #
###


Re: Unseen field reported by imap status command returns wrong count for shared mailboxes on dovecot cluster

2022-10-11 Thread Aki Tuomi
Hi!

This seems to be a bug in imapc client, we'll look into this. Thank you for 
reporting this issue. It's currently tracked as DOV-5579.

Aki

> On 07/10/2022 15:38 EEST Nikolaos Pyrgiotis  wrote:
> 
> 
> Hello, 
> 
> I want to make a correction on my first post. We are using version 2.3.19.1 
> for all our dovecot servers. Is there any update regarding this issue? I 
> would be happy to provide more details if necessary.
> 
> Best Regards,
> Nikos Pyrgiotis
> 
> On 8/9/22 17:47, Nikolaos Pyrgiotis wrote:
> 
> > Hello,
> > We recently migrated our mail server to a dovecot cluster of5nodes, a 
> > dovecot proxy,2directors and2dovecot backends.
> > All dovecot nodes run version2.19.1. We use a glusterfs mounted volume on 
> > the backendsforthe mail storage.
> > We noticed that when issuing the IMAP command to checkforUNSEEN 
> > messagesformails on the shared namespace instead of seeing the value of the 
> > unseen messages of the user that the mailbox has been shared to,
> > the value of the unseen messages of the owner of the mailbox is returned.
> > This behavior causes thunderbird when getting new messagesforshared 
> > mailboxes, to show briefly all messages of the mailbox as unseenforthe user 
> > before showing the correct unseen countforthe shared mailbox.
> > The mail location of the shared mailboxes is defined with imapc storage 
> > type as describedinthe documentation.
> > Is this a dovecot bug? Can we configure a different dovecot configuration 
> > setting so that imap status command reports the correct unseen field count 
> > when mail location is an imapc storage location?
> > 
> > An examples is given below when running doveadm command from one the 2 
> > dovecot directors:
> > When issuing the status command we see that the unseen count is2:
> > root@doved0-rmt0-cn1:/etc/cron.d# doveadm mailbox status -u npyrgiotis all 
> > shared.sysadmins doveadm(npyrgiotis): Info: remote(10.101.0.71:8080): 
> > doveadm(npyrgio...@domie02.com)<19078><9l8IJTb+GWOGSgAAEU9A+w>: 
> > imapc(10.101.0.75:143): Connected to 10.101.0.75:143 (local 
> > 10.101.0.71:33476) shared.sysadmins messages=2 recent=0 uidnext=3 
> > uidvalidity=1662640492 unseen=2 highestmodseq=3 vsize=3950 
> > guid=c92f64f79f0d1ed01e6d5b314f04886c firstsaved=1662643853
> > shared.sysadmins 
> > messages=2recent=0uidnext=3uidvalidity=1662640492unseen=2highestmodseq=3vsize=3950guid=c92f64f79f0d1ed01e6d5b314f04886c
> >  firstsaved=1662643853
> > 
> > But when fetching the emails of the mailboxes we can see that the \Seen 
> > flag is set for both emails
> > 
> > root@doved0-rmt0-cn1:/etc/cron.d# doveadm fetch -u npyrgiotis flags mailbox 
> > shared.sysadmins ALL doveadm(npyrgiotis): Info: remote(10.101.0.71:8080): 
> > doveadm(npyrgio...@domie02.com)<19074>: 
> > imapc(10.101.0.75:143): Connected to 10.101.0.75:143 (local 
> > 10.101.0.71:38750) flags: \Seen flags: \Seen 
> > Below i post the dovecot configuration of one of the two dovecot backends:
> > #2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf
> > # Pigeonhole version0.5.19 (4eae2f79)
> > # OS: Linux5.10.0-17-amd64 x86_64 Debian11.4
> > # Hostname: doveb0-rmt0-cn1
> > auth_cache_negative_ttl =5mins
> > auth_cache_size =50M
> > auth_debug = yes
> > auth_default_realm = example.com
> > auth_master_user_separator = *
> > auth_mechanisms = plain login
> > auth_verbose = yes
> > auth_worker_max_count =16
> > disable_plaintext_auth = no
> > first_valid_uid =499
> > hostname = smtp.example.com
> > imapc_features = fetch-bodystructure fetch-headers rfc822.size search 
> > modseq acl delay-login
> > imapc_host =10.101.0.75
> > imapc_password = # hidden, use -P to show it
> > imapc_sasl_mechanisms = plain login
> > imapc_ssl = starttls
> > imapc_ssl_verify = no
> > last_valid_uid =499
> > lda_mailbox_autocreate = yes
> > lda_mailbox_autosubscribe = yes
> > login_greeting = You have successfully loggedinto example.com IMAP server
> > login_trusted_networks =10.101.0.7310.101.0.74
> > mail_always_cache_fields = flags hdr.* date.received date.sent
> > mail_cache_fields = flags date.received guid size.physical size.virtual 
> > imap.bodystructure body.snippet
> > mail_debug = yes
> > mail_fsync = always
> > mail_plugins =" notify mail_log zlib acl"
> > mail_privileged_group = mail
> > 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
> > mdbox_rotate_size =200M
> > mmap_disable = yes
> > namespace example {
> > list = children
> > location = imapc:~/shared/%%n:INDEXPVT=~/shared-pvt/%%n
> > prefix = shared.%%n.
> > separator = .
> > subscriptions = no
> > type = shared
> > }
> > namespace inbox {
> > inbox = yes
> > location =
> > mailbox Drafts {
> > special_use = \Drafts
> > }
> > mailbox Junk {
> > special_use = \Junk
> > }
>