Re: Sieve fileinto copies messages instead of moving them
On 2019-03-07 02:52, Michael Goth via dovecot wrote:
> require ["fileinto"];
> # rule:[SPAM]
> if header :contains "subject" "SPAMSPAM"
> {
> fileinto "SPAM";
> }
> # rule:[SPAMSPAM]
> if header :contains "subject" "SPAM"
> {
> fileinto "MaybeSPAM";
> }
>
>
> But when I receive a message with subject "SPAMSPAM", the message turns up in
> "SPAM" and "MaybeSPAM". Is this expected behaviour?
You are missing a stop after the fileinto. Otherwise it will not stop, but
rather processing the next rule as well.
Change it to:
require ["fileinto"];
# rule:[SPAM]
if header :contains "subject" "SPAMSPAM"
{
fileinto "SPAM";
stop;
}
# rule:[SPAMSPAM]
if header :contains "subject" "SPAM"
{
fileinto "MaybeSPAM";
stop;
}
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
signature.asc
Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-07 02:47, Aki Tuomi via dovecot wrote: > We'll look into it. It's not usually failing for us, is it failing > consistently or randomly? It is failing consistently. I ran the tests 4 times. It always errors out at the same tests with the same error messages. Going to bed now. Will be able to answer any other questions you might have in 6-7h. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Sieve fileinto copies messages instead of moving them
Hi,
we're running Doveocot 2.3.4.1 with Pigeonhole, from repo.webflow.org.
As far as I understand the RFC for 'fileinto', the following Sieve
script should move a message either into the folder "SPAM" or "MaybeSPAM":
require ["fileinto"];
# rule:[SPAM]
if header :contains "subject" "SPAMSPAM"
{
fileinto "SPAM";
}
# rule:[SPAMSPAM]
if header :contains "subject" "SPAM"
{
fileinto "MaybeSPAM";
}
But when I receive a message with subject "SPAMSPAM", the message turns
up in "SPAM" and "MaybeSPAM". Is this expected behaviour?
Thanks!
Michael
--
Michael Goth
.webflow GmbH
Geschäftsführer: Andreas Schrei
Wasserburger Straße 4
D - 83352 Altenmarkt a. d. Alz
Amtsgericht Traunstein HRB 18537
E-Mail: m...@webflow.de
Tel: +49 (0) 8621 - 99989 - 26
Fax: +49 (0) 8621 - 99989 - 28
Web: www.webflow.de
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 7.3.2019 2.02, Helmut K. C. Tessarek via dovecot wrote: > Hi, > > I was womdering, if anyone has experienced the same issues. When I run the > tests after compiling 2.3.5, the following 4 tests fail: > > http payload echo (ssl): sequential .. : ok > http payload echo (ssl): pipeline : ok > http payload echo (ssl): parallel : > FAILED: Test is hanging > http payload echo (ssl) .. : > FAILED > http payload echo (ssl; unknown size): sequential : ok > http payload echo (ssl; unknown size): pipeline .. : ok > http payload echo (ssl; unknown size): parallel .. : > FAILED: Test is hanging > http payload echo (ssl; unknown size) : > FAILED > 4 / 114 tests failed > Failed to run: ./test-http-payload > > The tests ran fine for 2.3.4.1. Is there any way, to debug the issue any > further? Do the tests write log files? > > It just doesn't make amy sense. Nothing has changed on the OS since I compiled > and tested 2.3.4.1. > > Cheers, > K. C. > Hi! We'll look into it. It's not usually failing for us, is it failing consistently or randomly? Aki signature.asc Description: OpenPGP digital signature
Re: doveadm expunge recursive?
On 6.3.2019 10.24, Maria Arrea via dovecot wrote: > We are happy users of Dovecot 2.3.4.1 . We run a cronjob that deletes > from Trash messages older than 15 days, this is the command we run: > > //usr/bin/doveadm expunge -u $USER mailbox Trash savedbefore 15d/ > > But this commands does NOT delete folders inside Trash. > doveadm-expunge man page says nothing about recursive expunge. Maybe > is not implemented? > > We can not use doveadm mailbox delete, because has no search query > argument. We could elaborate a complex doveadm-search query and with > xargs feed it do mailbox delete, but must be an easier way, how do you > cope with old folders in Trash? Expunge only deletes mails. Just like IMAP EXPUNGE command. You need to use mailbox delete to delete mailboxes. Aki
Re: director in rings
On 6.3.2019 14.26, Maciej Milaszewski IQ PL via dovecot wrote: > Hi > Maby stupid question :) > > It possible to have 3 directors (frontend) > but without rings ? > > All directors connect to this same dovecot (backend) - all backad have > this same login_trusted_networks > > Why would you even use a director then? Aki
Re: how to enable PowerDNS/Weakforced with Fedora and sendmail
wforce is the username always.
auth_policy_hash_nonce should be set to a pseudorandom value that is
shared by your server(s). Weakforced does not need it for anything.
auth_policy_server_api_header should be set to Authorization: Basic
without the < >.
Aki
On 6.3.2019 20.42, Robert Kudyba via dovecot wrote:
> I took suggestions from https://forge.puppet.com/fraenki/wforce to set
> these in /etc/dovecot/conf.d/95-auth.conf
>
> auth_policy_server_url = http://localhost:8084/
> auth_policy_hash_nonce = our_password
> auth_policy_server_api_header = "Authorization: Basic
> hash_from_running_echo-n_base64"
> auth_policy_server_timeout_msecs = 2000
> auth_policy_hash_mech = sha256
> auth_policy_request_attributes = login=%{requested_username}
> pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s
> auth_policy_reject_on_fail = no
> auth_policy_hash_truncate = 8
> auth_policy_check_before_auth = yes
> auth_policy_check_after_auth = yes
> auth_policy_report_after_auth = yes
>
> And auth_debug=yes
>
> in /usr/local/etc/wforce.conf
> webserver("0.0.0.0:8084 ", "our_password")
> So when I run:
> curl -X POST -H "Content-Type: application/json" --data
> '{"login":"ouruser", "remote": "127.0.0.1", "pwhash":"our_password"}'
> http://127.0.0.1:8084/?command=allow -u wforce:our_passwordi
> {"msg": "", "r_attrs": {"defaultReturn": "1"}, "status": 0}
>
> What's the value of wforce and super represent? -u for user? and super
> is the password for the user?
> |curl -X GET http://127.0.0.1:8084/?command=ping -u wforce:super|
> I always get:
> {"status":"failure", "reason":"Unauthorized"}
>
> Using Squirrelmail and logging in brings up the mails but I see these
> Policy server HTTP error: 401 Unauthorized errors over and over:
>
> Mar 06 13:32:16 auth: Debug: http-client: peer 127.0.0.1:8084
> : Successfully connected (1 connections exist,
> 0 pending)
> Mar 06 13:32:16 auth: Debug: http-client[1]: peer 127.0.0.1:8084
> : Using 1 idle connections to handle 1 requests (1
dovecot 2.3.5 - tests fail: http payload echo (ssl)
Hi, I was womdering, if anyone has experienced the same issues. When I run the tests after compiling 2.3.5, the following 4 tests fail: http payload echo (ssl): sequential .. : ok http payload echo (ssl): pipeline : ok http payload echo (ssl): parallel : FAILED: Test is hanging http payload echo (ssl) .. : FAILED http payload echo (ssl; unknown size): sequential : ok http payload echo (ssl; unknown size): pipeline .. : ok http payload echo (ssl; unknown size): parallel .. : FAILED: Test is hanging http payload echo (ssl; unknown size) : FAILED 4 / 114 tests failed Failed to run: ./test-http-payload The tests ran fine for 2.3.4.1. Is there any way, to debug the issue any further? Do the tests write log files? It just doesn't make amy sense. Nothing has changed on the OS since I compiled and tested 2.3.4.1. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: how to enable PowerDNS/Weakforced with Fedora and sendmail
I took suggestions from https://forge.puppet.com/fraenki/wforce to set
these in /etc/dovecot/conf.d/95-auth.conf
auth_policy_server_url = http://localhost:8084/
auth_policy_hash_nonce = our_password
auth_policy_server_api_header = "Authorization: Basic
hash_from_running_echo-n_base64"
auth_policy_server_timeout_msecs = 2000
auth_policy_hash_mech = sha256
auth_policy_request_attributes = login=%{requested_username}
pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s
auth_policy_reject_on_fail = no
auth_policy_hash_truncate = 8
auth_policy_check_before_auth = yes
auth_policy_check_after_auth = yes
auth_policy_report_after_auth = yes
And auth_debug=yes
in /usr/local/etc/wforce.conf
webserver("0.0.0.0:8084", "our_password")
So when I run:
curl -X POST -H "Content-Type: application/json" --data
'{"login":"ouruser", "remote": "127.0.0.1", "pwhash":"our_password"}'
http://127.0.0.1:8084/?command=allow -u wforce:our_passwordi
{"msg": "", "r_attrs": {"defaultReturn": "1"}, "status": 0}
What's the value of wforce and super represent? -u for user? and super is
the password for the user?
curl -X GET http://127.0.0.1:8084/?command=ping -u wforce:super
I always get:
{"status":"failure", "reason":"Unauthorized"}
Using Squirrelmail and logging in brings up the mails but I see these
Policy server HTTP error: 401 Unauthorized errors over and over:
Mar 06 13:32:16 auth: Debug: http-client: peer 127.0.0.1:8084: Successfully
connected (1 connections exist, 0 pending)
Mar 06 13:32:16 auth: Debug: http-client[1]: peer 127.0.0.1:8084: Using 1
idle connections to handle 1 requests (1 total connections ready)
Mar 06 13:32:16 auth: Debug: http-client[1]: queue http://localhost:8084:
Connection to peer 127.0.0.1:8084 claimed request [Req1: POST
http://localhost:8084/?command=allow]
Mar 06 13:32:16 auth: Debug: http-client[1]: conn 127.0.0.1:8084 [0]:
Claimed request [Req1: POST http://localhost:8084/?command=allow]
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req1: POST
http://localhost:8084/?command=allow]: Sent header
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req1: POST
http://localhost:8084/?command=allow]: Send more (sent 100, buffered=357)
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req1: POST
http://localhost:8084/?command=allow]: Finished sending payload
Mar 06 13:32:16 auth: Debug: http-client[1]: peer 127.0.0.1:8084: No more
requests to service for this peer (1 connections exist, 0 pending)
Mar 06 13:32:16 auth: Debug: http-client[1]: conn 127.0.0.1:8084 [0]: Got
401 response for request [Req1: POST http://localhost:8084/?command=allow]
(took 1 ms + 3 ms in queue)
Mar 06 13:32:16 auth: Error: policy(our_user,127.0.0.1,<7CmLNXGDisV/AAAB>):
Policy server HTTP error: 401 Unauthorized
Mar 06 13:32:16 auth: Debug: http-client[1]: conn 127.0.0.1:8084 [0]:
Response payload stream destroyed (0 ms after initial response)
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req1: POST
http://localhost:8084/?command=allow]: Finished
Mar 06 13:32:16 auth: Debug: http-client[1]: queue http://localhost:8084:
Dropping request [Req1: POST http://localhost:8084/?command=allow]
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req1: POST
http://localhost:8084/?command=allow]: Free (requests left=1)
Mar 06 13:32:16 auth: Debug: http-client[1]: peer 127.0.0.1:8084: No
requests to service for this peer (1 connections exist, 0 pending)
Mar 06 13:32:16 auth: Debug: http-client[1]: conn 127.0.0.1:8084 [0]: No
more requests queued; going idle (timeout = 1 msecs)
Mar 06 13:32:16 auth-worker(18997): Debug: Loading modules from directory:
/usr/lib64/dovecot/auth
Mar 06 13:32:16 auth-worker(18997): Debug: Module loaded:
/usr/lib64/dovecot/auth/lib20_auth_var_expand_crypt.so
Mar 06 13:32:16 auth-worker(18997): Debug: Module loaded:
/usr/lib64/dovecot/auth/libdriver_sqlite.so
Mar 06 13:32:16 auth-worker(18997): Debug: pam( our_user
,127.0.0.1,<7CmLNXGDisV/AAAB>): lookup service=dovecot
Mar 06 13:32:16 auth-worker(18997): Debug: pam( our_user
,127.0.0.1,<7CmLNXGDisV/AAAB>): #1/1 style=1 msg=Password:
Mar 06 13:32:16 auth: Debug: policy( our_user
,127.0.0.1,<7CmLNXGDisV/AAAB>): Policy request
http://localhost:8084/?command=allow
Mar 06 13:32:16 auth: Debug: policy( our_user
,127.0.0.1,<7CmLNXGDisV/AAAB>): Policy server request JSON:
{"device_id":"","login":"our_user","protocol":"imap","pwhash":"68","remote":"127.0.0.1","tls":false}
Mar 06 13:32:16 auth: Debug: http-client[1]: queue http://localhost:8084:
Set request timeout to 2019-03-06 13:32:18.444 (now: 2019-03-06
13:32:16.444)
Mar 06 13:32:16 auth: Debug: http-client[1]: queue http://localhost:8084:
Using existing connection to 127.0.0.1:8084 (1 requests pending)
Mar 06 13:32:16 auth: Debug: http-client[1]: request [Req2: POST
http://localhost:8084/?command=allow]: Submitted (requests left=1)
Mar 06 13:32:16 auth: Debug: http-client[1]: peer 127.0.0.1:8084: Using 1
idle connections to handle 1 requests (1 total connections ready)
Re: Strange behaviour with BLF-CRYPT and SHA*-CRYPT pasword schemas
On 6 March 2019 18:16 Kristijan Savic - ratiokontakt GmbH via dovecot <
dovecot@dovecot.org> wrote:
Greetings,
this is less of a bug report or a help request, but we would like to know if
someone can explain the following:
Environment: Centos 7 with Dovecot 2.3.4-2
default_pass_scheme = BLF-CRYPT
password hash in database : BLF-CRYPT
login = works
default_pass_scheme = SHA512 or SHA256-CRYPT
password hash in database : BLF-CRYPT
login = also works
default_pass_scheme = BLF-CRYPT
password hash in database : SHA512-CRYPT
login = does not work
Can someone explain these discrepancies?
--
Kind regards,
Kristijan Savic
ratiokontakt GmbH
Biegenhofstr. 13
96103 Hallstadt
Telefon: +49 (0) 951 9 35 35 - 0
Telefax: +49 (0) 951 9 35 35 - 902
Internet: www.ratiokontakt.de
Geschäftsführer: Dr. Nils Kaufmann, Stefan Kraft
Amtsgericht Bamberg - HRB 3757
ratiokontakt ist zertifiziert nach DIN ISO/IEC 27001
You could configure default scheme as CRYPT. It covers these all. Otherwise you need to make sure passwords have {SCHEME} prefix when it differs from default or oddities occur.
---
Aki Tuomi
Re: how to enable PowerDNS/Weakforced with Fedora and sendmail
On 6 March 2019 18:25 Robert Kudyba via dovecot wrote: We have dovecot-1:2.3.3-1.fc29.x86_64 running on Fedora 29. I'd like to test wforce, from https://github.com/PowerDNS/weakforced. I see instructions at the Authentication policy support page, https://wiki2.dovecot.org/Authentication/Policy I see the Required Minimum Configuration: auth_policy_server_url = http://example.com:4001/ auth_policy_hash_nonce = localized_random_string But when I search for these directives, they're not found: grep auth_policy_server_url /etc/dovecot/conf.d/* Are these to be added to the /etc/dovecot/conf.d/10-auth.conf file? Does anyone know if a good tutorial? You can add them there if you want, dovecot combines all the files into one in the end. --- Aki Tuomi
how to enable PowerDNS/Weakforced with Fedora and sendmail
We have dovecot-1:2.3.3-1.fc29.x86_64 running on Fedora 29. I'd like to test wforce, from https://github.com/PowerDNS/weakforced. I see instructions at the Authentication policy support page, https://wiki2.dovecot.org/Authentication/Policy I see the Required Minimum Configuration: auth_policy_server_url = http://example.com:4001/ auth_policy_hash_nonce = localized_random_string But when I search for these directives, they're not found: grep auth_policy_server_url /etc/dovecot/conf.d/* Are these to be added to the /etc/dovecot/conf.d/10-auth.conf file? Does anyone know if a good tutorial?
Strange behaviour with BLF-CRYPT and SHA*-CRYPT pasword schemas
Greetings, this is less of a bug report or a help request, but we would like to know if someone can explain the following: Environment: Centos 7 with Dovecot 2.3.4-2 default_pass_scheme = BLF-CRYPT password hash in database : BLF-CRYPT login = works default_pass_scheme = SHA512 or SHA256-CRYPT password hash in database : BLF-CRYPT login = also works default_pass_scheme = BLF-CRYPT password hash in database : SHA512-CRYPT login = does not work Can someone explain these discrepancies? -- Kind regards, Kristijan Savic ratiokontakt GmbH Biegenhofstr. 13 96103 Hallstadt Telefon: +49 (0) 951 9 35 35 - 0 Telefax: +49 (0) 951 9 35 35 - 902 Internet: www.ratiokontakt.de Geschäftsführer: Dr. Nils Kaufmann, Stefan Kraft Amtsgericht Bamberg - HRB 3757 ratiokontakt ist zertifiziert nach DIN ISO/IEC 27001 signature.asc Description: This is a digitally signed message part.
Probleme with replication and shared mailbox
Hi Folks !
I finaly resolve my problem !
First of all I had to modify namespaces :
###
namespace inbox {
inbox = yes
location =
mailbox Archive {
auto = subscribe
special_use = \Archive
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Junk {
auto = subscribe
special_use = \Junk
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix = INBOX/
separator = /
subscriptions = yes
type = private
}
namespace partage {
list = children
location =
maildir:/mnt/mail/vmail/%%d/%%n:INDEXPVT=/mnt/mail/vmail/%d/%n/shared/%%u
prefix = shared/%%u/
separator = /
subscriptions = yes
type = shared
}
###
Also change the « replication_dsync_parameters » in aim to syncronize only the
Private namespace :
==> replication_dsync_parameters = -d -n inbox -l 30 -U
I change the sharing command from « acl set » to « acl add »
AND THE MOST IMPORTANT ==> RUN THE COMMAND ON THE 2 SERVER because of
active/active réplication…
==> doveadm acl add -u us...@exemple.fr INBOX user=us...@exemple.fr admin
create delete expunge insert lookup post read write write-deleted write-seen
Hope this may help if someone is faced to the same problem
Best regards
Laurent
Re: “Message cannot be displayed because of the way it is formatted” iOS
On 2019-03-06 12:00, James Brown via dovecot wrote: Have updated our mail server and are now running Dovecot 2.3.4. Things are mostly working OK, but occasionally I have users on latest iOS getting this message: “this message cannot be displayed because of the way it is formatted. Ask the sender to send it again using a different format or email program. multipart/alternative” The email seems to open OK on the macOS version of Mail.app. Also getting “Loading...” displayed in body section of the app with content never displayed. Most emails are fine, but just get this strange ones occasionally. Our previous mail server was much older, with older version of Dovecot, etc. This server never used to have these issues. Just wondering if anyone has any ideas or suggestions? Can’t see anything in the logs. You are probably seeing the effects of a bug or shortcut in the iOS mail client. A few years ago, I was working on system that sent bulk marketing emails. I had particular problems with iOS and multipart/alternative messages. iOS would insist on displaying the second of the multipart components assuming that it was html, without actually checking the MIME type. For other technical reasons, I wanted to construct the multipart mail so that the html version body was before the plain text version. Every other email client I tested worked fine, but iOS broke when it saw that message. I also saw problems when iOS mail was configured to only download the first 32kb of each email (to save on cellular data), but those problems where intermittent and harder to pin down. In short, I doubt there is a bug in dovecot, it will be following the RFCs, but iOS is probably playing fast and loose with the standards. -- David Pottage
director in rings
Hi Maby stupid question :) It possible to have 3 directors (frontend) but without rings ? All directors connect to this same dovecot (backend) - all backad have this same login_trusted_networks -- Maciej Miłaszewski IQ PL Sp. z o.o. Starszy Administrator Systemowy
“Message cannot be displayed because of the way it is formatted” iOS
Have updated our mail server and are now running Dovecot 2.3.4. Things are mostly working OK, but occasionally I have users on latest iOS getting this message: “this message cannot be displayed because of the way it is formatted. Ask the sender to send it again using a different format or email program. multipart/alternative” The email seems to open OK on the macOS version of Mail.app. Also getting “Loading...” displayed in body section of the app with content never displayed. Most emails are fine, but just get this strange ones occasionally. Our previous mail server was much older, with older version of Dovecot, etc. This server never used to have these issues. Just wondering if anyone has any ideas or suggestions? Can’t see anything in the logs. Thanks, James. smime.p7s Description: S/MIME cryptographic signature
doveadm expunge recursive?
Hello We are happy users of Dovecot 2.3.4.1 . We run a cronjob that deletes from Trash messages older than 15 days, this is the command we run: /usr/bin/doveadm expunge -u $USER mailbox Trash savedbefore 15d But this commands does NOT delete folders inside Trash. doveadm-expunge man page says nothing about recursive expunge. Maybe is not implemented? We can not use doveadm mailbox delete, because has no search query argument. We could elaborate a complex doveadm-search query and with xargs feed it do mailbox delete, but must be an easier way, how do you cope with old folders in Trash?
