Re: [Dovecot] smartsieve managesieve-login failure with dovecot 2.1.7
On 10/7/2013 1:01 AM, Wouter Berkepeis wrote: > > Everything OK I guess. Especially the first part of the output is > interesting: "IMPLEMENTATION" "Dovecot Pigeonhole" > This is what Smartsieve is looking at. With the former version the > string was 'dovecot', so I changed this in the 'Managesieve.php' file. > This file was already patched as stated on the site. Furthermore I > changed everything referring to port 2000 to port 4190. That should work. I used the patch mentioned here: http://www.mail-archive.com/dovecot@dovecot.org/msg21862.html And modified it for the new situation. I'm assuming this is very similar to what you're doing and here it works. You could try to obtain more information by logging the protocol exchange: http://wiki2.dovecot.org/Debugging/Rawlog Alternatively you can debug Smartsieve by adding more logging into the source code. And yes, SmartSieve is unmaintained, so I would not recommend using it anymore. Regards, Stephan.
Re: [Dovecot] Yet another going from 1.2 to 2.X question: authentication
On Thu, Sep 19, 2013 at 2:40 AM, Noel Butler wrote:
> On Thu, 2013-09-19 at 00:50 -0400, Mauricio Tavares wrote:
>
>> So in 1.2.9 I had something like this:
>>
>> [...]
>>
>> socket listen {
>> master {
>> path = /var/run/dovecot/auth-master
>> mode = 0600
>> user = virtual # User running Dovecot LDA's deliver
>> }
>> }
>>
>> # Dovecot as SASL Auth
>> socket listen {
>> client {
>> path = /var/spool/postfix/private/dovecot-auth
>> mode = 0660
>> user = postfix
>> group = postfix
>> }
>> }
>>
>> I see I can, per http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL,
>> setup the sasl entry as
>>
>> # Dovecot as SASL Auth
>> service auth {
>> unix_listener /var/spool/postfix/private/dovecot-auth
>> mode = 0660
>> user = postfix
>> group = postfix
>> }
>>
>> what about the lda? From http://wiki2.dovecot.org/LDA I take it would
>> be as simple as
>>
>> service auth {
>> unix_listener auth-userdb {
>> mode = 0600
>> user = virtual # User running Dovecot LDA's deliver
>> }
>> }
>>
>> Am I correct?
>
>
> Yes, but no need for two service auth's, put them under the one. you
> might want to also include group= in addition to user, probably wont
> matter too much if you don't, I cant remember the consequences of not.
>
Makes sense, so I shall set them up as
/etc/dovecot/conf.d/10-master.conf
# http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
service auth {
unix_listener auth-userdb {
mode = 0600
user = virtual # User running Dovecot LDA's deliver
}
# Dovecot as SASL Auth
unix_listener /var/spool/postfix/private/dovecot-auth {
mode = 0660
user = postfix
group = postfix
}
}
Thanks for the help (and sorry for the late reply)! Now as soon as the
namespaces make sense to me and I figure out how to get sieve properly
configured I can do the upgrade.
Re: [Dovecot] Transparent Migration from cyrus to dovecot
On 10/6/2013 1:56 PM, Ed W wrote: Make use of the proxy feature. You can add a "server" entry into your userdb, that way you can literally move users over one by one and flip their server location. You can easily test individual users and move them over individually. Works brilliantly Second this. Pair it with a snapshot-capable FS and you can migrate the bulk of data in the background, then do the stop cyrus delivery, offline cyrus, copy remaining differences, online dovecot, start delivery to dovecot steps in a matter of seconds.
Re: [Dovecot] retr errors
On 07/10/2013 11:19, Bill Morgan wrote: On 10/6/2013 5:58 PM, Daniel Parthey wrote: Hi Bill, any intercepting virus scanner or personal firewall software between your mail client and the dovecot server? Regards Daniel McAfee As I'm sure Daniel was implying, did you also test without these? Also, do they provide webmail? next time you get a stuck message, login to webmail and see if its OK there, try using only webmail for a week or two, if you have this trouble every day, you'll soon reproduce it, or rule out the ISP end. and the ISP wasn't interested in the wireshark traces. Baring in mind, that ISP tech support, is exactly that, "ISP, Tech Support" not Microsoft support, or apple support or whatever, the ISP can only support its services, not your local client software, if they can prove, and your ISP should have by process of elimination, for instance, webmail, you have no trouble, then they have ruled out an ISP related cause, and they are very within their rights to say "not our problem". Also remember, engineers tend to act/get-involved when complaints are en-mass, its to their advantage to look at it then, IOW, the care factor will increase with multiple people exhibiting the same problem over a short or same period of time. I know, I should change the ISP and see if the problem goes away. :-) Sounds like a fair idea to me if you rule out everything on your end and can prove beyond doubt it is the ISP, else you'll just be moving the problem sideways, not up towards resolution.
Re: [Dovecot] retr errors
On 10/6/2013 5:58 PM, Daniel Parthey wrote: Hi Bill, any intercepting virus scanner or personal firewall software between your mail client and the dovecot server? Regards Daniel McAfee and the ISP wasn't interested in the wireshark traces. I know, I should change the ISP and see if the problem goes away. :-) Thanks
Re: [Dovecot] couple of errors on new setup
On 07/10/2013 04:58, Timo Sirainen wrote: On 6.10.2013, at 4.04, Noel Butler wrote: mail_nfs_index = yes mail_nfs_storage = yes These are never recommended. They may be a kludgy workaround to avoid worst problems, but they will never work 100% In the recommended configurations (one Dovecot server or director cluster) you won't need them. Ahh OK, thanks, our configs have been carried over since early days when this recommended, certainly never seen any errors with them on our cluster (and we don't use director).
[Dovecot] smartsieve managesieve-login failure with dovecot 2.1.7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I just subscribed to the mailing list because I am stuck trying to solve
a problem getting smartsieve to work with a new version of dovecot.
But let me first explain the situation shortly. I am running a mail
server at home for personal use, and for fun. At this moment this is an
old, slow machine running Debian Squeeze, Dovecot 1.2.15 and Exim 4.72.
Authentication is done with LDAP, running OpenLDAP 2.4.23. For managing
mail filtering I use Smartsieve 1.0.0-RC2 in conjunction with Dovecot's
Managesieve plugin. It's all working properly. But because this machine
is slow, I'm now busy upgrading building a new machine running Debian
Wheezy, Dovecot 2.1.7 and Exim 4.80. I've got it all running and working
now (that is: locally in my lan): imap with dovecot, smtp with exim,
Dovecot's sieve plugin working properly, authentication done through
LDAP backend.
But what I can't get to work is Smartsieve. Looking at the logs on my
server I can tell managesieve-login is not working well with Smartsieve.
As far as I understand authentication is always done over a secure
connection using TLS. Here is some logged output, Dovecot as well as
Smartsieve.
dovecot-info.log:
2013-10-06 21:16:20 managesieve-login: Info: Disconnected (no auth
attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, TLS
handshaking: SSL_accept() failed: error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure: SSL alert number
40, session=
syslog:
Oct 6 21:51:40 jingo smartsieve[12168]: getCryptLib: using rc4
Oct 6 21:51:40 jingo smartsieve[12168]: getCryptLib: using rc4
Oct 6 21:51:40 jingo smartsieve[12168]: FAILED LOGIN: jingo
[192.168.2.12] {Private Lotus}: starttls: TLS initialization failed:
socket timed out while reading server response: #002
Oct 6 21:51:40 jingo smartsieve[12168]:
2Z#027#015141003200542Z0??1#0130#011#006#003U#004#006#023#002NL1#0230#021#006#003U#004#010#014#012Overijssel1#0200#016#006#003U#004#007#014#007Hengelo1#0!#006#003U#004#012#014#032Private
Lotus Organization1#0230#021#006#003U#004#013#014#012Jingo
Mail1&0$#006#003U#004#003#014#035jingo.private-lotus.no-ip.net1&0$#006#011*?H?÷#015#001#011#001#026#027amigo@private-lotus.org0?#001"0#015#006#011*?H?÷#015#001#001#001#005
Oct 6 21:51:40 jingo smartsieve[12168]: #003#001
Oct 6 21:51:40 jingo smartsieve[12168]:
èm¬NþgHÁßt#021×?Ð#011$?f+»#013?#021?ø#013yùZd#032Òí}Ì#012ù?#003xPË
What is clear is that somehow no user information is being negotiated.
Issuing a manual TLS login give the following results:
root@amigos:~# gnutls-cli --starttls -p 4190 jingo.private-lotus.no-ip.net
Resolving 'jingo.private-lotus.no-ip.net'...
Connecting to '82.161.181.183:4190'...
- - Simple Client Mode:
"IMPLEMENTATION" "Dovecot Pigeonhole"
"SIEVE" "fileinto reject envelope encoded-character vacation subaddress
comparator-i;ascii-numeric relational regex imap4flags copy include
variables body enotify environment mailbox date ihave"
"NOTIFY" "mailto"
"SASL" ""
"STARTTLS"
"VERSION" "1.0"
OK "Dovecot ready."
STARTTLS
OK "Begin TLS negotiation now."
*** Starting TLS handshake
- - Ephemeral Diffie-Hellman parameters
- Using prime: 1024 bits
- Secret key: 1022 bits
- Peer's public key: 1024 bits
- - Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `C=NL,ST=Overijssel,L=Hengelo,O=Private Lotus
Organization,OU=Jingo
Mail,CN=jingo.private-lotus.no-ip.net,EMAIL=am...@private-lotus.org',
issuer `C=NL,ST=Overijssel,L=Hengelo,O=Private Lotus
Organization,OU=Private Lotus Certificate
Authority,CN=private-lotus.no-ip.net,EMAIL=am...@private-lotus.org', RSA
key 2048 bits, signed using RSA-SHA, activated `2013-10-03 20:05:42
UTC', expires `2014-10-03 20:05:42 UTC', SHA-1 fingerprint
`85ff6b5846a53e7eb5d46c3c4ebfd7beb253ba15'
- - The hostname in the certificate matches 'jingo.private-lotus.no-ip.net'.
- - Peer's certificate issuer is unknown
- - Peer's certificate is NOT trusted
- - Version: TLS1.1
- - Key Exchange: DHE-RSA
- - Cipher: AES-128-CBC
- - MAC: SHA1
- - Compression: NULL
Everything OK I guess. Especially the first part of the output is
interesting: "IMPLEMENTATION" "Dovecot Pigeonhole"
This is what Smartsieve is looking at. With the former version the
string was 'dovecot', so I changed this in the 'Managesieve.php' file.
This file was already patched as stated on the site. Furthermore I
changed everything referring to port 2000 to port 4190.
But it still ain't working. Am I doing something wrong? Or is Smartsieve
just becoming too outdated to work with newer versions of Dovecot?
To get the picture complete, hereby my used config of Dovecot, generated
with 'dovecot -n' :
root@jingo:~# dovecot -n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-686-pae i686 Debian 7.1
info_log_path = /var/log/dovecot/dovecot-info.log
log_path = /var/log/dovecot/dovecot.log
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:~/Maildir
managesieve_notify_cap
Re: [Dovecot] retr errors
Hi Bill, any intercepting virus scanner or personal firewall software between your mail client and the dovecot server? Regards Daniel
Re: [Dovecot] retr errors
Hi Bill You should send the wireshark traces to your ISP and ask him to fix it. At least one would require the doveconf -n output and the version of dovecot. Probably a bug in an older dovecot version? Regards Daniel
Re: [Dovecot] SSL with startssl.com certificates
Am 06.10.2013 22:42, schrieb Dan Langille: > I have Thunderbird working just fine on my Macbook. > > But my goal is mail.app on my iPhone and my Macbook. When they try to > connect, the mail server logs are: > > Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: > SSLv3 read client certificate A [98.111.147.220] > Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in > 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: > Disconnected, session= > Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 > installation. That's my current IMAP server. I'm moving to another server > and failing so far. > > Suggestions to use another client app or platform will not be entertained, > because, clearly, this works with dovecot 1 and mail.app is working even with *self signed* certificates and dovecot 2.2 you only have to accept / import the certificate proven by a testserver all day long so i assume the problem exists between chair and keyboard signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Transparent Migration from cyrus to dovecot
Make use of the proxy feature. You can add a "server" entry into your userdb, that way you can literally move users over one by one and flip their server location. You can easily test individual users and move them over individually. Works brilliantly Ed W On 06/10/2013 11:39, Jogi Hofmüller wrote: Hi dovecot people, We are in the process of preparing the migration from a cyrus 2.1 installation to dovecot. Dovecot will be installed on new hardware, so we have separated servers that can/will exist in parallel for a while. Our goal is to do the migration without interrupting the service for our users too much. Currently we tend to using dsync. So I am asking for best practice suggestions, tips and hints from people who have done such a thing before. Curiously awaiting your replies ;) Cheers! PS: I am subscribed to the list. So no need to include my address in replies. Thanks!
Re: [Dovecot] SSL with startssl.com certificates
On Sep 17, 2013, at 10:59 AM, Bruno Tréguier wrote:
> Le 17/09/2013 à 16:32, Dan Langille a écrit :
>> $ openssl s_client -connect imaps.unixathome.org:993 -quiet
>> depth=0
>> /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmas...@unixathome.org
>>
>> verify error:num=20:unable to get local issuer certificate
>> verify return:1
>> depth=0
>> /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmas...@unixathome.org
>>
>> verify error:num=27:certificate not trusted
>> verify return:1
>> depth=0
>> /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmas...@unixathome.org
>>
>> verify error:num=21:unable to verify the first certificate
>> verify return:1
>> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
>> IDLE AUTH=PLAIN] Dovecot ready.
>>
>> Somewhere, somehow, there is something vastly different and not working.
>
> Hi,
>
> Something is definitely wrong with your certificate chain. The first
> certificate listed in your chain (depth 2) should be StartCom's root CA,
> bearing "CN = StartCom Certification Authority", the 2nd one (depth 1)
> should be the intermediate cert, bearing "CN = StartCom Class 1 Primary
> Intermediate Server CA" and the last one (depth 0) should be yours.
>
> You told in an earlier message that you had put the 3 certs (yours, then
> the intermediate, and then the root) in your crt file. Is it still the
> case ? If not, you really *must* do it, even if you find it makes no
> difference. Maybe there's another problem somewhere else, but this chain
> is a prerequisite for many clients to work.
After a long delay, I'm ready to tackle this again.
This is my configuration:
# dovecot -n
# 2.2.6: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.1-RELEASE-p6 amd64
auth_debug = yes
auth_verbose = yes
first_valid_gid = 1001
first_valid_uid = 1001
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
passdb {
args = scheme=SHA512-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = 199.233.228.197
port = 0
}
inet_listener imaps {
address = 199.233.228.197
}
}
ssl_cert = dovecot.pem
All the certs are startssl.com certs.
Testing via the command line gives:
$ openssl s_client -connect imaps.unixathome.org:993
CONNECTED(0003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN
= StartCom Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel
Langille/CN=imaps.unixathome.org/emailAddress=postmas...@unixathome.org
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Class 2 Primary Intermediate Server CA
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Class 2 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Certification Authority
2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Certification Authority
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Certification Authority
---
Server certificate
-BEGIN CERTIFICATE-
MIIHsjCCBpqgAwIBAgIDAaiZMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MiBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTMxMDA2MTIzODI3
WhcNMTUxMDA2MjA1NzI4WjCBsjEZMBcGA1UEDRMQVndoZEppMHNMSFAzQkR0UTEL
MAkGA1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEOMAwGA1UEBxMFTWVk
aWExGDAWBgNVBAoTD0RhbmllbCBMYW5naWxsZTEdMBsGA1UEAxMUaW1hcHMudW5p
eGF0aG9tZS5vcmcxKDAmBgkqhkiG9w0BCQEWGXBvc3RtYXN0ZXJAdW5peGF0aG9t
ZS5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQLgy4N8rCnhZS5t
uwA0/4gTmMNdNflfwUgWGGUoeOC3qcodt2EitcnuhLfvDJORrpZtxKYYK0SMAlJt
RHg+DTp+9mSCicDWjoxOcc1WbUUkAiFdkL155LtMEd2xSB/NaEbjeone86ln5erz
4BLJqiaaubOkhAwXrJy/Owfp6RUbqEKUToGI1bF+q5EFFGqh3rO7/3Gpx0qihScx
6sGa04CgqhT0G6JOw6zJ5zJE0PSX4U/S7nAJCA/ktXNU3v23Jd+RYIOqrmuyHnf6
dISQH8HQKr83L3D3Yq64GCadvf0Nv/xrxc/4UO2mpiZlZppf+8Q+vTgfwl98OH62
mqdUM8hspGMAtRGmt8ccB73ukmqHvY9QJEGNNvx181VlTTcAygi/R5LiEtwFewAj
Zk4QvC4O3O3Rxl6VKfEgmoO93EXFfbVylv7MQqs6NKGeIdMgBpcxdsrlXo8ofVCz
uIQvJV8G8mlejP/RstZAoGxtUP5BRrLbcke3q77l6d6DYrTAhb7SgxP31AYrSknj
I+sCNb5IJvrrZe9lZt8OYlm3Yog8wjiTCgeBlytes7L95Dr0Xn8jZk4Dzg59HbO4
AIlSVdMistZatAvM9QFBPUdt36dyNkFOGpAtNblfmV3pB1Wyz0LlxhS2n3XFxSJB
ZgHvBYV891UoSm6julSzeE2i/6liIQIDAQABo4IC8zCCAu8wCQYDVR0TBAIwADAL
BgNVHQ8EBAMCA6gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1Ud
DgQWBBTuSWRJewXVTNYjoX6gw/DdaXcDqTAfBgNVHSMEGDAWgBQR2yNF/VTManFv
hIoD1773AS8mhjAvBgNVHREEKDAmghRpbWFwcy51bml4YXRob21lLm9yZ4IOdW5p
eGF0aG9tZS5vcmcwggFWBgNVHSAEggFNMIIBSTAIBgZngQwBAgIwggE7BgsrBgEE
AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
L3Bv
Re: [Dovecot] Problems getting Squirrelmail and Avelsieve to connect to Pigeonhole
On 10/6/2013 9:01 PM, Steve wrote:
> Running/*# /usr/sbin/ngrep -d lo port 4190 */produces the following
> trace:
>
>/##/
>/T 127.0.0.1:35495 -> 127.0.0.1:4190 [AP]/
>/ AUTHENTICATE "PLAIN" \{28+}.. /
>/##/
>/T 127.0.0.1:35495 -> 127.0.0.1:4190 [AP]/
>/c3RldmUAc3RldmUAbWFnaWNsaWs=.. /
>/##/
>/T 127.0.0.1:4190 -> 127.0.0.1:35495 [AP]/
>/ NO "Invalid characters in atom"..NO "Error in MANAGESIEVE command
>received by server.".. /
>/###/
>
> I hope that someone can provide a way to get the filter management
> working as I am more that happy with the way Dovecot and Squirrelmail
> are working, but just want to add server-side filtering, especially
> tagged mail produced by Spamassassin :)
I was a bit confused by what your screen dump looks like with all those
slashes, so initially I didn't notice one strange slash that is actually
causing this phenomenon. I went as far as installing 2.0.21 with
Pigeonhole 0.2.6 to reproduce this, only to find out that I couldn't.
But.. when I copied this literally into my manual ManageSieve telnet
session:
AUTHENTICATE "PLAIN" \{28+}
it failed in the same manner. The reason is quite obvious: this is not a
valid ManageSieve command. That '\' is not supposed to be there.
So, it looks like AvelSieve is severely broken.
Regards,
Stephan.
[Dovecot] Problems getting Squirrelmail and Avelsieve to connect to Pigeonhole
Hi,
I have been going around in circles trying to find the solution. Many
others appear to have the same problem, but never a solution or explanation.
I am running Dovecot 2.0.21 under Fedora 16.
All components are running on the same server, whose IP address is shown
as '192.168.x.y'.
The dovecot -n output is:
/SSH Secure Shell 3.2.0 (Build 267)/
/Copyright (c) 2000-2002 SSH Communications Security Corp -
http://www.ssh.com//
/This copy of SSH Secure Shell is a non-commercial version./
/This version does not include PKI and PKCS #11 functionality./
/Last login: Sun Oct 6 17:00:08 2013 from 192.168.2.196/
/[root@nsi-server2 ~]# /usr/sbin/dovecot -n/
/# 2.0.21: /etc/dovecot/dovecot.conf/
/# OS: Linux 3.6.11-4.fc16.x86_64 x86_64 Fedora release 16 (Verne) /
/auth_debug_passwords = yes/
/auth_verbose = yes/
/auth_verbose_passwords = plain/
/log_path = /var/log/mail/dovecot.log/
/mail_access_groups = mail/
/mail_location = mbox:~/mail:INBOX=/var/mail/%u/
/managesieve_notify_capability = mailto/
/managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave/
/mbox_write_locks = fcntl/
/passdb {/
/ driver = pam/
/}/
/passdb {/
/ args = /etc/dovecot/users/
/ driver = passwd-file/
/}/
/plugin {/
/ sieve = ~/.dovecot.sieve/
/ sieve_dir = ~/sieve/
/ sieve_global_path = /var/lib/dovecot/sieve/default.sieve/
/}/
/protocols = imap pop3 sieve sieve/
/service imap-login {/
/ inet_listener imap {/
/address = 192.168.x.y,localhost/
/ }/
/ inet_listener imaps {/
/address = 192.168.x.y/
/ }/
/}/
/service managesieve-login {/
/ inet_listener sieve {/
/port = 4190/
/ }/
/}/
/service pop3-login {/
/ inet_listener pop3 {/
/address = 192.168.x,y,localhost/
/ }/
/ inet_listener pop3s {/
/address = 192.168.x.y/
/ }/
/}/
/ssl_cert =
On attempting to connect to the managesieve port from Squirrelmail,
using the 'Filter' button i get the following error message:
/*Could not log on to timsieved daemon on your IMAP server localhost.*/
/*Please contact your administrator*/
Running/*# /usr/sbin/ngrep -d lo port 4190 */produces the following trace:
/[root@nsi-server root]# /usr/sbin/ngrep -d lo port 4190/
/interface: lo (127.0.0.0/255.0.0.0)/
/filter: (ip or ip6) and ( port 4190 )/
//
/T 127.0.0.1:4190 -> 127.0.0.1:35495 [AP]/
/ "IMPLEMENTATION" "Dovecot Pigeonhole".."SIEVE" "fileinto reject
envelope encoded-character vacation subaddress comparator/
/ -i;ascii-numeric relational regex imap4flags copy include
variables body enotify environment mailbox date ihave".."NOTIFY/
/ " "mailto".."SASL" "PLAIN".."STARTTLS".."VERSION" "1.0"..OK
"Dovecot ready.".. /
/##/
/T 127.0.0.1:35495 -> 127.0.0.1:4190 [AP]/
/ AUTHENTICATE "PLAIN" \{28+}.. /
/##/
/T 127.0.0.1:35495 -> 127.0.0.1:4190 [AP]/
/c3RldmUAc3RldmUAbWFnaWNsaWs=.. /
/##/
/T 127.0.0.1:4190 -> 127.0.0.1:35495 [AP]/
/ NO "Invalid characters in atom"..NO "Error in MANAGESIEVE command
received by server.".. /
/###/
I hope that someone can provide a way to get the filter management
working as I am more that happy with the way Dovecot and Squirrelmail
are working, but just want to add server-side filtering, especially
tagged mail produced by Spamassassin :)
Many thanks
Steve
Re: [Dovecot] couple of errors on new setup
On 6.10.2013, at 4.04, Noel Butler wrote: > mail_nfs_index = yes > mail_nfs_storage = yes These are never recommended. They may be a kludgy workaround to avoid worst problems, but they will never work 100% In the recommended configurations (one Dovecot server or director cluster) you won't need them.
[Dovecot] State of the FTS modules and packaging
Hi there. I'm running a small (VPS) mail system just for myself for quite a while and want to support some friends and family now. For that I'm improving / documenting the setup. One thing I never cared to implement was FTS support. Looking at the options [1] now, I'm stuck. I don't want solr (no Java bashing here, I'm sure that's working awesome. But I don't want to pull all these dependencies in on my tiny VPS: Memory and disk will be as small as I can get away with). With that out of the way: What are my options? Squat: Why's squat deprecated? Did it stop working? Can someone shed some light on the original reasons for the deprecation? What are the risks to go with squat anyway? Clucene: That seems .. unusable. It would be my prefered choice (not deprecated, little dependencies), but .. it isn't packaged in deb based distributions (Debian, Ubuntu). It doesn't even _build_, because it doesn't use pkg-config to find the clucene includes (at least for 2.1.17) in these environments. Centos is even more out of date with 2.0.9. Given the experience above, is solr my only option to offer FTS? Can you guys share how you're having a stable base/os with a somewhat recent (and complete!) dovecot package? Thanks a lot & regards, Ben 1: http://wiki2.dovecot.org/Plugins/FTS
[Dovecot] retr errors
My ISP uses Dovecot and I have had an ongoing problem for a while using several email clients. Sometimes the response to a retr request is mal-formed. The expected response "+OK nnn octets" is not returned. The response looks like it started somewhere in the message headers. Sometimes a retry can clear the problem but I usually need to delete the first message via a putty session. The problem, when present, is always on the first message. Never seen it in the middle of a series of messages. This problem has been seen on different machines, different versions of Windows, at home and on the road. I have wireshark traces showing good and bad sessions == stat +OK 93 1000437 retr 1 +OK 6946 octets Return-path: . = retr 1 of blahb...@blah.com designates 2607:f8b0:4001:c03::235 as permitted sender) smtp.mail=blahb...@blah.com; dkim=pass header.i=@blah.com Reply-To: android-develop...@googlegroups.com Precedence: list Mailing-list: .. == My ISP has been non-helpful. Any ideas how I can track down the problem? Thanks Bill
[Dovecot] Transparent Migration from cyrus to dovecot
Hi dovecot people, We are in the process of preparing the migration from a cyrus 2.1 installation to dovecot. Dovecot will be installed on new hardware, so we have separated servers that can/will exist in parallel for a while. Our goal is to do the migration without interrupting the service for our users too much. Currently we tend to using dsync. So I am asking for best practice suggestions, tips and hints from people who have done such a thing before. Curiously awaiting your replies ;) Cheers! PS: I am subscribed to the list. So no need to include my address in replies. Thanks! -- j.hofmüller Optimism doesn't alter the laws of physics. - Subcommander T'Pol signature.asc Description: OpenPGP digital signature
Re: [Dovecot] couple of errors on new setup
On 06/10/2013 03:16, Dean Guenther wrote: mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u mail_privileged_group = mail mbox_write_locks = fcntl mbox over NFS has *never* been recommended, it is unsafe - for any pop/imap type server, not just dovecot. If its not too late, and since you are testing a new server it cant be, change to Maildir, it was designed specifically for this very reason. also should use: mail_fsync = yes mail_nfs_index = yes mail_nfs_storage = yes mmap_disable = yes
