Re: Panic: file mail-index-util.c: line 37 (mail_index_uint32_to_offset): assertion failed: (offset < 0x40000000)

[Stefan Neben]

Hi,

> You are storing 1.7 million e-mails in a single mbox file.

no, of course not:

mdbox_rotate_size = 64 M

> I would rather store the archive using one file per e-mail.

I think one file per mail would be not good for this setup. One
keypoint is that the INBOX is searchable (in a acceptable amount of
time). Further this probably could slow down the backup process (i
think).

2018-01-11 0:46 GMT+01:00 Rupert Gallagher :
> You are storing 1.7 million e-mails in a single mbox file. I would rather
> store the archive using one file per e-mail.

Ignored mount points forgotten on reboot

[Kenneth Porter]

The list of ignored mount points are stored in a directory (/var/run) 
that's cleared on  reboot. (On CentOS it's a RAM disk.) It seems this 
should be stored in /etc/dovecot to remain persistent across reboots.




I discovered this when I saw a dovecot error message in /var/log/maillog 
that some of my automounts (that don't contain mail directories) were 
missing.


Latest dovecot from this distro is dovecot-2.2.10-8.el7.x86_64. Does the 
new release fix this? (I haven't seen any real problems from it, just log 
noise.) 

Re: Bug in dovecot 2.3 virtual plugin

[Jakob Schürz]

Hi!

Now an error is back. I didn't change my configuration and get now this
error, whily i try to refresh my thunderbird. I think it happens in a
virtual folder again.


Jän 11 01:29:19 aldebaran dovecot[11597]: imap-login: Login:
user=, method=CRAM-MD5, rip=127.0.0.1, lip=127.0.0.1, mpid=5008,
TLS, session=<+MAgPXVisrx/AAAB>
Jän 11 01:29:22 aldebaran dovecot[11597]:
imap(jakob)<5008><+MAgPXVisrx/AAAB>: Panic: file mail-index.c: line 793
(mail_index_close): assertion failed: (index->open_count > 0)
Jän 11 01:29:22 aldebaran dovecot[11597]:
imap(jakob)<5008><+MAgPXVisrx/AAAB>: Error: Raw backtrace:
/usr/local/lib/dovecot/libdovecot.so.0(+0xc6021) [0x7fd17fbb9021] ->
/usr/local/lib/dovecot/libdovecot.so.0(+0xc60ed) [0x7fd17fbb90ed] ->
/usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fd17fb2b481] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(+0xf39a8)
[0x7fd17ff589a8] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(+0xd92d1)
[0x7fd17ff3e2d1] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(+0xd9363)
[0x7fd17ff3e363] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(index_storage_mailbox_free+0x9)
[0x7fd17ff2ff39] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(+0xd05a4)
[0x7fd17ff355a4] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_free+0x19)
[0x7fd17feafc99] ->
/usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xabdc) [0x7fd17b11abdc]
-> /usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xacb9)
[0x7fd17b11acb9] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_close+0x1a)
[0x7fd17feafc0a] ->
/usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xac60) [0x7fd17b11ac60]
-> /usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xacb9)
[0x7fd17b11acb9] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_close+0x1a)
[0x7fd17feafc0a] ->
/usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xac60) [0x7fd17b11ac60]
-> /usr/local/lib/dovecot/lib20_virtual_plugin.so(+0xacb9)
[0x7fd17b11acb9] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_close+0x1a)
[0x7fd17feafc0a] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_free+0x13)
[0x7fd17feafc93] -> dovecot/imap [jakob 127.0.0.1
select](imap_client_close_mailbox+0x5b) [0x5633bdd9905b] -> dovecot/imap
[jakob 127.0.0.1 select](+0x14f03) [0x5633bdd90f03] -> dovecot/imap
[jakob 127.0.0.1 select](cmd_select_full+0xf9) [0x5633bdd91129] ->
dovecot/imap [jakob 127.0.0.1 select](command_exec+0x64)
[0x5633bdd98ca4] -> dovecot/imap [jakob 127.0.0.1 select](+0x1b0b2)
[0x5633bdd970b2] -> dovecot/imap [jakob 127.0.0.1 select](+0x1b13c)
[0x5633bdd9713c] -> dovecot/imap [jakob 127.0.0.1
select](client_handle_input+0x1a5) [0x5633bdd97565] -> dovecot/imap
[jakob 127.0.0.1 select](client_input+0x82) [0x5633bdd97be2] ->
/usr/local/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69)
[0x7fd17fbd0c09]
Jän 11 01:29:22 aldebaran dovecot[11597]:
imap(jakob)<5008><+MAgPXVisrx/AAAB>: Fatal: master: service(imap): child
5008 killed with signal 6 (core not dumped)


Am 2018-01-05 um 10:25 schrieb Aki Tuomi:
> This is a different bug, and I suspect it might be caused by virtual
> plugin. We'll look into it.
> 
> Aki
> 
> On 04.01.2018 23:41, Jakob Schürz wrote:
>> Hi!
>>
>> This is very strange...
>> This error affects only one mailaccount, and it happend not yesterday.
>> The file
>>
>> /var/lib/dovecot/db/indexes/Maildir/jakob/INBOX/dovecot.index
>>
>> which hat "Panic: Leaked view for index" does not exist. only
>> dovecot.index.log and .cache exists in this mailbox. (which is normal
>> for small mailboxes, i've read). But why is dovecot throwing an error?
>>
>> And i could find out, this is only, when i try to open a virtual folder.
>>
>> I switched back to older self-compiled dovecot-versions... but the error
>> exists also there (but not before the update!!!)
>>
>> I also deleted all the dovecot.index-files, dovecot.index.log and
>> dovecot.index.cache-files to let rebuild dovecot the index again... the
>> error persists.
>>
>> Is it a misconfiguration?
>>
>> So i tried to build for the virtual-Mailboxes the Index in memory... the
>> error persists and dovecot wants to read this index-file.
>>
>> My virtual folders not working any longer (on this account only!)
>>
>> For debug purpose i deleted all the emails in this mailbox, the error
>> dissapered on this folder, but comes back in the next folder.
>>
>> could this be a problem with ulimit?
>>
>> greez
>> jakob
>>
>> Am 2018-01-04 um 11:07 schrieb Jakobus Schürz:
>>> Hi!
>>>
>>> Is this a bug according to the other one?
>>>
>>> When i try to open a real or virtual mailbox, i often (not on every
>>> mailbox) get this error-message:
>>>
>>> Jän 04 11:03:32 aldebaran dovecot[24534]:
>>> imap(jakob)<24705>: Panic: Leaked view for index
>>> /var/lib/dovecot/db/indexes/Maildir/jakob/INBOX/dovecot.index: Opened in
>>> index-storage.c:336
>>> Jän 04 11:03:32 aldebaran dovecot[24534]:
>>> imap(jakob)<24705>: Error: Raw backtrace:
>>> /usr/local/lib/dovecot/libdovecot.so.0(+0xc6021) [0x7f47d5872021] ->
>>> 

Re: Panic: file mail-index-util.c: line 37 (mail_index_uint32_to_offset): assertion failed: (offset < 0x40000000)

[Rupert Gallagher]

You are storing 1.7 million e-mails in a single mbox file. I would rather store 
the archive using one file per e-mail.

Re: Dovecot 2.3.0 imap-login using 100% CPU

[Jason Kiniry]

We were able to obtain a better backtrace:

0x7f4b303b5af5 in clients_notify_auth_connected () at 
client-common-auth.c:839
839 if (!client_does_custom_io(client) && 
client->input_blocked) {
(gdb) run

Thank you!

Regards,

Jason Kiniry

> On Jan 10, 2018, at 4:28 PM, Jason Kiniry  wrote:
> 
> When in the process of testing out the 2.3.0 version of Dovecot, we noticed 
> that on a busy server, imap-login can sometimes take 100% CPU and remain 
> there indefinitely. We grabbed a gdb trace while it was happening:
> 
> dovenull 36053 31.2  0.0  60460 17316 ?R04:38  11:55 
> dovecot/imap-login
> root@server [~]# strace -p 36053
> Process 36053 attached
> ^CProcess 36053 detached
> root@server [~]# gdb 
> atGNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> .
> (gdb) attach 36053
> Attaching to process 36053
> Reading symbols from /usr/libexec/dovecot/imap-login...done.
> Reading symbols from /usr/lib64/dovecot/libdovecot-login.so.0...done.
> Loaded symbols for /usr/lib64/dovecot/libdovecot-login.so.0
> Reading symbols from /usr/lib64/dovecot/libdovecot.so.0...done.
> Loaded symbols for /usr/lib64/dovecot/libdovecot.so.0
> Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libc.so.6
> Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib64/libssl.so.10
> Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib64/libcrypto.so.10
> Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib64/librt.so.1
> Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libdl.so.2
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libgssapi_krb5.so.2
> Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libkrb5.so.3
> Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libcom_err.so.2
> Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libk5crypto.so.3
> Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libz.so.1
> Reading symbols from /lib64/libpthread.so.0...(no debugging symbols 
> found)...done.
> [Thread debugging using libthread_db enabled]
> Loaded symbols for /lib64/libpthread.so.0
> Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libkrb5support.so.0
> Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libkeyutils.so.1
> Reading symbols from /lib64/libresolv.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libresolv.so.2
> Reading symbols from /lib64/libselinux.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib64/libselinux.so.1
> Reading symbols from /usr/lib64/dovecot/libssl_iostream_openssl.so...done.
> Loaded symbols for /usr/lib64/dovecot/libssl_iostream_openssl.so
> 0x7f758fb8dd18 in client_notify_auth_ready@plt () from 
> /usr/lib64/dovecot/libdovecot-login.so.0
> Missing separate debuginfos, use: debuginfo-install 
> dovecot-2.3.0-4.cp1162.x86_64
> (gdb) back
> #0  0x7f758fb8dd18 in client_notify_auth_ready@plt () from 
> /usr/lib64/dovecot/libdovecot-login.so.0
> #1  0x7f758fb90af0 in clients_notify_auth_connected () at 
> client-common-auth.c:837
> #2  0x7f758f8cfc04 in auth_server_input_done (conn=0x7f7591911838) at 
> auth-server-connection.c:127
> #3  auth_server_connection_input_line (conn=0x7f7591911838) at 
> auth-server-connection.c:229
> #4  auth_server_connection_input (conn=0x7f7591911838) at 
> auth-server-connection.c:281
> #5  0x7f758f8f5e35 in io_loop_call_io (io=0x7f759277e2a0) at ioloop.c:614
> #6  0x7f758f8f7d3f in io_loop_handler_run_internal (ioloop= optimized out>) at ioloop-epoll.c:222
> #7  0x7f758f8f5f25 in io_loop_handler_run (ioloop=0x7f75918e4d00) at 
> ioloop.c:666
> #8  0x7f758f8f6148 in io_loop_run (ioloop=0x7f75918e4d00) at ioloop.c:639
> #9  

Dovecot 2.3.0 imap-login using 100% CPU

[Jason Kiniry]

When in the process of testing out the 2.3.0 version of Dovecot, we noticed 
that on a busy server, imap-login can sometimes take 100% CPU and remain there 
indefinitely. We grabbed a gdb trace while it was happening:

dovenull 36053 31.2  0.0  60460 17316 ?R04:38  11:55 
dovecot/imap-login
root@server [~]# strace -p 36053
Process 36053 attached
^CProcess 36053 detached
root@server [~]# gdb 
atGNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
.
(gdb) attach 36053
Attaching to process 36053
Reading symbols from /usr/libexec/dovecot/imap-login...done.
Reading symbols from /usr/lib64/dovecot/libdovecot-login.so.0...done.
Loaded symbols for /usr/lib64/dovecot/libdovecot-login.so.0
Reading symbols from /usr/lib64/dovecot/libdovecot.so.0...done.
Loaded symbols for /usr/lib64/dovecot/libdovecot.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols 
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libselinux.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /usr/lib64/dovecot/libssl_iostream_openssl.so...done.
Loaded symbols for /usr/lib64/dovecot/libssl_iostream_openssl.so
0x7f758fb8dd18 in client_notify_auth_ready@plt () from 
/usr/lib64/dovecot/libdovecot-login.so.0
Missing separate debuginfos, use: debuginfo-install 
dovecot-2.3.0-4.cp1162.x86_64
(gdb) back
#0  0x7f758fb8dd18 in client_notify_auth_ready@plt () from 
/usr/lib64/dovecot/libdovecot-login.so.0
#1  0x7f758fb90af0 in clients_notify_auth_connected () at 
client-common-auth.c:837
#2  0x7f758f8cfc04 in auth_server_input_done (conn=0x7f7591911838) at 
auth-server-connection.c:127
#3  auth_server_connection_input_line (conn=0x7f7591911838) at 
auth-server-connection.c:229
#4  auth_server_connection_input (conn=0x7f7591911838) at 
auth-server-connection.c:281
#5  0x7f758f8f5e35 in io_loop_call_io (io=0x7f759277e2a0) at ioloop.c:614
#6  0x7f758f8f7d3f in io_loop_handler_run_internal (ioloop=) at ioloop-epoll.c:222
#7  0x7f758f8f5f25 in io_loop_handler_run (ioloop=0x7f75918e4d00) at 
ioloop.c:666
#8  0x7f758f8f6148 in io_loop_run (ioloop=0x7f75918e4d00) at ioloop.c:639
#9  0x7f758f875ab3 in master_service_run (service=0x7f75918e4b90, 
callback=) at master-service.c:767
#10 0x7f758fb96156 in login_binary_run (binary=, 
argc=1, argv=0x7f75918e4890) at main.c:549
#11 0x7f758f4a2d1d in __libc_start_main () from /lib64/libc.so.6
#12 0x7f758ffc4469 in _start ()
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
client_notify_auth_ready 

Re: Can Dovecot reject unencrypted mail?

[Jochen Bern]

On 01/10/2018 01:08 PM, David Seaward wrote:
> Is it possible to configure Dovecot to reject mail that is not
> encrypted. In other words:
> 1. If the user tries to send an unencrypted message from their MUA,
> the server rejects it.
> 2. If a third-party tries to send an unencrypted message to the user,
> the server rejects it.

a) In a typical setup, neither of these two services uses dovecot.
b) In order to be able to exchange encrypted e-mails, the two parties
   need to exchange their public keys / certs beforehand. Which is
   usually done by - signed, but not encrypted, on purpose - e-mail.
c) Any other mail server the user has an account on can be used to
   circumvent your securing scenario 1, at least for a large number
   of recipients.
d) You're breaking pretty much every sort of autoreplies on this planet
   for your users.
e) Checking an e-mail for *every* sort of encapsulation that encryption
   may use is not quite trivial. Making sure that *the recipient* can
   actually decrypt it is impossible, as you assume that the system
   does *not* hold the recipient's private key. Nailing it down so that
   *only* the recipient can decrypt it (when the sysadmin might fool
   the sender into encrypting it for one of *his* pubkeys as well)
   should be quite a while of fun, too.

What I *have* done, in postfix, is to take every (single-recipient)
delivery to our own domain, look up a map that tells me whether the
server has a PGP/GnuPG, S/MIME, or neither type of pubkey/cert on
record, encrypt the incoming mail in the first two cases, and log a
warning (and allow the mail to pass unchanged) in the latter. Mind, that
was on peripheral mail servers where I could *assume* the mails not to
already be encrypted, not the actual MX. Also, keeping the map and
pubkeys updated didn't come for free, either, even though I'm the one
handing our staff their S/MIME certs in the first place.

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Doveadm field for message body without attachments

[Aki Tuomi]

> On January 10, 2018 at 11:49 AM Athanasios Viennas  wrote:
> 
> 
> 
> Happy new year to all,
> 
> what is the message field in doveadm data model representing the body 
> without attachments? I need to dump the message body without the 
> attachments so as to avoid unnecessary size of the exported files and 
> while I am also not interested in this part of the message.
> 
> with kind regards
> Athanasios
>

You could try doveadm fetch -u victim body.0 (or body.1)

another alternative is to parse bodystructure to figure out which body part is 
the one you want and do doveadm fetch -u victim body.partno

sub-parts are numbered as body.part.subpart

Aki

Re: Can Dovecot reject unencrypted mail?

[Aki Tuomi]

> On January 10, 2018 at 2:08 PM David Seaward  wrote:
> 
> 
> Hi,
> 
> Is it possible to configure Dovecot to reject mail that is not
> encrypted. In other words:
> 
> 1. If the user tries to send an unencrypted message from their MUA,
> the server rejects it.
> 
> 2. If a third-party tries to send an unencrypted message to the user,
> the server rejects it.
> 
> The end result would be that no mail stored on the server can be
> decrypted by the administrator.
> 
> I am aware that:
> 
> * "Encrypted" could mean a lot of things. I'm imagining GPG
> encryption, but am open to other supported methods.
> 
> * This configuration would not suit everyone, e.g. someone posting to
> a public mailing list :)
> 
> Regards,
> David

You can make a global Sieve script that will e.g. pipe your email to some 
verification script. Or you can use some header based checks. This is probably 
not very simple thing to do.

Aki

Re: openssl question

[Aki Tuomi]

> On January 8, 2018 at 10:19 PM Selcuk Yazar  wrote:
> 
> 
> Hi
> 
> we are using dovecot on secure port
> 
> when i try to command
> 
> openssl s_client -connect mail.mydomain:pop3s
> 
> 
> 
> it works perfect.
> 
> [image: Inline image 1]
> 
> 
> Also   i check from
> 
> https://www.sslshopper.com/ssl-checker.html web page i can see all correct
> ceritificate paths
> 
> but i try to this command
> 
> openssl s_client -connect mail.mydomain:pop3s -starttls imap

You are connecting to pop3 ssl port and attempt STARTTLS. Try

openssl s_client -connect mail.mydomain:imap -starttls imap

> 
> it says CONNECTED and hang. second command is correct?
> 
> also my thunderbird client doesnt work with 143 port and STARTTLS. is this
> general issue or have we config error?
> 
> thanks in advance
> 
> Selçuk YAZAR

Check logs for possible errors.

Aki

openssl question

[Selcuk Yazar]

Hi

we are using dovecot on secure port

when i try to command

openssl s_client -connect mail.mydomain:pop3s



it works perfect.

[image: Inline image 1]


Also   i check from

https://www.sslshopper.com/ssl-checker.html web page i can see all correct
ceritificate paths

but i try to this command

openssl s_client -connect mail.mydomain:pop3s -starttls imap

it says CONNECTED and hang. second command is correct?

also my thunderbird client doesnt work with 143 port and STARTTLS. is this
general issue or have we config error?

thanks in advance

Selçuk YAZAR

Can Dovecot reject unencrypted mail?

[David Seaward]

Hi,

Is it possible to configure Dovecot to reject mail that is not
encrypted. In other words:

1. If the user tries to send an unencrypted message from their MUA,
the server rejects it.

2. If a third-party tries to send an unencrypted message to the user,
the server rejects it.

The end result would be that no mail stored on the server can be
decrypted by the administrator.

I am aware that:

* "Encrypted" could mean a lot of things. I'm imagining GPG
encryption, but am open to other supported methods.

* This configuration would not suit everyone, e.g. someone posting to
a public mailing list :)

Regards,
David

Doveadm field for message body without attachments

[Athanasios Viennas]

Happy new year to all,

what is the message field in doveadm data model representing the body 
without attachments? I need to dump the message body without the 
attachments so as to avoid unnecessary size of the exported files and 
while I am also not interested in this part of the message.


with kind regards
Athanasios