After emerging relay-ctrl and integrating it into my qmail installation the "smtp after imap" is functioning quite well, save some annoying lines in /var/log/mail/current, which are saying something like: Jun 1 14:38:39 [imapd-ssl] relay-ctrl-allow[5592]: Warning: Could not rename '.1212323919.767255:5592' to '111.222.123.132': Operation not permitted. I am using courier-authlib-0.58 with authmodulelist="authvchkpw authpam". The problem is that I have two mail accounts on my server, and one is authenticating against authvchkpw and the other against authpam. Because the /var/spool/relay-ctrl/allow has the sticky bit set, the creation of the file /var/spool/relay-ctrl/allow/111.222.123.132 proceeds normally, with the user vpopmail as owner, but then the imap server wants to recreate this file with the local user as the owner (after authenticating second time against pam), which obviously fails because of the sticky bit. After looking at the installation instructions on http://untroubled.org/relay-ctrl/ I recommend removing the sticky bit. Reproducible: Always Steps to Reproduce:
Created attachment 155171 [details, diff] Proposed patch to remove the sticky bit from the /var/spool/relay-ctrl/allow directory
Hi, I have a same issue with netqmail. I followed the instructions in /var/qmail/control/conf-pop3d and enabled the two lines enabling the relay-ctrl (I did not enable this in smtp not pop3sd configs). Since then I cannot fetch email via POP3 on port 110. # ls -la /var/spool/relay-ctrl/allow/ total 12 drwxrwxrwt 2 root root 4096 Dec 17 01:56 . drwx------ 3 root root 4096 Dec 17 01:19 .. -rw-r--r-- 1 root root 0 Dec 17 01:19 .keep_net-mail_relay-ctrl-0 -rw-rw-rw- 1 account2 account2 14 Dec 17 01:56 $myip # root 561 1 0 01:55 ? 00:00:00 /usr/bin/svscan /service root 563 561 0 01:55 ? 00:00:00 supervise qmail-send root 564 561 0 01:55 ? 00:00:00 supervise log root 565 561 0 01:55 ? 00:00:00 supervise qmail-smtpd root 566 561 0 01:55 ? 00:00:00 supervise log root 567 561 0 01:55 ? 00:00:00 supervise qmail-qmtpd root 568 561 0 01:55 ? 00:00:00 supervise log root 569 561 0 01:55 ? 00:00:00 supervise qmail-pop3d root 570 561 0 01:55 ? 00:00:00 supervise log root 572 561 0 01:55 ? 00:00:00 supervise qmail-qmqpd root 573 561 0 01:55 ? 00:00:00 supervise log root 574 561 0 01:55 ? 00:00:00 supervise qmail-pop3sd root 575 561 0 01:55 ? 00:00:00 supervise log qmaill 576 564 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-send qmaild 577 567 0 01:55 ? 00:00:00 /usr/bin/tcpserver -p -v -t 10 -R -x /etc/tcprules.d/tcp.qmail-qmtp.cdb -c 40 -u 201 -g 200 0.0.0.0 209 /var/qmail/bin/ qmaill 578 570 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-pop3d qmails 579 563 0 01:55 ? 00:00:00 qmail-send qmaill 580 575 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-pop3sd qmaill 581 573 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-qmqpd qmaill 582 566 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-smtpd root 583 569 0 01:55 ? 00:00:00 /usr/bin/tcpserver -p -v -t 10 -x /etc/tcprules.d/tcp.qmail-pop3.cdb -c 40 0.0.0.0 pop3 /var/qmail/bin/qmail-popup fold qmaild 584 572 0 01:55 ? 00:00:00 /usr/bin/tcpserver -p -v -t 10 -R -x /etc/tcprules.d/tcp.qmail-qmqp.cdb -c 40 -u 201 -g 200 0.0.0.0 628 /var/qmail/bin/ qmaill 585 568 0 01:55 ? 00:00:00 /usr/bin/multilog t s2500000 n10 /var/log/qmail/qmail-qmtpd qmaild 587 565 0 01:55 ? 00:00:00 /usr/bin/tcpserver -p -v -t 10 -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb -c 40 -u 201 -g 200 0.0.0.0 smtp /var/qmail/bin root 600 579 0 01:55 ? 00:00:00 qmail-lspawn qmailr 601 579 0 01:55 ? 00:00:00 qmail-rspawn qmailq 602 579 0 01:55 ? 00:00:00 qmail-clean root 693 2 0 Dec12 ? 00:00:00 [scsi_eh_0] root 695 583 0 01:55 ? 00:00:00 /var/qmail/bin/qmail-popup $myserver /bin/checkpassword /usr/bin/relay-ctrl-allow /var/qmail/bin/qmail-pop3d . account1 697 695 0 01:55 ? 00:00:00 /var/qmail/bin/qmail-pop3d .maildir I have two accounts on the machine as well and indeed, the it looks this is a problem. The message one yields claims this is a warning. It should be treated as a warning I agree, but then the fix should be that pop3d would not exit on the exitcode but continue instead. This is my guess what is happening behind the scene.
I forgot to add that removing the sticky bit helps (and I do not mind neither if an evil users drops the file with my IP address nor if he/she creates the file for me). In contrary, I do my if he/she turns the machine by the latter approach into an open relay ... I just wonder whether the whole idea is secure. If one gets a local account access one can just do: echo "USER=$logname" > /var/spool/relay-ctrl/allow/$some_spammer_ip and the server will gladly turn into an open relay without knowledge of the admin. The ebuild did not tell me I could (optionally) install a cron rule which would drop the files every minute (see the installation instructions).
(In reply to Martin Mokrejš from comment #3) > I forgot to add that removing the sticky bit helps (and I do not mind > neither if an evil users drops the file with my IP address nor if he/she > creates the file for me). In contrary, I do my if he/she turns the machine > by the latter approach into an open relay ... I just wonder whether the > whole idea is secure. If one gets a local account access one can just do: > > echo "USER=$logname" > /var/spool/relay-ctrl/allow/$some_spammer_ip > > and the server will gladly turn into an open relay without knowledge of the > admin. No, this is incorrectly. /var/spool/relay-ctrl/ is 0700, which prevents traversal by a local user. $ sudo ls -lad /var/spool/relay-ctrl/{,allow} drwx------ 3 root root 4096 Nov 10 2010 /var/spool/relay-ctrl/ drwxrwxrwx 2 root root 4096 Nov 10 2010 /var/spool/relay-ctrl/allow $ touch foo /var/spool/relay-ctrl/allow/foo touch: cannot touch '/var/spool/relay-ctrl/allow/foo': Permission denied > The ebuild did not tell me I could (optionally) install a cron rule which > would drop the files every minute (see the installation instructions). Added. I changed the storage perm to 777 anyway.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f08d7f499b8b425adcd9ac6b4453e644ee03fd2 commit 4f08d7f499b8b425adcd9ac6b4453e644ee03fd2 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2020-05-31 04:39:04 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2020-05-31 04:46:51 +0000 net-mail/relay-ctrl: tweak storage permissions Closes: https://bugs.gentoo.org/224545 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> net-mail/relay-ctrl/relay-ctrl-3.1.1-r3.ebuild | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
