Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Bill Shirley

Also, I wouldn't use the second rule:
    if header :contains "subject" ["SPAM?"] {
      fileinto "Junk";
      stop;
    }

If someone sends you an email with the subject "Can you help me with this spam?"
it will get filed into Junk.

Bill



Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Bill Shirley

This is what I use.  Notice the comma:
require "fileinto";
if header :contains "X-Spam-Status" "Yes," {
  fileinto "SystemFolders.SuspectedSpam";
  stop;
}

Bill

On 12/14/2017 1:02 PM, Richard wrote:



Date: Thursday, December 14, 2017 09:47:44 -0800
From: Gao 

I use a sieve filter to move spam email to user's Junk folder:
# cat spam_to_junk.sieve
require "fileinto";
    if exists "X-Spam-Status" {
    if header :contains "X-Spam-Status" "YES" {
    fileinto "Junk";
    stop;
    } else {
    }
    }
    if header :contains "subject" ["SPAM?"] {
      fileinto "Junk";
      stop;
    }

Most time this filter works fine but occasionally it move non-spam
in to Junk folder. Here is an example, this email is from dovecot
mailling list and it end up in my Junk folder. Mailllog and header
here. Would someone help me to figure out what went wrong here?

Thanks.

Gao


   > X-Spam-Status: No, score=-2.9 required=5.0
  tests=ALL_TRUSTED,BAYES_00


Because of the way you are bounding it, I suspect that the "YES" in
BAYES_00, at the end of that line, is triggering the mis-filing.

Why not make:

contains "X-Spam-Status" "YES"

a single string:

contains "X-Spam-Status: YES"

that would be more precise and avoid this issue.






Re: Mail-crypt plugin clarification

2017-12-14 Thread Joseph Tam

Aki Tuomi writes:


Dovecot does support making it difficult to prevent access to the stored
mail.


Those who have had problems understanding the documentation might find
this unintended double-negative ironically funny.


You can, with suitable workflows, ensure that the user's emails are not
readable by anyone but the user.  Of course the only way to be fully
sure is to use end-to-end encryption, ...


"Ensure" (or OP: "impossible") are very high standards of privacy.
If the OP really means it, then since a third party has control over
the (virtual or real) hardware, the server should never have access to
private keys or decrypted data.  (We're in agreement I think.)

If the OP lowers their standards to "inconvenient" to gain access,
then the plugin is enough.  It will keep the honest admin honest.


... like PGP or S/MIME, but this does go a long way to prevent admin access
to user's email.


Don't ignore metadata; who/when/where (and headers?) could reveal much
information.

Joseph Tam 


Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Larry Rosenman
This is what I use with Exim, spam.sieve is included in from a master.sieve:

thebighonker.lerctr.org /home/ler $ more sieve/spam.sieve
require ["fileinto","imap4flags"];
if header :contains ["X-LERCTR-Spam-Flag","X-TNTSCAN-Spam-Flag"]  "YES"
{
   redirect "spamt...@spambouncer.org";
   fileinto :flags "\\Seen Junk" "SPAM";
   stop;
}

thebighonker.lerctr.org /home/ler $ grep -B10 -A10 -- -Spam-Flag 
/usr/local/etc/exim/configure
spam = smmsp:true
  warn  message = X-LERCTR-Spam-Score: $spam_score ($spam_bar)
! authenticated = *
spam = smmsp:true
  warn  message = X-Spam-Report: $spam_report
! authenticated = *
spam = smmsp:true
  warn  message = X-LERCTR-Spam-Report: $spam_report
! authenticated = *
spam = smmsp:true
  # Add X-Spam-Flag if spam is over system-wide threshold
  warn message = X-Spam-Flag: YES
! authenticated = *
spam = smmsp:true
condition = ${if >={$spam_score_int}{50}{1}{0}}
  warn message = X-LERCTR-Spam-Flag: YES
! authenticated = *
spam = smmsp:true
condition = ${if >={$spam_score_int}{50}{1}{0}}

  #warn  message = DomainKey-Status: $dkim_status
#   !condition = ${if eq{$dkim_status}{}{1}{0}}
  # Reject spam messages with score over 7, using an extra condition.
  deny  message = This message scored $spam_score points. Congratulations!
! authenticated = *
spam = smmsp:true
thebighonker.lerctr.org /home/ler $

On 12/14/17, 1:04 PM, "dovecot on behalf of Gao"  wrote:

Well I changed the line to
   if header :contains "X-Spam-Status: YES" {

Then I got:
# sievec spam_to_junk.sieve
spam_to_junk: line 3: error: the header test requires 2 positional 
argument(s), but 1 is/are specified.
spam_to_junk: error: validation failed.
sievec(root): Fatal: failed to compile sieve script 'spam_to_junk.sieve'


Should it be:
   if header :contains "X-Spam-Status" "X-Spam-Status: YES" {

???
I need to learn some sieve grammar.

Gao

On 2017-12-14 10:02 AM, Richard wrote:
>
>> Date: Thursday, December 14, 2017 09:47:44 -0800
>> From: Gao 
>>
>> I use a sieve filter to move spam email to user's Junk folder:
>> # cat spam_to_junk.sieve
>> require "fileinto";
>> if exists "X-Spam-Status" {
>> if header :contains "X-Spam-Status" "YES" {
>> fileinto "Junk";
>> stop;
>> } else {
>> }
>> }
>> if header :contains "subject" ["SPAM?"] {
>>   fileinto "Junk";
>>   stop;
>> }
>>
>> Most time this filter works fine but occasionally it move non-spam
>> in to Junk folder. Here is an example, this email is from dovecot
>> mailling list and it end up in my Junk folder. Mailllog and header
>> here. Would someone help me to figure out what went wrong here?
>>
>> Thanks.
>>
>> Gao
>>
>> X-Spam-Status: No, score=-2.9 required=5.0
>   tests=ALL_TRUSTED,BAYES_00
>
>
> Because of the way you are bounding it, I suspect that the "YES" in
> BAYES_00, at the end of that line, is triggering the mis-filing.
>
> Why not make:
>
> contains "X-Spam-Status" "YES"
>
> a single string:
>
> contains "X-Spam-Status: YES"
>
> that would be more precise and avoid this issue.
>
>






Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Gao

Well I changed the line to
  if header :contains "X-Spam-Status: YES" {

Then I got:
# sievec spam_to_junk.sieve
spam_to_junk: line 3: error: the header test requires 2 positional 
argument(s), but 1 is/are specified.

spam_to_junk: error: validation failed.
sievec(root): Fatal: failed to compile sieve script 'spam_to_junk.sieve'


Should it be:
  if header :contains "X-Spam-Status" "X-Spam-Status: YES" {

???
I need to learn some sieve grammar.

Gao

On 2017-12-14 10:02 AM, Richard wrote:



Date: Thursday, December 14, 2017 09:47:44 -0800
From: Gao 

I use a sieve filter to move spam email to user's Junk folder:
# cat spam_to_junk.sieve
require "fileinto";
    if exists "X-Spam-Status" {
    if header :contains "X-Spam-Status" "YES" {
    fileinto "Junk";
    stop;
    } else {
    }
    }
    if header :contains "subject" ["SPAM?"] {
      fileinto "Junk";
      stop;
    }

Most time this filter works fine but occasionally it move non-spam
in to Junk folder. Here is an example, this email is from dovecot
mailling list and it end up in my Junk folder. Mailllog and header
here. Would someone help me to figure out what went wrong here?

Thanks.

Gao


   > X-Spam-Status: No, score=-2.9 required=5.0
  tests=ALL_TRUSTED,BAYES_00


Because of the way you are bounding it, I suspect that the "YES" in
BAYES_00, at the end of that line, is triggering the mis-filing.

Why not make:

contains "X-Spam-Status" "YES"

a single string:

contains "X-Spam-Status: YES"

that would be more precise and avoid this issue.






Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Gao

thank you for the advice. I'll change it.

Gao

On 2017-12-14 10:02 AM, Richard wrote:



Date: Thursday, December 14, 2017 09:47:44 -0800
From: Gao 

I use a sieve filter to move spam email to user's Junk folder:
# cat spam_to_junk.sieve
require "fileinto";
    if exists "X-Spam-Status" {
    if header :contains "X-Spam-Status" "YES" {
    fileinto "Junk";
    stop;
    } else {
    }
    }
    if header :contains "subject" ["SPAM?"] {
      fileinto "Junk";
      stop;
    }

Most time this filter works fine but occasionally it move non-spam
in to Junk folder. Here is an example, this email is from dovecot
mailling list and it end up in my Junk folder. Mailllog and header
here. Would someone help me to figure out what went wrong here?

Thanks.

Gao


   > X-Spam-Status: No, score=-2.9 required=5.0
  tests=ALL_TRUSTED,BAYES_00


Because of the way you are bounding it, I suspect that the "YES" in
BAYES_00, at the end of that line, is triggering the mis-filing.

Why not make:

contains "X-Spam-Status" "YES"

a single string:

contains "X-Spam-Status: YES"

that would be more precise and avoid this issue.






Re: sieve filter move wrong email to Junk folder

2017-12-14 Thread Richard


> Date: Thursday, December 14, 2017 09:47:44 -0800
> From: Gao 
>
> I use a sieve filter to move spam email to user's Junk folder:
># cat spam_to_junk.sieve
> require "fileinto";
>    if exists "X-Spam-Status" {
>    if header :contains "X-Spam-Status" "YES" {
>    fileinto "Junk";
>    stop;
>    } else {
>    }
>    }
>    if header :contains "subject" ["SPAM?"] {
>      fileinto "Junk";
>      stop;
>    }
> 
> Most time this filter works fine but occasionally it move non-spam
> in to Junk folder. Here is an example, this email is from dovecot
> mailling list and it end up in my Junk folder. Mailllog and header
> here. Would someone help me to figure out what went wrong here?
> 
> Thanks.
> 
> Gao
> 

  > X-Spam-Status: No, score=-2.9 required=5.0 
 tests=ALL_TRUSTED,BAYES_00


Because of the way you are bounding it, I suspect that the "YES" in
BAYES_00, at the end of that line, is triggering the mis-filing. 

Why not make:

   contains "X-Spam-Status" "YES"

a single string:

   contains "X-Spam-Status: YES"

that would be more precise and avoid this issue.




sieve filter move wrong email to Junk folder

2017-12-14 Thread Gao

I use a sieve filter to move spam email to user's Junk folder:
# cat spam_to_junk.sieve
require "fileinto";
  if exists "X-Spam-Status" {
  if header :contains "X-Spam-Status" "YES" {
  fileinto "Junk";
  stop;
  } else {
  }
  }
  if header :contains "subject" ["SPAM?"] {
    fileinto "Junk";
    stop;
  }

Most time this filter works fine but occasionally it move non-spam in to 
Junk folder. Here is an example, this email is from dovecot mailling 
list and it end up in my Junk folder. Mailllog and header here. Would 
someone help me to figure out what went wrong here?


Thanks.

Gao



===Header=
Dovecot Mailing List 
References: 
 
From: sender name 
Message-ID: <9100b497-7f3e-8129-9f8f-c675296e2...@rename-it.nl>
Date: Thu, 14 Dec 2017 11:54:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-SA-Exim-Connect-IP: 217.119.239.130
X-SA-Exim-Mail-From: sen...@rename-it.nl
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sogo.guto.nl
X-Spam-Level:
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
 autolearn=ham version=3.3.2, No
Subject: Re: New Dovecot service: SMTP Submission (RFC6409)
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +)
X-SA-Exim-Scanned: Yes (on sogo.guto.nl)
X-BeenThere: dovecot@dovecot.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Dovecot Mailing List 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: dovecot-boun...@dovecot.org
Sender: "dovecot" 
X-mydomain-MailScanner-Information: Please contact the administrator for 
more information

X-mydomain-MailScanner-ID: D6773400AB09.ADBA7
X-mydomain-MailScanner: Found to be clean
X-mydomain-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
    score=-4.598, required 5, autolearn=not spam, BAYES_00 -1.90,
    DCC_CHECK 1.10, HEADER_FROM_DIFFERENT_DOMAINS 0.00,
    KAM_LAZY_DOMAIN_SECURITY 1.00, KAM_SHORT 0.00,
    RCVD_IN_DNSWL_MED -2.30, RCVD_IN_HOSTKARMA_W -2.50)
X-mydomain-MailScanner-From: dovecot-boun...@dovecot.org

=End of header===



===Maillog=
Dec 14 02:54:51 mail postfix/postscreen[19236]: CONNECT from 
[94.237.32.243]:40818 to [10.11.22.68]:25
Dec 14 02:54:52 mail postfix/postscreen[19236]: PASS OLD 
[94.237.32.243]:40818
Dec 14 02:54:52 mail postfix/smtpd[19244]: connect from 
wursti.dovecot.fi[94.237.32.243]
Dec 14 02:54:52 mail policyd-spf[19248]: None; identity=helo; 
client-ip=94.237.32.243; helo=mail.dovecot.fi; 
envelope-from=dovecot-boun...@dovecot.org; receiver=g...@pztop.com
Dec 14 02:54:52 mail policyd-spf[19248]: None; identity=mailfrom; 
client-ip=94.237.32.243; helo=mail.dovecot.fi; 
envelope-from=dovecot-boun...@dovecot.org; receiver=g...@pztop.com
Dec 14 02:54:52 mail postfix/smtpd[19244]: D6773400AB09: 
client=wursti.dovecot.fi[94.237.32.243]
Dec 14 02:54:53 mail postfix/cleanup[19249]: D6773400AB09: hold: header 
Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243])??by 
mail.mydomain.com (Postfix) with ESMTP id D6773400AB09??for 
; Thu, 14 Dec 2017 02:54:52 -0800 (PST) from 
wursti.dovecot.fi[94.237.32.243]; from= 
to= proto=ESMTP helo=
Dec 14 02:54:53 mail postfix/cleanup[19249]: D6773400AB09: 
message-id=<9100b497-7f3e-8129-9f8f-c675296e2...@rename-it.nl>
Dec 14 02:54:53 mail opendkim[1706]: D6773400AB09: wursti.dovecot.fi 
[94.237.32.243] not internal

Dec 14 02:54:53 mail opendkim[1706]: D6773400AB09: not authenticated
Dec 14 02:54:53 mail opendkim[1706]: D6773400AB09: no signature data
Dec 14 02:54:53 mail postfix/smtpd[19244]: disconnect from 
wursti.dovecot.fi[94.237.32.243] ehlo=1 mail=1 rcpt=1 data=1 quit=1 
commands=5
Dec 14 02:54:53 mail MailScanner[18700]: New Batch: Scanning 1 messages, 
7572 bytes
Dec 14 02:54:53 mail MailScanner[18700]: Virus and Content Scanning: 
Starting

Dec 14 02:54:53 mail MailScanner[18700]: Spam Checks: Starting
Dec 14 02:54:53 mail MailScanner[18700]: MailWatch: Blacklist refresh 
time reached
Dec 14 02:54:53 mail MailScanner[18700]: MailWatch: Starting up 
MailWatch SQL Blacklist

Dec 14 02:54:53 mail MailScanner[18700]: MailWatch: Read 0 blacklist entries
Dec 14 02:54:56 mail MailScanner[18700]: Requeue: 

Re: New Dovecot service: SMTP Submission (RFC6409)

2017-12-14 Thread Tanstaafl
One other point.

Adding support for something like this that also requires Clients to add
support for it is just begging for a feature that never gets used.

Stephan, are you sure there is no (fairly simple) way to make this an
SMTP service that any email client that supports SMTP can use?


On 12/14/2017, 10:57:44 AM, Tanstaafl  wrote:
> On 12/14/2017, 3:03:41 AM, Aki Tuomi  wrote:
>> On 13.12.2017 21:41, Tanstaafl wrote:
>>> On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
>>> I thought this was simply going to be an SMTP like service that any SMTP
>>> client could utilize, keeping the BURL/URLAUTH pieces working only
>>> between Dovecot and the MTA it works with. Meaning, instead of
>>> connecting an SMTP service provided by Postfix, you connect to one
>>> provided by Dovecot. I guess there is a good reason it couldn't be made
>>> to work this way.
>>>
>>> For obvious reasons, the likelihood that Thunderbird will add
>>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
> 
>> Actually it's supposed to serve as SMTP-like service as well.
> 
> Meaning... it actually won't require Thunderbird to implement anything
> (at least painful) to allow it to make use of it?
> 
> 
> 
> Thanks Aki,
> 
> Charles
> 



Re: New Dovecot service: SMTP Submission (RFC6409)

2017-12-14 Thread Tanstaafl
On 12/14/2017, 3:03:41 AM, Aki Tuomi  wrote:
> On 13.12.2017 21:41, Tanstaafl wrote:
>> On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
>> I thought this was simply going to be an SMTP like service that any SMTP
>> client could utilize, keeping the BURL/URLAUTH pieces working only
>> between Dovecot and the MTA it works with. Meaning, instead of
>> connecting an SMTP service provided by Postfix, you connect to one
>> provided by Dovecot. I guess there is a good reason it couldn't be made
>> to work this way.
>>
>> For obvious reasons, the likelihood that Thunderbird will add
>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.

> Actually it's supposed to serve as SMTP-like service as well.

Meaning... it actually won't require Thunderbird to implement anything
(at least painful) to allow it to make use of it?



Thanks Aki,

Charles


Re: doveadm log reopen not works with 2.2.33

2017-12-14 Thread Gedalya
On 12/14/2017 03:18 PM, Alessio Cecchi wrote:
> Is this a know bug? 


https://www.dovecot.org/pipermail/dovecot/2017-November/109971.html




doveadm log reopen not works with 2.2.33

2017-12-14 Thread Alessio Cecchi

Hi,

after the upgrade from dovecot 2.2.32 to 2.2.33 we notice that the 
/var/log/director/director.log was empty and the log are write in the 
logrotate file es. /var/log/director/director.log-20171201.


Log path is dovecot is:

log_path = /var/log/director/director.log

Logrotate configuration is:

/var/log/director/director.log {
  daily
  rotate 31
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    doveadm -i director log reopen
  endscript
}

and worked fine until the last dovecot upgrade. Now the only way to 
"reopen" the log file is doveadm reload.


Is this a know bug?

Thanks

--
Alessio Cecchi
Postmaster @ http://www.qboxmail.it
https://www.linkedin.com/in/alessice



Panic: file imap-client.c: line 1204 (client_handle_input): assertion failed: (o_stream_is_corked(client->output))

2017-12-14 Thread Ralf Hildebrandt
Running Dovecot from the daily builds: 2:2.3.0~alpha0-1~auto+1287 in
an proxy setup:

auth_mechanisms = plain login
default_vsz_limit = 1 G
imapc_host = .charite.de
imapc_port = 993
imapc_ssl = imaps
imapc_ssl_verify = no
listen = *,::
mail_gid = imapproxy
mail_home = /home/imapproxy/%u
mail_location = imapc:~/imapc
mail_plugins = mail_log notify
mail_uid = imapproxy
passdb {
  args = host=.charite.de port=993 ssl=imaps 
ssl_ca_file=/etc/ssl/certs/ca-certificates.crt
  default_fields = userdb_imapc_user=%u userdb_imapc_password=%w 
userdb_imapc_host=.charite.de userdb_imapc_ssl=imaps 
userdb_imapc_port=993
  driver = imap
}
postmaster_address = postmas...@charite.de
protocols = imap
service auth {
  inet_listener {
address = 127.0.0.1
port = 12345
  }
}
ssl = required
ssl_ca = : Panic: 
file imap-client.c: line 1204 (client_handle_input): assertion failed: 
(o_stream_is_corked(client->output))
Dec 14 14:35:28 mproxy dovecot: imap(voea)<79305>: Panic: 
file imap-client.c: line 1204 (client_handle_input): assertion failed: 
(o_stream_is_corked(client->output))
Dec 14 14:35:28 mproxy dovecot: imap(voea)<79275>: Error: 
Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xc3cd5) 
[0x7fe40d9cccd5] -> /usr/lib/dovecot/libdovecot.so.0(+0xc3dbc) 
[0x7fe40d9ccdbc] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) 
[0x7fe40d942f8e] -> dovecot/imap [voea 
193.175.2.18](client_handle_input+0x2a8)
[0x564f326e0e18] -> dovecot/imap [voea 
193.175.2.18](client_continue_pending_input+0x80)
[0x564f326e0f20] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69)
[0x7fe40d9e48f9] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x10a)
[0x7fe40d9e612a] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x52)
[0x7fe40d9e4a02] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38)
[0x7fe40d9e4c18] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13)
[0x7fe40d965b63] -> dovecot/imap [voea 193.175.2.18](main+0x333)
[0x564f326d3113] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
[0x7fe40d5623f1] -> dovecot/imap [voea 193.175.2.18](+0xe2f1)
[0x564f326d32f1]
Dec 14 14:35:28 mproxy dovecot: imap(voea)<79305>: Error: 
Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xc3cd5) 
[0x7faa962d8cd5] -> /usr/lib/dovecot/libdovecot.so.0(+0xc3dbc) 
[0x7faa962d8dbc] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7faa9624ef8e] -> dovecot/imap [voea 
193.175.2.18](client_handle_input+0x2a8)
[0x5615124cde18] -> dovecot/imap [voea 
193.175.2.18](client_continue_pending_input+0x80)
[0x5615124cdf20] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69)
[0x7faa962f08f9] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x10a)
[0x7faa962f212a] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x52)
[0x7faa962f0a02] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38)
[0x7faa962f0c18] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13)
[0x7faa96271b63] -> dovecot/imap [voea 193.175.2.18](main+0x333)
[0x5615124c0113] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
[0x7faa95e6e3f1] -> dovecot/imap [voea 193.175.2.18](+0xe2f1)
[0x5615124c02f1]

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: dovecot (+sendmail) fails to get email into thunderbird

2017-12-14 Thread jo land
> # %u is replaced with the username that logs in
> mail_location = mbox:~/mail:INBOX=/var/mail/%u
>

if i change the mail location into: mbox:~/mail:INBOX=/var/mail/%u

mail.log says:

Dec 14 14:24:26 pie dovecot: imap(update.site1): Error: user update.site1:
Initialization failed: Namespace '': mbox: mbox root directory can't be a
file: /var/spool/mail/mail


dovecot crashing

2017-12-14 Thread cheese
i have a system with panics/crashes and seem to be able to trigger the 
problem.


dovecot version: 2.2.33.2 (from ius rpm-package-repository)
maillog:

Dec 14 10:55:00 vimap01 dovecot: imap(XXX): Panic: file index-mail-binary.c: 
line 358 (blocks_count_lines): assertion failed: (block_count == 0 || 
block_idx+1 == block_count)
Dec 14 10:55:00 vimap01 dovecot: imap(XXX): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0x9f3de) 
[0x7fa6768ef3de] -> /usr/lib64/dovecot/libdovecot.so.0(+0x9f4be) [0x7fa6768ef4be] -> 
/usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa67688077c] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0xb50f7) 
[0x7fa676c370f7] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_mail_get_binary_stream+0x3c9) [0x7fa676c37569] 
-> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_get_binary_size+0x5b) [0x7fa676bbfa2b] -> 
/usr/lib64/dovecot/libdovecot-storage.so.0(imap_msgpart_size+0x80) [0x7fa676c7a340] -> dovecot/imap(+0x207a9) 
[0x55b9589327a9] -> dovecot/imap(+0x1e63a) [0x55b95893063a] -> dovecot/imap(imap_fetch_more+0x35) [0x55b958931b45] 
-> dovecot/imap(cmd_fetch+0x34d) [0x55b95892336d] -> dovecot/imap(command_exec+0x5c) [0x55b95892ef0c] -> 
dovecot/imap(+0x1b48f) [0x55b95892d48f] -> dovecot/imap(+0x1b521) [0x55b95892d521] -> 
dovecot/imap(client_handle_input+0x195) [0x55b9589
2d8e5] -> dovecot/imap(client_input+0x85) [0x55b95892de05] -> 
/usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x52) [0x7fa676904cd2] -> 
/usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x10f) [0x7fa6769063bf] -> 
/usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x3c) [0x7fa676904d6c] -> 
/usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7fa676904f28] -> 
/usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7fa67688afa3] -> 
dovecot/imap(main+0x333) [0x55b9589202e3] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fa6764aec05] 
-> dovecot/imap(+0xe476) [0x55b958920476]
Dec 14 10:55:00 vimap01 dovecot: imap(XXX): Fatal: master: service(imap): child 
5766 killed with signal 6 (core dumped)

gdb backtrace is attached as file

more infos/core-dump-file available if needed.

yours
josef

#0  0x7fa6764c21f7 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 5766
selftid = 5766
#1  0x7fa6764c38e8 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, 
sa_mask = {__val = {1024, 140352925920261, 94254543275126, 0, 140352930371331, 
140729204080784, 94254563559328, 513, 13884021430134021376, 140352934095424, 
140352930552771, 94254563559328, 140729204080880, 3328, 140352930553113, 
94254563559328}}, 
  sa_flags = 1989059466, sa_restorer = 0x7ffe12380101}
sigs = {__val = {32, 0 }}
#2  0x7fa6768ef3d6 in default_fatal_finish (type=, 
status=status@entry=0) at failures.c:201
backtrace = 0x55b959c787d8 
"/usr/lib64/dovecot/libdovecot.so.0(+0x9f3de) [0x7fa6768ef3de] -> 
/usr/lib64/dovecot/libdovecot.so.0(+0x9f4be) [0x7fa6768ef4be] -> 
/usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa67688077c] -> /usr"...
#3  0x7fa6768ef4be in i_internal_fatal_handler (ctx=0x7ffe12380140, 
format=, args=) at failures.c:670
status = 0
#4  0x7fa67688077c in i_panic (format=format@entry=0x7fa676c7aa40 "file %s: 
line %d (%s): assertion failed: (%s)") at failures.c:275
ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, 
timestamp_usecs = 0}
args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
0x7ffe12380240, reg_save_area = 0x7ffe12380180}}
#5  0x7fa676c370f7 in blocks_count_lines (full_input=0x55b959cd6510, 
ctx=0x7ffe123802c0) at index-mail-binary.c:358
block_idx = 0
p = 
size = 0
cur_block_offset = 
data = 0x0
ret = 
cur_block = 0x55b959c785e0
block_count = 2
skip = 
#6  index_mail_read_binary_to_cache (_mail=_mail@entry=0x55b959cc2858, 
part=0x55b959cced78, include_hdr=include_hdr@entry=true, 
reason=reason@entry=0x7fa676c8cef6 "binary.size", 
binary_r=binary_r@entry=0x7ffe1238038e, 
converted_r=converted_r@entry=0x7ffe1238038f) at index-mail-binary.c:396
mail = 0x55b959cc2858
cache = 0x55b959c9e138
ctx = {mail = 0x55b959cc2858, input = 0x55b959cc32a0, has_nuls = false, 
converted = true, blocks = {arr = {buffer = 0x55b959c785a8, element_size = 24}, 
v = 0x55b959c785a8, v_modifiable = 0x55b959c785a8}, copy_start_offset = 3424}
is = 0x55b959cd6510
__FUNCTION__ = "index_mail_read_binary_to_cache"
#7  0x7fa676c37569 in index_mail_get_binary_size (lines_r=, 
size_r=0x7ffe12380490, include_hdr=false, part=0x55b959cced78, 
_mail=0x55b959cc2858) at index-mail-binary.c:499
root_bin_part = 
size = 
mail = 0x55b959cc2858
msg_part = 
bin_part = 
all_parts = 0x55b959cced78
end_offset = 

Re: New Dovecot service: SMTP Submission (RFC6409)

2017-12-14 Thread Stephan Bosch



Op 14-12-2017 om 8:26 schreef María Arrea:


    Stephan, thank you very much for your hard work. I want to ask 
your opinion about jmap ( http://jmap.io/ ) , do you think is a viable 
alternative to current IMAP + MSA ?




Difficult to tell at this point, as It is not finished yet. It all 
depends on whether people will want to implement it. Still, 
technology-wise I think it is solid and, as far as I know now, we'll be 
implementing it at some point.


Regards,

Stephan.


Regards

    María

El 12/12/17 a las 00:14, Stephan Bosch escribió:

Hi,

As some of you know, I started implementing the SMTP submission proxy a
few years ago. It acts as a front-end for any MTA, adding the necessary
functionality for an SMTP submission service, also known as a Mail
Submission Agent (MSA) (https://tools.ietf.org/html/rfc6409). The main
reason I created this, back then, was implementing the BURL capability
(https://tools.ietf.org/html/rfc4468). The main application of that
capability -- together with IMAP URLAUTH -- is avoiding a duplicate
upload of submitted e-mail messages; normally the message is both sent
through SMTP and uploaded to the "Sent" folder through IMAP. Using BURL,
the client can first upload the message to IMAP and then use BURL to
make the SMTP server fetch the message from IMAP for submission, thereby
avoiding a second upload. Apart from BURL, the submission proxy service
also adds the required AUTH support, avoiding the need to configure the
MTA for SASL authentication. More SMTP capabilities like CHUNKING and
SIZE are supported, without requiring the backend MTA supporting these
extensions. Other capabilities like DSN currently require support from
the backend/relay MTA.

At this point, the submission proxy is still pretty basic. However, it
will provide a basis for adding all kinds of functionality in the (not
so distant) future. For the first time, it will be possible to act upon
message submission, rather than only message retrieval; e.g. plugins can
be devised that process outgoing messages somehow. Examples of the
things we could do are adding Sieve filtering support for outgoing
messages, or implicitly storing submitted messages to the Sent folder.
Once a plugin API is devised, you can create your own plugins.

The reason I send this message now, is that this code is finally merged
into the Dovecot master repository. This means that it is part of the
upcoming 2.3 release. Now that it is merged, you can install and test it
from Github if you like. Feedback is of course appreciated. The
documentation is still pretty sparse, but there is currently not much to
configure. Just add "submission" to the protocols and configure the
relay MTA server. The configuration is currently only documented in the
example configuration in doc/example-config/conf.d/20-submission.conf.
The submission service is a login service, just like IMAP, POP3 and
ManageSieve, so clients are required to authenticate. The same
authentication configuration will also apply to submission, unless
you're doing protocol-specific things, in which case you may need to
amend your configuration for the new protocol. BURL support requires a
working IMAP URLAUTH implementation.

I've updated the automated Xi Debian package builder to create an
additional dovecot-submissiond package. So, if you're using the Xi
packages, you only need to install that package and configure the 
relay MTA.


Regards,

Stephan.











Re: auth_policy in a non-authenticating proxy chain

2017-12-14 Thread Peter Mogensen


On 2017-12-14 10:31, Sami Ketola wrote:
> 
>> On 14 Dec 2017, at 8.30, Peter Mogensen  wrote:
>> However... since the proxy use "nopassword", ALL passdb lookups result
>> in "success", so the proxy will never report an authentication failure
>> to the authpolicy server.
> 
> 
> Why not authenticate the sessions at the proxy level already? Is there any
> reason not to do that?

Yes. Several.
This is not a new setup. It's an already well established setup and it's
unlikely that authentication can be moved to the proxy.

/Peter



Re: auth_policy in a non-authenticating proxy chain

2017-12-14 Thread Sami Ketola

> On 14 Dec 2017, at 8.30, Peter Mogensen  wrote:
> However... since the proxy use "nopassword", ALL passdb lookups result
> in "success", so the proxy will never report an authentication failure
> to the authpolicy server.


Why not authenticate the sessions at the proxy level already? Is there any
reason not to do that?

Sami



Re: Recommended tool for migrating IMAP servers

2017-12-14 Thread Sami Ketola

> On 13 Dec 2017, at 18.27, Davide Marchi  wrote:
> 
> Sami Ketola wrote:> We run all our migrations using Dovecot internal dsync. 
> Usually using imapc connector to connect to legacy
>> platform.
>> Wqmi
> 
> Many thanks Wqmi!
> Well, I've read the dsync documentation, but this warning has me a little 
> worried:
> 
> "Make sure destination is exactly as source, deleting/reverting any changes 
> in destination if necessary"

This is when you use the 'backup' option. Dsync then makes 1:1 copy of the 
source. If you use 'sync -1' option, 
it does not delete mails/folders from destination.

> So I followed the Imapsync way, and all works fine.

Sure if you are fine with the imapsync limitations.

Sami

Re: Mail-crypt plugin clarification

2017-12-14 Thread Aki Tuomi


On 14.12.2017 01:07, Joseph Tam wrote:
> rje writes:
>
>> I'm looking into ways to encrypt the stored email on my server. The
>> idea is
>> to make it impossible for my hosting provider (who has access to my
>> VPS) to
>> read the mail from the disk.
>
> Just to be clear, if at any point your VPS has access to the plaintext
> mail (or keys that decrypt mail), then the VPS provider could access
> your decrypted mail.
>
> To make it unfeasible for your VPS to read your mail, it has to arrive
> at your VPS pre-encrypted.  I can envision a system where you import
> encrypted mail into your mail store, then use client IMAP access to
> be decrypted locally by your mail reader.  However, metadata is still
> accessible by your VPS provider.
>
> If your VPS is the MTA that directly handles SMTP from your correspondees
> sending you unencrypted messages, you can't lock out a sufficiently
> skilled platform admin.
>
> Joseph Tam 

Hi!

Dovecot does support making it difficult to prevent access to the stored
mail. You can, with suitable workflows, ensure that the user's emails
are not readable by anyone but the user. This can be done by encrypting
the user's private key using user's password (or it's derivate, such as
sha256 sum of it).

Of course the only way to be fully sure is to use end-to-end encryption,
like PGP or S/MIME, but this does go a long way to prevent admin access
to user's email.

Downside of course is that if the user ever forgets his password, then
those emails are lost as well. We have plans to add DR support for this,
but it's still WIP.

Aki


Re: New Dovecot service: SMTP Submission (RFC6409)

2017-12-14 Thread Aki Tuomi


On 13.12.2017 21:41, Tanstaafl wrote:
> On 12/12/2017, 1:39:08 PM, Stephan Bosch  wrote:
>> However, keep in mind that for this particular feature we're just 
>> providing the "chicken" as it were. The "egg", i.e. client support, is 
>> still to come. Apart from Trojita (which I think is still not widely 
>> used), I know of no IMAP client supporting BURL/URLAUTH for message 
>> submission. I'd expect to see it first for clients that can truly 
>> benefit; i.e., mobile clients such as K9.
> Oh... bummer...
>
> I thought this was simply going to be an SMTP like service that any SMTP
> client could utilize, keeping the BURL/URLAUTH pieces working only
> between Dovecot and the MTA it works with. Meaning, instead of
> connecting an SMTP service provided by Postfix, you connect to one
> provided by Dovecot. I guess there is a good reason it couldn't be made
> to work this way.
>
> For obvious reasons, the likelihood that Thunderbird will add
> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
>
> :(

Actually it's supposed to serve as SMTP-like service as well.

Aki