Re: murmurhash3 test failures on big-endian systems

On Tue, Mar 27, 2018 at 08:46:20 -0400, Josef 'Jeff' Sipek wrote: > On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > It turns out there's a missing

Re: murmurhash3 test failures on big-endian systems

On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > It turns out there's a missing byte-inversion when loading the blocks > > which should be addressed in

Re: murmurhash3 test failures on big-endian systems

On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > It turns out there's a missing byte-inversion when loading the blocks > which should be addressed in getblock{32,64}. Murmurhash treats each > block as an integer expecting

Re: murmurhash3 test failures on big-endian systems

On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > Hi, > > On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > > ... > > > I'd be happy to test the patch, thanks! >

Re: murmurhash3 test failures on big-endian systems

Hi, On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > ... > > I'd be happy to test the patch, thanks! > > Ok, try the attached patch. (It is a first pass at the issue, so it may not > be the fina

Re: murmurhash3 test failures on big-endian systems

On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: ... > I'd be happy to test the patch, thanks! Ok, try the attached patch. (It is a first pass at the issue, so it may not be the final diff that'll end up getting committed. It'd be good to know if it actually fixes the is

Re: murmurhash3 test failures on big-endian systems

; relevant output from e.g. s390x is: > > > > test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, > > vectors[i].result, sizeof(result)) == 0 > > test-murmurhash3.c:22: Assert(#11) failed: memcmp(result, > > vectors[i].result, sizeof(result)) == 0 > > tes

Re: murmurhash3 test failures on big-endian systems

On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > Hi, > > The dovecot 2.3.0.1 Debian package currently fails to build on all > big-endian architectures[1], due to murmurhash3 tests failing. The > relevant output from e.g. s390x is: > > test-murmurhash3.c:22: Asse

murmurhash3 test failures on big-endian systems

Hi, The dovecot 2.3.0.1 Debian package currently fails to build on all big-endian architectures[1], due to murmurhash3 tests failing. The relevant output from e.g. s390x is: test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 test-murmurhash3.c

"make check" test-hash-method bus error (Sparc alignment)

3f9b7e9054#diff-2ff53ae0e00a90ee20d648229ad91d2b But the tests use hand written test vectors, that are not correctly aligned: ... hash method md4 (test vectors) ... : ok hash method md5 (test vectors) ... : ok /bin/ksh[2]:

Re: test-net.c failure

This test is not dependant on the configuration file. I have to see under which exact circumstances does it fail. It should not fail even if you don't have IPv6 enabled on your system. Aki > On January 31, 2018 at 10:09 AM Rupert Gallagher <r...@protonmail.com> wrote: >

Re: test-net.c failure

I meant to disable it when configuring the source, and thus when running make check. The test fails on 2.3.0 only, the 2.2 branch did not have this problem. Sent from ProtonMail Mobile On Wed, Jan 31, 2018 at 05:56, Prasad K <pra...@cloudcomputer.in> wrote: > The dovecot.conf file fr

Re: test-net.c failure

more complex, # edit conf.d/master.conf. #listen = *, :: --- snip --- HTH -- Prasad On 30/01/18 11:35 PM, Rupert Gallagher wrote: test-net.c:79: Assert failed: strcmp(net_ip2addr(), "::5") == 0 test-net.c:83: Assert failed: strcmp(net_ip2a

test-net.c failure

test-net.c:79: Assert failed: strcmp(net_ip2addr(), "::5") == 0 test-net.c:83: Assert failed: strcmp(net_ip2addr(), "::5") == 0 net_ip2addr() : FAILED Hello, Is it possible to disable DOVECOT_IPV6? We do not use IPv

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

On 26 Feb 2017, at 14.42, Ruga <r...@protonmail.com> wrote: > > Timo, > > re: What OS is this? > OS 10.12.3 with Xcode 8.2.1 and the official clang 3.9.0 > > re: test-time-util.c > > > t_strftime and variants now ..

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

Timo, re: What OS is this? OS 10.12.3 with Xcode 8.2.1 and the official clang 3.9.0 re: test-time-util.c t_strftime and variants now .. : ok Info: 'Thu, 08 Dec 2016 18:42:16 +0100' test-time-util.c:124: Assert failed: strcmp(t_strftime(RFC2822_FMT

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

Am 2017-02-25 um 22:42 schrieb Aki Tuomi: Silly thunderbird, does not understand that "reply to sender" should reply to sender... I think it is correct, as the sender explicitly stated: Reply-To: Dovecot Mailing List -- peter

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

Silly thunderbird, does not understand that "reply to sender" should reply to sender... Aki On 2017-02-25 23:40, Aki Tuomi wrote: tästä jäi pätsi =) Aki On 2017-02-25 22:08, Timo Sirainen wrote: On 25 Feb 2017, at 21.54, Timo Sirainen wrote: Oh, I forgot to remove the #if

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

tästä jäi pätsi =) Aki On 2017-02-25 22:08, Timo Sirainen wrote: On 25 Feb 2017, at 21.54, Timo Sirainen wrote: Oh, I forgot to remove the #if OPENSSL_VERSION_NUMBER checks from lib-dcrypt. Will be removed in v2.2.29. Attached the planned patch that should do it. Well that

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

openssl.diff Description: Binary data

Re: v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

On 25 Feb 2017, at 21.11, Ruga <r...@protonmail.com> wrote: > > t_strftime and variants now .. : ok > > > test-time-util.c:123: Assert failed: strcmp(t_strftime(RFC2822_FMT, > gmtime()), exp) == 0 > > > test-time-

v2.2.28: patches (to use libressl 2.4.5) and test error (strftime)

t_strftime and variants now .. : ok test-time-util.c:123: Assert failed: strcmp(t_strftime(RFC2822_FMT, gmtime()), exp) == 0 test-time-util.c:124: Assert failed: strcmp(t_strfgmtime(RFC2822_FMT, ts), exp) == 0 t_strftime and variants fixed timestamp

Re: Dovecot 2.2.25 test failure

4:19 PM "Michael A. Peters" <mpet...@domblogger.net> wrote: On 08/04/2016 06:13 AM, Aki Tuomi wrote: On 04.08.2016 16:11, Michael A. Peters wrote: Operating system - 64 bit CentOS 7 gcc-4.8.5-4.el7.x86_64 Building against LibreSSL which has been fine for other releases, but i

Re: Dovecot 2.2.25 test failure

t; On 04.08.2016 16:11, Michael A. Peters wrote: > > >>>> Operating system - 64 bit CentOS 7 > > >>>> gcc-4.8.5-4.el7.x86_64 > > >>>> > > >>>> Building against LibreSSL which has been fine for other releases, but

Re: Dovecot 2.2.25 test failure

>> wrote: > >> > >> > >> On 08/04/2016 06:13 AM, Aki Tuomi wrote: > >>> > >>> > >>> On 04.08.2016 16:11, Michael A. Peters wrote: > >>>> Operating system - 64 bit CentOS 7 > >>>> gcc-4.8.5-4.el7.x8

Re: Dovecot 2.2.25 test failure

x86_64 Building against LibreSSL which has been fine for other releases, but it is a crypto test that is fails. Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but fails the make check Dovecot 2.2.24 passes make check on both. This is where it fails: Making check in lib-dcrypt m

Re: Dovecot 2.2.25 test failure

>> gcc-4.8.5-4.el7.x86_64 > >> > >> Building against LibreSSL which has been fine for other releases, but > >> it is a crypto test that is fails. > >> > >> Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but > >> fails th

Re: Dovecot 2.2.25 test failure

On 08/04/2016 06:13 AM, Aki Tuomi wrote: On 04.08.2016 16:11, Michael A. Peters wrote: Operating system - 64 bit CentOS 7 gcc-4.8.5-4.el7.x86_64 Building against LibreSSL which has been fine for other releases, but it is a crypto test that is fails. Tried with LibreSSL 2.4.2 and 2.3.6

Re: Dovecot 2.2.25 test failure

On 04.08.2016 16:11, Michael A. Peters wrote: > Operating system - 64 bit CentOS 7 > gcc-4.8.5-4.el7.x86_64 > > Building against LibreSSL which has been fine for other releases, but > it is a crypto test that is fails. > > Tried with LibreSSL 2.4.2 and 2.3.6 - bot

Dovecot 2.2.25 test failure

Operating system - 64 bit CentOS 7 gcc-4.8.5-4.el7.x86_64 Building against LibreSSL which has been fine for other releases, but it is a crypto test that is fails. Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but fails the make check Dovecot 2.2.24 passes make check

Re: Mailbox doesn't exist: test

open mailbox test: Mailbox doesn't exist: test Is this is as simple as adding lda_mailbox_autocreate = yes to my conf file, and does it go at the ‘top’ level of the file, or does it need to be in some sort of clause? you should find the option in the sample config files. It should go in the

Mailbox doesn't exist: test

I’ve been getting an error when trying to save mail based on address extensions where dovecot is not creating the mailbox: dovecot: lda(u...@example.com): msgid=<balhs-u...@example.net>: save failed to open mailbox test: Mailbox doesn't exist: test Is this is as simple as

Re: auth_request_get_var_expand test fails on big endian arches.

Hi, On 27 November 2015 at 13:42, Timo Sirainen <t...@iki.fi> wrote: > On 02 Nov 2015, at 15:28, Rafael dos Santos <rdoss...@redhat.com> wrote: > > > > Hi, > > > > when running the tests in a big endian machine, I get the following > error: > >

Re: auth_request_get_var_expand test fails on big endian arches.

On 02 Nov 2015, at 15:28, Rafael dos Santos <rdoss...@redhat.com> wrote: > > Hi, > > when running the tests in a big endian machine, I get the following error: > > 0 / 1 tests failed > test-auth-request-var-expand.c:99: Assert failed: strcmp(str_c(str), > test_ou

Re: auth_request_get_var_expand test fails on big endian arches.

Timo, On 27 November 2015 at 13:49, Rafael dos Santos <rdoss...@redhat.com> wrote: > > >> Should be fixed by http://hg.dovecot.org/dovecot-2.2/rev/cf956e34dc11 >> > > > I will test on a big-endian machine and report back. > I tested the patch and now al

auth_request_get_var_expand test fails on big endian arches.

Hi, when running the tests in a big endian machine, I get the following error: 0 / 1 tests failed test-auth-request-var-expand.c:99: Assert failed: strcmp(str_c(str), test_output) == 0 test-auth-request-var-expand.c:104: Assert failed: strcmp(str_c(str), test_output) == 0 auth request var expand

Compiling v2.2.19 - internal compiler error: segmentation fault (test-timing.c -> int64_t issue?)

: - [...] gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib-test -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2-MT

Assert test not compatible with s390(x) and ppc64 architectures

Hi, we have found that assert test fails on some architectures: test-net.c:59: Assert failed: net_addr2ip(127.0.0.1, ip) == 0 ip.family == AF_INET ip.u.ip4.s_addr == (127 | (1 24)) It seems as bug in test suit as test is expecting IPv4 address in LE format (0x017f), but it gets

Test

Test msg, nock nock dovecot list?

Mailing list test

Apparently this list has somehow broken.. Not really sure what the problem is, lets see what happens to this mail.

Re: Mailing list test

On 21 Nov 2014, at 06:34, Timo Sirainen t...@iki.fi wrote: Apparently this list has somehow broken.. Not really sure what the problem is, lets see what happens to this mail. Easy enough :) Looks like mailman hadn't automatically started after server reboot for some reason.

Re: Mailing list test

On Fri, 21 Nov 2014, Timo Sirainen wrote: Apparently this list has somehow broken.. Not really sure what the problem is, lets see what happens to this mail. Any chance of putting [dovecot] back in the subject line? Thanks. Max Pyziur p...@brama.com

Re: Mailing list test

On 11/20/2014 04:34 PM, Timo Sirainen wrote: Apparently this list has somehow broken.. Not really sure what the problem is, lets see what happens to this mail. thanks for fixing it. I thought the problem was on my end with my new server and got yelled at on the postfix list on some of my

Re: Mailing list test

Am 20.11.2014 um 23:06 schrieb Max Pyziur: On Fri, 21 Nov 2014, Timo Sirainen wrote: Apparently this list has somehow broken.. Not really sure what the problem is, lets see what happens to this mail. Any chance of putting [dovecot] back in the subject line? how did the words DKIM and

Re: v2.2.15 released - test suite segfault

On Saturday 25 of October 2014, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig Test suite passes but at the end: fatal_printf_format_fix .. : ok 0 / 190 tests

Re: v2.2.15 released - test suite segfault

On 25 Oct 2014, at 06:11, Arkadiusz Miśkiewicz ar...@maven.pl wrote: fatal_printf_format_fix .. : ok 0 / 190 tests failed ==6098== Invalid read of size 16 ==6098==at 0x317B880804: ??? (in /lib64/libc-2.20.so) ==6098==by 0x317B8A93B6: ???

Re: v2.2.15 released - test suite segfault

On Saturday 25 of October 2014, Timo Sirainen wrote: On 25 Oct 2014, at 06:11, Arkadiusz Miśkiewicz ar...@maven.pl wrote: fatal_printf_format_fix .. : ok 0 / 190 tests failed ==6098== Invalid read of size 16 ==6098==at 0x317B880804: ??? (in

STARTTLS test (was Re: No AUTH PLAIN with dovecot 2.0.19)

it offers AUTH only over a encrypted channel (recommended) then you need to use STARTTLS before you see the capability and for that telnet is just the wrong tool To test STARTTLS try this: a) gnutls-cli -p 587 --starttls smtp STARTTLS ^D The ^D lets gnutls perform the SSL handshake, then you can

Re: STARTTLS test (was Re: No AUTH PLAIN with dovecot 2.0.19)

tool To test STARTTLS try this: a) gnutls-cli -p 587 --starttls smtp STARTTLS ^D The ^D lets gnutls perform the SSL handshake, then you can type again. b) openssl s_client -connect smtp:587 -starttls smtp -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin

Test / can you see my mail??

Hi! I have to excuse my behave and I am really sorry. Yesterday I wrote two mails to this list and they never showed up in the online archives where I checked it. So that's the reason for this testmail. I hope this mail is readable to all of you? Cheers, Michael

Re: Test / can you see my mail??

I can see it. On 12 Aug 2014 12:20, Michael Ludwig frozenyoghurt2...@gmail.com wrote: Hi! I have to excuse my behave and I am really sorry. Yesterday I wrote two mails to this list and they never showed up in the online archives where I checked it. So that's the reason for this testmail.

Re: Test / can you see my mail??

am 12.08.14 11:50 schrieb Muzaffer Tolga Ozses to...@ozses.net: I can see it. On 12 Aug 2014 12:20, Michael Ludwig frozenyoghurt2...@gmail.com wrote: Hi! I have to excuse my behave and I am really sorry. Yesterday I wrote two mails to this list and they never showed up in the online

Re: Test / can you see my mail??

On Tue, Aug 12, 2014 at 11:20 AM, Michael Ludwig frozenyoghurt2...@gmail.com wrote: HI, I hope this mail is readable to all of you? I don't know. Do you? -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/

Re: Test / can you see my mail??

On Tue, 12 Aug 2014 11:20:03 +0200 Michael Ludwig frozenyoghurt2...@gmail.com wrote: I hope this mail is readable to all of you? Nope, I can't... :-) l. -- /\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2

Re: Test / can you see my mail??

HI! On Tuesday 12 August 2014 14:24:10 Luciano Mannucci wrote: Nope, I can't... :-) me2! cu!

[Dovecot] dkim test

just testing, if it tempfails on dovecot mail me private from the admins of dovecot maillist only

[Dovecot] Test outgoing email on director setup

HI All, I have a several Exim MTA's relaying mail to a pair of director proxies via LMTP which then relayi to several mailstores via LMTP   Incoming mail is working fine.  My outgoing mail uses LMTP also in the reverse of above.   How do I manually test outgoing mail on the mailstores

[Dovecot] plain test passwords

Is it possible to enable plaintext passwords on dovecot?

Re: [Dovecot] plain test passwords

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Broch wrote the following on 11.02.2014 09:19: Is it possible to enable plaintext passwords on dovecot? A simple look at the Wiki will answer your question: http://wiki2.dovecot.org/Authentication/Mechanisms -BEGIN PGP SIGNATURE-

Re: [Dovecot] undoing a zlib test

On Dec 9, 2013, at 11:41 PM, Robert Schetterer r...@sys4.de wrote: Am 10.12.2013 01:08, schrieb Terry Barnum: I'm trying to undo a dovecot zlib test and uncompress 6 emails in my Junk mailbox. There are about 25 total in different mailboxes but I thought I'd first start with those in my

[Dovecot] undoing a zlib test

I'm trying to undo a dovecot zlib test and uncompress 6 emails in my Junk mailbox. There are about 25 total in different mailboxes but I thought I'd first start with those in my Junk. I ran: # dsync -v -u te...@dop.com -m Junk -o plugin/zlib_save= backup maildir:/path/to/temp/folder which

Re: [Dovecot] undoing a zlib test

Am 10.12.2013 01:08, schrieb Terry Barnum: I'm trying to undo a dovecot zlib test and uncompress 6 emails in my Junk mailbox. There are about 25 total in different mailboxes but I thought I'd first start with those in my Junk. I ran: # dsync -v -u te...@dop.com -m Junk -o plugin/zlib_save

[Dovecot] Any way to test a master user's password?

Hello, Is there any way to easily check a master user's password, for itself, without having to refer to another user or to weak the security by allowing master users to log in for themselves? For example, this works: # doveadm auth test 'someuser*masteruser' Password: enter

Re: [Dovecot] Any way to test a master user's password?

Google the terms Dictionary Attack and Rainbow Table  perhaps ?  ;-) From: Axel Luttgens axelluttg...@swing.be To: Dovecot Mailing List dovecot@dovecot.org Sent: Friday, 16 August 2013, 13:55 Subject: [Dovecot] Any way to test a master user's password? Hello

Re: [Dovecot] script to test CATENATE

x append inbox catenate (url ;invalid; url {5} Dovecot replies with + OK because it wants to read all the URLs into memory before parsing them, while catenate.pl expects an error message immediately. I see that Example 4 in Appendix A of RFC 4469 explicitly allows both models. Here's a

Re: [Dovecot] script to test CATENATE

On 23.7.2013, at 1.17, Mike Abbott michael.abb...@apple.com wrote: Attached please find a perl script which tests the CATENATE support in dovecot. I used this to test my CATENATE implementation a few years ago and it runs fine against dovecot in OS X Server. When run against dovecot-2.2.4

Re: [Dovecot] script to test CATENATE

On 22/07/2013 23:17, Mike Abbott wrote: Attached please find a perl script which tests the CATENATE support in dovecot. I used this to test my CATENATE implementation a few years ago and it runs fine against dovecot in OS X Server. Hi Mike Do you think you might re-submit the matching BURL

Re: [Dovecot] script to test CATENATE

Do you think you might re-submit the matching BURL support to Postfix? I don't think re-submitting is a good idea unless Wietse co. request it, which I doubt will happen.

Re: [Dovecot] script to test CATENATE

On 23/07/2013 14:30, Mike Abbott wrote: Do you think you might re-submit the matching BURL support to Postfix? I don't think re-submitting is a good idea unless Wietse co. request it, which I doubt will happen. My reading of it at the time was something like There are no clients that

[Dovecot] script to test CATENATE

Attached please find a perl script which tests the CATENATE support in dovecot. I used this to test my CATENATE implementation a few years ago and it runs fine against dovecot in OS X Server. When run against dovecot-2.2.4 though it always fails or hangs, which in some cases means we

Re: [Dovecot] Allowing clients to test their Sieve scripts

On Jun 19, 2013, at 1:00 AM, Steffen Kaiser skdove...@smail.inf.fh-brs.de wrote: On Fri, 14 Jun 2013, Frerich Raabe wrote: I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them

Re: [Dovecot] Allowing clients to test their Sieve scripts

/sievetest.php code managesive plugin to make it test scripts before commit it to filesystem the ManageSieve from Pigeonhole performs syntax checks before committing the script to the filesystem. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUcFj

Re: [Dovecot] Allowing clients to test their Sieve scripts

receive any mail, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server

Re: [Dovecot] Allowing clients to test their Sieve scripts

. Can you check the logs?. +1 I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just prints a form asking for a mail file

Re: [Dovecot] Allowing clients to test their Sieve scripts

staticsafe skrev den 2013-06-14 18:50: The ManageSieve plugin in Thunderbird does basic syntax checks, to check if your Sieve script does what it is supposed to to do, there is something like this - https://www.fastmail.fm/docs/sieve/sievetest.php code managesive plugin to make it test

Re: [Dovecot] Allowing clients to test their Sieve scripts

Thomas Harold skrev den 2013-06-14 18:50: If you have Thunderbird, you may want to have them try out the Sieve plug-in available at http://sieve.mozdev.org/ yes but it learns fast imho http://smartsieve.sourceforge.net/ is very good sieve webpanel, just a bit sad its not developped anymore,

Re: [Dovecot] Allowing clients to test their Sieve scripts

Ben Morrow skrev den 2013-06-14 20:07: Simply providing some way for them to read the .dovecot.sieve.log file created in their home directory would be a good start. If there are any problems with delivery they will be logged there. You could set up some sort of web access, or even have a

Re: [Dovecot] Allowing clients to test their Sieve scripts

On Jun 14, 2013, at 7:05 PM, Ben Morrow b...@morrow.me.uk wrote: At 6PM -0700 on 14/06/13 you (Frerich Raabe) wrote: Nice, judging from the source code it looks very much like what I was thinking of! However, as it happens my IMAP server is *very* minimalistic (it runs FreeBSD and has

[Dovecot] Allowing clients to test their Sieve scripts

then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just prints a form asking for a mail file and a sieve script, and then it runs

Re: [Dovecot] Allowing clients to test their Sieve scripts

, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just

Re: [Dovecot] Allowing clients to test their Sieve scripts

broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just prints a form asking for a mail

Re: [Dovecot] Allowing clients to test their Sieve scripts

didn't receive any mail, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web

Re: [Dovecot] Allowing clients to test their Sieve scripts

On 6/14/2013 1:11 PM, Ben Johnson wrote: One of the obvious limitations of using the Thunderbird plug-in, or the web-based tool as cited, is that neither one has any way to know which Sieve modules have been required. Oftentimes fatal errors result from referencing a module that hasn't been

Re: [Dovecot] Allowing clients to test their Sieve scripts

like I don't know whether I just didn't receive any mail, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try

Re: [Dovecot] Allowing clients to test their Sieve scripts

filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just prints a form asking

Re: [Dovecot] Allowing clients to test their Sieve scripts

don't know whether I just didn't receive any mail, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves

Re: [Dovecot] Allowing clients to test their Sieve scripts

their Sieve scripts, i.e. it often goes like I don't know whether I just didn't receive any mail, or whether my filters broke. Can you check the logs?. I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering

Re: [Dovecot] Allowing clients to test their Sieve scripts

On Jun 14, 2013, at 11:42 AM, Ben Johnson b...@indietorrent.org wrote: Sounds as though you've answered your own question. You probably need to build some type of Web interface for sieve-test that is well-secured and well-escaped. Looks like it. Kinda surprising that nobody else needed

Re: [Dovecot] Allowing clients to test their Sieve scripts

On 6/14/2013 3:06 PM, Frerich Raabe wrote: On Jun 14, 2013, at 11:42 AM, Ben Johnson b...@indietorrent.org wrote: Sounds as though you've answered your own question. You probably need to build some type of Web interface for sieve-test that is well-secured and well-escaped. Looks like

Re: [Dovecot] Allowing clients to test their Sieve scripts

On 6/14/2013 2:07 PM, Ben Morrow wrote: Simply providing some way for them to read the .dovecot.sieve.log file created in their home directory would be a good start. If there are any problems with delivery they will be logged there. You could set up some sort of web access, or even have a daily

Re: [Dovecot] Allowing clients to test their Sieve scripts

, and can be also configured to be available via TCP. http://wiki2.dovecot.org/Design/AuthProtocol Also an even simpler way: Just run doveadm auth test username password and see if it returns 0.

Re: [Dovecot] Allowing clients to test their Sieve scripts

On 6/14/2013 3:28 PM, Thomas Harold wrote: On 6/14/2013 2:07 PM, Ben Morrow wrote: Simply providing some way for them to read the .dovecot.sieve.log file created in their home directory would be a good start. If there are any problems with delivery they will be logged there. You could set

Re: [Dovecot] Allowing clients to test their Sieve scripts

At 10PM +0300 on 14/06/13 you (Timo Sirainen) wrote: On 14.6.2013, at 22.22, Ben Johnson b...@indietorrent.org wrote: The complexities associated with authentication will be the most difficult part (at least if you want to build something reusable). Dovecot has a pretty easily usable

Re: [Dovecot] Allowing clients to test their Sieve scripts

the user's credentials securely. Plaintext authentication is not an option in my environment. In the meantime, here's a very rough-cut of a PHP script that accepts a Sieve script and an email body, and prints-out the sieve-test results. http://pastebin.com/7mHL2w0z This works fine on my server. Next

Re: [Dovecot] Allowing clients to test their Sieve scripts

At 5PM -0400 on 14/06/13 you (Ben Johnson) wrote: Thanks Timo and Ben for the authentication suggestions. I'll look into those further. It seems clear that whatever method is used, it has to transmit the user's credentials securely. Plaintext authentication is not an option in my

Re: [Dovecot] Allowing clients to test their Sieve scripts

On Jun 14, 2013, at 2:21 PM, Ben Johnson b...@indietorrent.org wrote: In the meantime, here's a very rough-cut of a PHP script that accepts a Sieve script and an email body, and prints-out the sieve-test results. http://pastebin.com/7mHL2w0z This works fine on my server. Next week, I'll

Re: [Dovecot] Allowing clients to test their Sieve scripts

users can paste scripts and email bodies would do the job. The form inputs can then be passed to sieve-test. Needless to say, the form inputs should be escaped very carefully to prevent arbitrary code from being executed on your system. I just re-read your mail, and I must admit I don't understand

Re: [Dovecot] Allowing clients to test their Sieve scripts

At 6PM -0700 on 14/06/13 you (Frerich Raabe) wrote: Nice, judging from the source code it looks very much like what I was thinking of! However, as it happens my IMAP server is *very* minimalistic (it runs FreeBSD and has just 9 software packages installed, the bare minimum I needed for

[Dovecot] test

mailman archive process seems to have crashed and hasn't been writing to archives. lets see if it works again after restart..

[Dovecot] Fwd: IMAP SSL incoming test need help !

Sent from my iPhone Begin forwarded message: From: Dennis Chen dchen...@yahoo.com Date: April 19, 2012 5:38:01 PM PDT To: dovecot@dovecot.org Subject: Fwd: [Dovecot] IMAP SSL incoming test need help ! Sent from my iPhone Begin forwarded message: From: D Chen dchen

<    1   2   3   >