@Nuxwin
Currently I have no testing device, that is why I cannot continue testing without disturbing the apple users from one domain. Sorry
Posts by UncleSam
-
-
@Nuxwin
Yes I know that is why it is such a strange thing. That was why my first idea was that the certificate was wrong or Apple is not trusting LetsEncrypt but that was fine. I only tried to remove it from the none part as it is not in the description of rspamd. Personally I would love to have an error inside the logs because then I can see what went wrong. -
@Nuxwin
Sorry I have no logs. The only thing logged is the imap part and a successfull login if the user wants to send a mail. Nothing more.
(And a successfully logout a second after the login.) -
@Nuxwin
I do not have an Apple hardware but someone using my mail server tried to connect to the server and it was not working. I checked everything but only removing rspamd from the non_smtpd_milter was a solution which worked.I am talking about the default mail client from apple which is not able to send (only smtp). No matter if stationaire "pc" or iPhone. As I do not have such devices I cannot test this but it seems to be a problem with rspamd. If you want you can also check the rspamd page which says that smtpd_milters is all you need. As I checked it before writing this article I was confused too because this should not affect anything but as I tested it with the guy it does.
rspamd page: https://rspamd.com/doc/integration.html
-
There is a mistake in the current configuration which could prevent mail clients (e.g. Apple hardware) to connect to the server for mail sending (imap is still working).
The main issue is, that the rspamd is added at the postfix main.cf config part non_smtpd_milters. Removing it from this part is not disabling any rspamd part.The listener file can be found in /etc/imscp/listeners.d/
@Nuxwin
Can you please modify the listener you built for me and remove this part? -
Ok I have no idea what happened. Now I did the same using aptitude and it worked:
- mv /usr/bin/chattr /usr/bin/chattr2 (for security reasons)
- aptitude reinstall e2fsprogs
- /usr/bin/chattr is again available
So I am confused but happy right now.
-
Ok this is f****** me up right now (sorry for the strong words):
I tried to reinstall it using aptitude reinstall e2fsprogs which was not working (command said "reinstall complete" but chattr was still not there).
Now I thought "lets do it exactly how @Nuxwin did it" and it is back again ... so aptitude was not able to reinstall it the correct way but apt-get was ...I am using aptitude now for years and prefere it (it is the first thing I install on ubuntu systesm)...
-
@Nuxwin already tried all of them but I retried them:
- /usr/bin (and a lot of more) are in the $PATH variable
- after updating the search db I was unable to find chattr
- there is no chattr inside /usr/bin (if there is one the locate command should have found it using root user)
- I also tested if it is hidden for some reasons, but touch /usr/bin/chattr is working and creating the file
All in all I think I can survive without having chattr. I already thought to set up a virtual machine and copy the files back to my system but I think currently it is gone for some reasons.
-
-
I fixed it on my own so I do not need the patch.
For everyone having this trouble:
- switch log mount on again
- do a reconfigure (this time it should work)
- go into the panel and switch the folder protection off for all domains
- set the do not mount flag again
- reconfigure (now it should work)
- switch the folder protection on again