Re: sieve filter move wrong email to Junk folder
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
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
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
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
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
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
> 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
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-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: D6773400AB09.ADBA7 to
24EDE400AABD
Dec 14 02:54:56 mail MailScanner[18700]: Uninfected: Delivered 1 messages
Dec 14 02:54:56 mail postfix/qmgr[1756]: 24EDE400AABD:
from=, size=6784, nrcpt=1 (queue active)
Dec 14 02:54:56 mail MailScanner[18700]: Deleted 1 messages from
processing-
Re: New Dovecot service: SMTP Submission (RFC6409)
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)
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
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
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))
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
> # %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
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 =
lin
Re: New Dovecot service: SMTP Submission (RFC6409)
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
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
> 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
> 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
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)
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
