October 2022 - dovecot

"make check" fail at test_program_refused
by A. Schulze 14 Oct '22

14 Oct '22

Hello, I moved my buildsystem to an other platform (I do not fully control) and now receive this error on "make check" Error: program tcp:127.0.0.2:42027: connect(::1) failed: Connection refused test_program_refused ................................................. : FAILED The build run on jenkins buildnodex spawn up on a kubernetes cluster. What I noticed so far: the buildnode opereate ipv4 only but has an entry in /etc/hosts: 127.0.0.1 c4a84c76f0d6 ::1 c4a84c76f0d6 Maybe that's the glitch ... I tried dovecot-2.3.15 and 2.3.19.1. Both fail (only the portnumber differ) Is there an option to disable only one specific test? I dislike to skip "make check" at all. Andreas

1 1

what are the options to 'interact' with a dovecot imap user
by Marc 14 Oct '22

14 Oct '22

I am looking for a user friendly way to have a user to tell the 'server' to either store or remove an email address. a. My first thought was to use imapsieve for this and have an imap sieve plugin store/remove the email address of the message that is being dragged into a predefined monitored folder. This would work with any imap client b. I was thinking about the message Flagged[1]. I am curious how would I be able to detect this (in sieve)? This does not seem to be stored in the source of the message. Although every client seems to support it, it would probably conflict with every day use cases. c. Then you have these colours and/or categories. But these do not seem to propagate across clients. Where are these even stored? Any ideas on how this can be done? [1] https://www.rfc-editor.org/rfc/rfc3501#section-2.3.2

1 0

Director hashing
by Dan Conway 14 Oct '22

14 Oct '22

Hello all, I have a 2 node director setup that uses checkpassword for authentication as well as backend assignment through director tags. director_servers = 192.168.1.10 192.168.1.20 director_mail_servers = 192.168.2.10@srv1 192.168.2.11@srv2 checkpassword writes the following to Dovecot on successful authentication: proxy=y\tdirector_tag=<tag>\tport=<port>ssl=yes\tdestuser=<email>\t This seems to work just fine. However, when I attempt to view a users current hash/initial config: # doveadm director status "user(a)domain.com" Current: n/a (expires -1) Hashed: Initial config: I get null data. There does appear to be a hash mapping of some sort however: # doveadm director map -u user(a)domain.com 1140334690 # doveadm director map -h 1140334690 user(a)domain.com The use of doveadm director move has no effect. doveadm reports it moved the user, but it does not: # doveadm -v director move "user(a)domain.com" 192.168.2.11 Info: User hash 1140334690 moved to 192.168.2.11 When using checkpassword and supplying fields to Dovecot, should I also be including another field to populate hashes for director? I could be missing something obvious in the docs. I'm on version 2.3.18 (9dd8408c18). I have not included dovecot.conf due to the size. If someone needs to see it I can supply it.

1 0

Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni
by Paul Kudla (SCOM.CA Internet Services Inc.) 12 Oct '22

12 Oct '22

Good morning to all i guess things have changed yet again to keep this simple : i buy a certificate (example) : mail.paulkudla.net i generated the key / csr as per normal using data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out /tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' %(country,state,location,organization,self.domain) please note the above is done in django (yes i am running thunderbird v102) i go buy the certificate i database the CRT & CA CSR is : -----BEGIN CERTIFICATE REQUEST----- MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN 15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4 VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9 7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk 9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5 yq88NESoIYaO6Do= -----END CERTIFICATE REQUEST----- CRT is : -----BEGIN CERTIFICATE----- MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u AAABgWzEkYoAAAQDAEcwRQIgOYjevKp5RI+c0JhIi6JflaxiNokRTSeXN6LrdIVt Cf8CIQCG+aLreYVV8xCPV0skr0ats5zMf5PLPN2y8EIxGPPNVTANBgkqhkiG9w0B AQsFAAOCAQEAJX544qDTgkGGLUOher7tH7yUgEhQFYkBDAirO37MXrhtuzH6pGSp XfYVNB9e2ydprfmLDh8O8oTaXpaQfp/jwK3U0GfvG57MfdQTLOunpWnCjaMUPUcv jPU90/mXc5oWlO5iJ6jPDkS/x47K03P6vftSr7AMwnLq4kYwuG9fHLslMHhoojen 9S2G1QjKVp5jkFecmQib+JOZV9Ub9r6iumHICfdcSO+tyBL2IDqWDQhuAVUXgyOV 11O9ZgikoeRhgsMhwiQA1z/Fs6Xqx/XCs6nUciebRiQuuHYm/PUG2H+tg0sLhJ6L ntIEhjjkumL0oJEfDidP/8wmrsPuwfSDCQ== -----END CERTIFICATE----- CA (INTER) : -----BEGIN CERTIFICATE----- MIIGEzCCA/ugAwIBAgIQfVtRJrR2uhHbdBYLvFMNpzANBgkqhkiG9w0BAQwFADCB iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgx MTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBjzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UE ChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5TZWN0aWdvIFJTQSBEb21haW4g VmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA1nMz1tc8INAA0hdFuNY+B6I/x0HuMjDJsGz99J/LEpgPLT+N TQEMgg8Xf2Iu6bhIefsWg06t1zIlk7cHv7lQP6lMw0Aq6Tn/2YHKHxYyQdqAJrkj eocgHuP/IJo8lURvh3UGkEC0MpMWCRAIIz7S3YcPb11RFGoKacVPAXJpz9OTTG0E oKMbgn6xmrntxZ7FN3ifmgg0+1YuWMQJDgZkW7w33PGfKGioVrCSo1yfu4iYCBsk Haswha6vsC6eep3BwEIc4gLw6uBK0u+QDrTBQBbwb4VCSmT3pDCg/r8uoydajotY uK3DGReEY+1vVv2Dy2A0xHS+5p3b4eTlygxfFQIDAQABo4IBbjCCAWowHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFI2MXsRUrYrhd+mb +ZsF4bgBjWHhMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAbBgNVHSAEFDASMAYGBFUdIAAw CAYGZ4EMAQIBMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2Bggr BgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDov L29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAMr9hvQ5Iw0/H ukdN+Jx4GQHcEx2Ab/zDcLRSmjEzmldS+zGea6TvVKqJjUAXaPgREHzSyrHxVYbH 7rM2kYb2OVG/Rr8PoLq0935JxCo2F57kaDl6r5ROVm+yezu/Coa9zcV3HAO4OLGi H19+24rcRki2aArPsrW04jTkZ6k4Zgle0rj8nSg6F0AnwnJOKf0hPHzPE/uWLMUx RP0T7dWbqWlod3zu4f+k+TY4CFM5ooQ0nBnzvg6s1SQ36yOoeNDT5++SR2RiOSLv xvcRviKFxmZEJCaOEDKNyJOuB56DPi/Z+fVGjmO+wea03KbNIaiGCpXZLoUmGv38 sbZXQm2V0TP2ORQGgkE49Y9Y3IBbpNV9lXj9p5v//cWoaasm56ekBYdbqbe4oyAL l6lFhd2zi+WJN44pDfwGF/Y4QA5C5BIG+3vzxhFoYt/jmPQT2BVPi7Fp2RBgvGQq 6jG35LWjOhSbJuMLe/0CjraZwTiXWTb2qHSihrZe68Zk6s+go/lunrotEbaGmAhY LcmsJWTyXnW0OMGuf1pGg+pRyrbxmRE1a6Vqe8YAsOf4vmSyrcjC8azjUeqkk+B5 yOGBQMkKW+ESPMFgKuOXwIlCypTPRpgSabuY0MLTDXJLR27lk8QyKGOHQ+SwMj4K 00u/I5sUKUErmgQfky3xxzlIPK1aEn8= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgTCCBGmgAwIBAgIQOXJEOvkit1HX02wQ3TE1lTANBgkqhkiG9w0BAQwFADB7 MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE AwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTE5MDMxMjAwMDAwMFoXDTI4 MTIzMTIzNTk1OVowgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5 MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sI s9CsVw127c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnG vDoZtF+mvX2do2NCtnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQ Ijy8/hPwhxR79uQfjtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfb IWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0 tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97E xwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNV icQNwZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5 D9kCnusSTJV882sFqV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJ WBp/kjbmUZIO8yZ9HE0XvMnsQybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ 5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzG KAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaOB8jCB7zAfBgNVHSMEGDAWgBSg EQojPpbxB+zirynvgqV/0DCktDAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rID ZsswDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAG BgRVHSAAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t L0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUA A4IBAQAYh1HcdCE9nIrgJ7cz0C7M7PDmy14R3iJvm3WOnnL+5Nb+qh+cli3vA0p+ rvSNb3I8QzvAP+u431yqqcau8vzY7qN7Q/aGNnwU4M309z/+3ri0ivCRlv79Q2R+ /czSAaF9ffgZGclCKxO/WIu6pKJmBHaIkU4MiRTOok3JMrO66BQavHHxW/BBC5gA CiIDEOUMsfnNkjcZ7Tvx5Dq2+UUTJnWvu6rvP3t3O9LEApE9GQDTF1w52z97GA1F zZOFli9d31kWTz9RvdVFGD/tSo7oBmF0Ixa1DVBzJ0RHfxBdiSprhTEUxOipakyA vGp4z7h/jnZymQyd/teRCBaho1+V -----END CERTIFICATE----- sni.conf : local_name mail.paulkudla.net { ssl_key = /programs/common/getssl.cert -c mail.paulkudla.net -q yes ssl_cert = /programs/common/getssl.cert -c mail.paulkudla.net -q yes ssl_ca = /programs/common/getssl.cert -c mail.paulkudla.net -q yes } please note getssl.cert above is a program that returns the keys from the database - worked perfectly fine before. basically what do i have to add to what file (csr, cert, ca) to get the sni to work again for mail.paulkudla.net so based on the mail lists So in you example a valid .csr now contains: CN = example.com SAN.1 = example.com SAN.2 = www.example.com etc. Of course you could also have: CN = www.example.com SAN.1 = www.example.com SAN.2 = example.com what do i modify (and how) ???? the above says to modify the csr ? please keep in mind that the cert purchased is only for the name : mail.paulkudla.net thus i fail to see why it is throwing error 42, however this seems to be a patch to thunderbird as well i did not have to change the servers base ssl stuff (*.scom.ca) so that is still working or will that need to be updated as well eventually postfix is perfectly fine ????? Note from sni.conf (ssl config file) - aka *.scom.ca is ok ?? : ssl = yes verbose_ssl = yes ssl_dh =</usr/local/etc/dovecot/dh-4096.pem ssl_prefer_server_ciphers = yes #ssl_min_protocol = TLSv1.2 #Default *.scom.ca ssl_key =</usr/local/etc/dovecot/scom.pem ssl_cert =</usr/local/etc/dovecot/scom.pem ssl_ca =</usr/local/etc/dovecot/scom.pem -- Happy Tuesday !!! Thanks - paul Paul Kudla Scom.ca Internet Services <http://www.scom.ca> 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3 Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul(a)scom.ca

3 6

One-off backup
by Ian Evans 11 Oct '22

11 Oct '22

I run a small email server for me and the missus. Six dovecot users. Our host is migrating our server instance. They usually (99.9999% lol) go off without a hitch. As we don't have dovecot running elsewhere, I'm assuming doveadm is the wrong tool. If we want to make a one-off backup prior to the migration, is shutting down postfix and running tar czf mailstorage.tgz /path/to/mail okay? Thanks.

8 9

grabbing multiple patterns from allof
by Marc 11 Oct '22

11 Oct '22

Anyone an idea how you should grab multiple matches from allof? if allof ( true, header :regex "Subject" "(test).*(test2)", envelope :matches "from" "*" )

2 1

Static build problems
by Jacob Welsh 09 Oct '22

09 Oct '22

I'm attempting to build the latest Dovecot, version 2.3.19.1, on Gales Linux, a distribution based on musl libc with all static linking. After working around some expected troubles to generate configure, such as the libtool and iconv.m4 dependencies, the build appeared to complete successfully. But on closer inspection, the plugins were installed as a bunch of .a and .la files rather than getting linked into any of the binaries, as would be necessary to actually use them. I determined that the probe for dynamic module support (DOVECOT_MODULES defined in 'm4/modules.m4') had returned a false positive: in the static configuration musl includes a stub dlopen() that always returns failure at runtime, so a compile-and-link-only test is not predictive. Libtool itself is affected in the same way, but it comes with the --disable-shared option which usually makes things works fine. Short of a proper solution (perhaps removing modules.m4 and going instead by what libtool already determined, since you've decided to depend on it anyway), I stubbed out modules.m4 to simply return the correct result for this platform, thus: AC_DEFUN([DOVECOT_MODULES], [ have_modules=no AC_SUBST(MODULE_LIBS) AC_SUBST(DLLIB) ]) Now the build is failing due to the absence of a function that's defined only when HAVE_MODULES is true: libtool: link: gcc -I../../src/lib -I../../src/lib-test -I../../src/lib-ssl-iostream -DDCRYPT_MODULE_DIR=\"/gales/pkg/dovecot-0.0-2.3.19.1/lib/dovecot\" -DDCRYPT_SRC_DIR=\"../../src/lib-dcrypt\" -std=gnu99 -g -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -Wl,--whole-archive -Wl,../lib-ssl-iostream/.libs/libssl_iostream.a -Wl,--no-whole-archive -o test-stream test_stream-dcrypt.o test_stream-istream-decrypt.o test_stream-ostream-encrypt.o test_stream-test-stream.o ../lib-ssl-iostream/.libs/libssl_iostream.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a test_crypto-dcrypt.o: In function `dcrypt_initialize': /home/user/gales-linux/gports/dovecot/build/dovecot-2.3.19.1/src/lib-dcrypt/dcrypt.c:34: undefined reference to `module_dir_try_load_missing' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:664: test-crypto] Error 1 I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, "Fixed compiling without module support", and clearly it's supposed to work since the #ifdefs are there, but I begin to suspect that nobody's actually tested this branch of the configuration tree recently. Further, looking through the automakefiles I'm not finding how the plugin libraries are supposed to work at all in this case and I begin to fear that they simply... aren't. Say it ain't so? Jacob

2 3

rspamd results
by Benny Pedersen 09 Oct '22

09 Oct '22

Results for file: 2 (0.0633 seconds) [Metric: default] Action: add header Spam: true Score: 3.99 / 30.00 Symbol: ARC_REJECT (1.00)[signature check failed: fail, {[1] = sig:dovecot.org:reject}] Symbol: DKIM_TRACE (0.00)[junc.eu:-] Symbol: DMARC_POLICY_SOFTFAIL (0.10)[junc.eu : No valid SPF, none] Symbol: FROM_HAS_DN (0.00) Symbol: FROM_NEQ_ENVFROM (0.00)[me(a)junc.eu, dovecot-bounces(a)dovecot.org] Symbol: HAS_LIST_UNSUB (-0.01) Symbol: HAS_ORG_HEADER (0.00) Symbol: HFILTER_HOSTNAME_UNKNOWN (2.50) Symbol: MAILLIST (-0.20)[mailman] Symbol: MID_RHS_MATCH_FROM (0.00) Symbol: MIME_GOOD (-0.10)[text/plain] Symbol: MIME_TRACE (0.00)[0:+] Symbol: RCPT_COUNT_ONE (0.00)[1] Symbol: RCVD_COUNT_SEVEN (0.00)[7] Symbol: RCVD_IN_DNSWL_MED (-0.40)[172.104.150.56:received, 94.237.105.223:received] Symbol: RCVD_NO_TLS_LAST (0.10) Symbol: RCVD_VIA_SMTP_AUTH (0.00) Symbol: R_DKIM_REJECT (1.00)[junc.eu:s=default] Symbol: TO_DN_NONE (0.00) Message-ID: 38f38a585892368901bd47944ca617ab(a)junc.eu just to be sure its not a fail in spamassassin with dkim_invalid ARC-Authentication-Results: i=1; talvi.dovecot.org; dkim=pass header.d=junc.eu header.s=default header.b=rodgOLEw; spf=pass (talvi.dovecot.org: domain of me(a)junc.eu designates 172.104.150.56 as permitted sender) smtp.mailfrom=me(a)junc.eu; dmarc=pass (policy=none) header.from=junc.eu where is the problem ? i will report fuglu dkim signing non existing headers in a moment if that my fault cc: is non existing here but are still signed, why did ARC verify not find this problem ?

1 0

imapsieve removeflag ignored
by Slavko 08 Oct '22

08 Oct '22

Hi, i have working SPAM reporting implementend by imapsieve in debian's 2.3.13 dovecot. Recently i decide to add personal spam filter by bogofilter and use logic to learn/unlearn SPAM/HAM based on message flags. Here is example of moving message from Junk folder (the opossite logic is similar): if hasflag "$Junk" { execute :pipe "bogofilter" ["-Sn"]; removeflag "$Junk"; debug_log "Learned HAM (and unlearned)"; } else { execute :pipe "bogofilter" ["-n"]; debug_log "Learned HAM (only)"; } # mark as learned addflag "$NotJunk"; report ... When i move message, the debug lines in log shows, that logic works and flag is added as expected, but the other flag is not removed. Thus after moving mail from Junk, which has $Junk flag, it has both flags, the $Junk and $NotJunk. I tried to move removeflag action outside of condition and add it just before addflag, but the result is the same. For now i do not know if here is something wrong in my script, or i did some other mistake. On IRC cmouse tell, that removeflag was fixed in some early version (2.3.5 or so), but it doesn't work here. Please, how i can get it working? regards PS: please CC me, i am not subscribed -- Slavko https://www.slavino.sk/

2 2

oauth2 passdb user authentication with PLAIN
by Simon 05 Oct '22

05 Oct '22

2 2