Sieve script will not work for main account

wila

Verified User
Joined
Dec 15, 2017
Messages
81
Hi,

Using DirectAdmin 1.54.1, roundcube - latest, dovecot 2.3.4 with pigeonhole.

For a customer of mine I made the mistake in the past to actually use the email account that comes with the main user account.

They have a bunch of additional email accounts and down there pigeonhole works fine with the vacation plugin and managesieve scripts.

On their main account however none of the sieve scripts work. For OOO emails I can still set the vacation settings in the main directadmin user interface and that works, but for additional sieve scripts, such as filtering emails and move them based on subject and from account, nothing works.

I have no idea why this is, looked at mail processing logs and nothing is jumping out to me.

Anybody has any ideas on how-to resolve this?

thanks!
 
Hello,

Emails to a main email account, i.e. system email account are delivered directly by Exim, without letting Dovecot process them. Since that sieve rules won't work for such emails. You might set /home/username/.forward file to redirect emails to a virtual email account, and it will let you to filter them with Sieve rules.
 
Thanks Alex,

So it is by design as they say. I knew that using that system email account as a normal email account was a mistake, but by the time I learned that, the customer had been using the account for a while.

The .forward rule is a good idea, but it means that it is a bit convoluted by that he then has 2 accounts, perhaps though it is the best action to take.

Another solution I was wondering about is to move all their sites and email accounts to a new user. At least then the config would be like every other account, but I don't know if that is difficult to do and how likely things are to break.
There's the move_domain.sh script, but I'm a bit hesitant on using it.

--
Wil
 
Another solution I was wondering about is to move all their sites and email accounts to a new user. At least then the config would be like every other account, but I don't know if that is difficult to do and how likely things are to break.
There's the move_domain.sh script, but I'm a bit hesitant on using it.
--Wil

You can try this:

1. create a backup of an user, let's say it's user007
2. remove account user007
3. rename backup user.admin.user007.tar.gz to user.admin.user777.tar.gz
4. restore user777
5. Update configs of sites, as MySQL DB and user renamed now.
6. Create your virtual email account.


Change user007 and user777 to match you needs.

Backups should be created and restored at admin level.
 
You can try this:

1. create a backup of an user, let's say it's user007
2. remove account user007
3. rename backup user.admin.user007.tar.gz to user.admin.user777.tar.gz
4. restore user777
5. Update configs of sites, as MySQL DB and user renamed now.
6. Create your virtual email account.


Change user007 and user777 to match you needs.

Backups should be created and restored at admin level.

Ah I thought the script took care of that.
Yes, restoring a backup should work, it certainly is the cleanest solution, but for now will try the easier one that Martynas suggested first. The alpha status of the feature is a tad scary, but DA has had an incredible record of reliability for me over the years.

I truly appreciate all the help (usually I don't have to ask as you guys answered most questions already so a search does tend to get me the answers I need)

--
Wil
 
Martynas,

I just did that, added as the very last line in the directadmin.conf this:
Code:
system_user_to_virtual_passwd=1

The restarted the directadmin service, but I'm not seeing anything happen in the file /etc/virtual/domain.com/passwd
If I'm not mistaken then the task queue would run every minute, so the "new" username should add itself there in a few minutes.
I suppose I can add the username by hand, but then I'm afraid it will break something else...

BTW, for my use case it would be nice if this feature could be "per domain" and not system wide.

Also not clear to me is if I set the setting back to false, will it remove the username again from /etc/virtual/domain.com/passwd ?
--
Wil
 
Ah I thought the script took care of that.
Yes, restoring a backup should work, it certainly is the cleanest solution


And if you still choose this method make sure to check PATHs in your cronjobs and settings, they will need to be modified as well.
 
The following command should be executed so that main users would get added there:
Code:
echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue
 
Martynas,

Ah right. I had seen those task queue notes in other documentation parts before too. It never occurred to me that it was meant to be run manually. The way I read that was that it is an implementation detail, but clearly it isn't.

So I used the other one:
Code:
echo "action=rewrite&value=email_passwd&user=fred" >> /usr/local/directadmin/data/task.queue
as I really only want this for the one user and then the new user does indeed show up in the /etc/virtual/domain.com/passwd file.

As a result I can indeed also login using "[email protected]" instead of only "user".

However the sieve filter still does not work.
I deleted the filters, recreated them, simplified them.. not working as far as I can see.

--
Wil
 
Hi,

OK, as I had to get this ticket closed, here's what I ended up doing. Note that I changed usernames to something else, but I made sure they have the same length (you'll see why)

Initially I figured to go down the backup & restore path then noticed the change_username.sh and figured that it would probably mess up less things.

For the backup/restore path I had already created a new user "abcdefgh01", so I figured to delete that user again.

Then I tried to run the change user name script:
Code:
# ./change_username.sh oomipo abcdefgh01
Killing User processes:
usermod: user oomipo is currently used by process 18346
Cannot find user abcdefgh01

Uhh what? Yes user abcdefgh01 shouldn't exist, it's the new user?? As I had just created and then deleted it, I figured to change a tiny detail and try again.

Code:
# ./change_username.sh oomipo abcdefgh02
Killing User processes:
groupmod: group 'oomipo' does not exist
swapping 'oomipo_xbxo1'@'localhost' with 'abcdefgh02_xbxo1'@'localhost'
swapping 'oomipo_p5l61'@'localhost' with 'abcdefgh02_p5l61'@'localhost'
swapping 'oomipo_absentry'@'localhost' with 'abcdefgh02_absentry'@'localhost'
Error updating 'oomipo_absentry'@'localhost' to 'abcdefgh02_absentry'@'localhost' in mysql.user: String 'abcdefgh02_absentry' is too long for user name (should be no longer than 16)

swapping 'oomipo_absusr17'@'localhost' with 'abcdefgh02_absusr17'@'localhost'
Error updating 'oomipo_absusr17'@'localhost' to 'abcdefgh02_absusr17'@'localhost' in mysql.user: String 'abcdefgh02_absusr17' is too long for user name (should be no longer than 16)

Swapping oomipo_xbxo1 to abcdefgh02_xbxo1

Dumping+restoring oomipo_xbxo1 -> abcdefgh02_xbxo1...
Database has been renamed successfully: oomipo_xbxo1 -> abcdefgh02_xbxo1
Updating mysql.db...
Swapping oomipo_p5l61 to abcdefgh02_p5l61

Dumping+restoring oomipo_p5l61 -> abcdefgh02_p5l61...
Database has been renamed successfully: oomipo_p5l61 -> abcdefgh02_p5l61
Updating mysql.db...
Swapping oomipo_abs17db to abcdefgh02_abs17db

Dumping+restoring oomipo_abs17db -> abcdefgh02_abs17db...
Database has been renamed successfully: oomipo_abs17db -> abcdefgh02_abs17db
Updating mysql.db...
Swapping oomipo_absentry to abcdefgh02_absentry

Dumping+restoring oomipo_absentry -> abcdefgh02_absentry...
Database has been renamed successfully: oomipo_absentry -> abcdefgh02_absentry
Updating mysql.db...
#

So I still have some databases with the old usernames, because they are too long. I'm not sure how bad that is. For the moment, I figured to live with it.

What did happen however was that all of my sites were down because php-fpm70 had broken.

Code:
service php-fpm70 start
cannot get gid for group 'abcdefgh02'

The php-fpm70 service was now looking for group abcdefgh02 -which did not exists- whereas all the files in the path are using group abcdefgh01 ??? Very weird, it seems to me that if you create a new user and then delete it, that it does not delete the group. What is more peculiar is that the user ended up using that group. It really does not make sense to me.

I ended up just creating the group 'abcdefgh02' and added the user to that group, after that I could restart php-fpm70 again.

With that I now had to fix the websites database and logins and things are slowly getting back to normal.
 
Back
Top