Repository: Mailu/Mailu

Issue:
Mailu 1.7 : Issue when moving mail to the Junk folder
When I move a mail to the Junk Folder, i see the following in the logs:
imap_1       | Sep 22 16:51:26 imap: Error: cannot stat file mailu
imap_1       | Sep 22 16:51:26 imap: Error: cannot stat file mailu
imap_1       | Sep 22 16:51:26 imap: Error: tee: /dev/fd/63: I/O error
imap_1       | Sep 22 16:51:26 imap(xxx@yyy.net)<27629><hn93GCeTsresEgAC>: Info: program exec:/conf/bin/spam (27655): Terminated with non-zero exit code 1
imap_1       | Sep 22 16:51:26 imap(xxx@yyy.net)<27629><hn93GCeTsresEgAC>: Info: sieve: left message in mailbox 'Junk'


Discussion:
This is very probably a regression introduced when refactoring the Dovecot container and the way sieve scripts are served.
This does not seem so obvious after all. Could you tell us more about your setup, are you using the `_ADDRESS ` variables maybe?
I have migrated from 1.6, using the web config generator to help me migrate my docker-compose.yml (no swarm, nor kubernetes). The main difference is that I am not using "Resolver" in all container, only in "rspamd" one.
- /mailu is a NFS share....
- docker version is 18.06.3-ce
I also have this since upgrading:

```
imap_1_b27192e2a475 | Sep 23 17:55:28 imap-login: Info: Login: user=<xxxx@yyyy.de>, method=PLAIN, rip=172.31.0.4, lip=172.31.0.11, mpid=856, session=<FgoNIDyTCLesHwAE>
imap_1_b27192e2a475 | Sep 23 17:55:28 imap(xxxx@yyyy.de)<856><FgoNIDyTCLesHwAE>: Info: sieve: left message in mailbox 'Junk'
imap_1_b27192e2a475 | Sep 23 17:55:28 imap: Error: cannot stat file mailu
imap_1_b27192e2a475 | Sep 23 17:55:28 master: Error: waitpid() returned unknown PID 859
imap_1_b27192e2a475 | Sep 23 17:55:28 imap: Error: cannot stat file mailu
imap_1_b27192e2a475 | Sep 23 17:55:28 imap(xxxx@yyyy.de)<856><FgoNIDyTCLesHwAE>: Info: Logged out in=266 out=1729 deleted=1 expunged=1 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
imap_1_b27192e2a475 | Sep 23 17:55:28 master: Error: waitpid() returned unknown PID 860
```

If I can find some time in the following days, I’ll try to find the cause too …
Possibly a change in the rspamc utility, notably a change in the `-P` flag?
Hi,

good news: The cause is found, and simple: The `ham` and `spam` scripts in `/conf/bin` of the dovecot container don’t get the `ANTISPAM_ADDRESS` environment anymore. In `start.py`, the address is correctly discovered, and also written to `os.environ`. From the python docs:

> If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified.

I’m a bit puzzled why this suddenly stopped working, and debugging is a bit ugly because i can’t `cat /proc/?/environ` — well, i can, but only garbled binary shit comes out. That was new to me …

Now the question is: Should we also use jinja2 to safely inject the address into these scripts, without relying on the environment getting passed? That’s a bit ugly, but maybe safer / less fiddly moving forward …

… or we try to understand why the environ doesn’t get passed anymore (maybe a dovecot change, stripping environ when calling sieve-child-scripts? or something?) … and see if we can work around it in another way …


Resolving patch:
diff --git a/core/dovecot/start.py b/core/dovecot/start.py
--- a/core/dovecot/start.py
+++ b/core/dovecot/start.py
@@ -32,6 +32,12 @@ def start_podop():
 for dovecot_file in glob.glob("/conf/*.conf"):
     conf.jinja(dovecot_file, os.environ, os.path.join("/etc/dovecot", os.path.basename(dovecot_file)))
 
+os.makedirs("/conf/bin", exist_ok=True)
+for script_file in glob.glob("/conf/*.script"):
+    out_file = os.path.join("/conf/bin/", os.path.basename(script_file).replace('.script',''))
+    conf.jinja(script_file, os.environ, out_file)
+    os.chmod(out_file, 0o555)
+
 # Run Podop, then postfix
 multiprocessing.Process(target=start_podop).start()
 os.system("chown mail:mail /mail")


Test patch: