Aliases file stop working
Hi!
I had migrated my sendmail aliases to the aliases file in sendmail 5.0. And all works fine for a long time
Suddenly the server began to return error messages with the all the alias addresses.
Recipient address: +alias@ims-ms-daemon
Original address: alias@mydomain
Reason: Invalid user
I runimsimta cnbuild and thenimsimta restart dispatcher and the same problem.
I tried with a new aliases file with few aliases but it didn't work.
The commandimsimta test -rewrite -debug shows me that the server was not able to find a match of the alias in the alias database neither the system alias file and expand the adress alias@mydomain as +alias@mydomain
After several dirsync's operations, restart-msg and reboot's of my server. I noticed that the owner of the aliases file was root when in a new installation the owner is the owner of the Messaging server's process. So I changed permission, group and owner to the file. I send a message to a alias and it works!!! I was almost happy when I noticed in the log that all the messages to the normal accounts was being queued with the following message:
unknown or illegal alias
So I executeddirsync -F to refresh the aliasdb and again the alias defined in aliases file didn't work.
I really appreciate some kind of help because right now I don't understand what happened with my server if it was working fine with aliases.
Thanks in advance for all your help.
Ana Cecilia Padilla
[1596 byte] By [
706831] at [2007-11-25 8:06:19]
I'm confused by your post. You mention migrating your aliases file from sendmail to sendmail 5.0. I've no idea what you mean by this.
The MTA from sendmail.org uses /etc/aliases. iMS does _not_ use this file. iMS uses msg-<instance>/imta/config/aliases. That is only one place where iMS can get address information from, but never from /etc/aliases.
Trying to run the MTA from sendmail.org on the same machine as iMS is asking for trouble. Pick one or the other, not both.
You should _not_ have to play with permissions on the iMTA aliases file unless of course you've changed it from the default value.Here are the values from my iMS 5.1 system.
-rwxr-x1 mailsrv igroup765 Jun 19 12:00 imta/config/aliases
NOTE -- The format of the two aliases files I mention above are _not_ the same.
Please also include in your post(s) the full version output information, for example:
bash-2.03# ./imsimta version
iPlanet Messaging Server 5.1 (built Jan 30 2002)
libimta.so 5.1 (built 09:19:15, Jan 30 2002)
SunOS peppy 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-5_10
In iMS addresses contained in msg-*/imta/config/aliases will supercede those contained in the resulting database files created when you ran dirsync, or in the case of iMS 5.2 and direct LDAP mode.
Note -- If you really are talking about iMS 5.0 or iMS 5.1, then I strongly suggest you look at iMS 5.2.
Thanks Chad. Sorry for the inconvenience I'll try to explain better, english isn't my native language. :)
1. This is the version of my server:
iPlanet Messaging Server 5.1 (built May 7 2001)
libimta.so 5.1 (built 23:43:53, May 7 2001)
SunOS buzon 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-880
> I'm confused by your post. You mention migrating
> your aliases file from sendmail to sendmail 5.0.
> I've no idea what you mean by this.
2. In our past e-mail implementation, we were using /etc/aliases and we had there some mail lists. We rewrite them in the format used by msg-<instance>/imta/config/aliases when we received the product and all worked fine.
list@mydomain.com: user1,user2,user3
We don't have problems with the aliases the first time we did it. The only strange thing that happen with my server was that I have to increase maxjobs in one of the channels because the server was not dequeuing the messages until I executed imsimta refresh. That happened 2 weeks ago.
>
> The MTA from sendmail.org uses /etc/aliases. iMS
> does _not_ use this file. iMS uses
> msg-<instance>/imta/config/aliases. That is only one
> place where iMS can get address information from, but
> never from /etc/aliases.
>
> Trying to run the MTA from sendmail.org on the same
> machine as iMS is asking for trouble. Pick one or
> the other, not both.
We are not working with sendmail or /etc/aliases anymore.
>
> You should _not_ have to play with permissions on the
> iMTA aliases file unless of course you've changed it
> from the default value.Here are the values from my
> iMS 5.1 system.
>
> -rwxr-x1 mailsrv igroup765 Jun 19 12:00
> imta/config/aliases
>
Maybe someone edit the file as root and change the permissions of the file. I noticed that so I change owner, group and permissions in the same way you tell me and it works but the aliasdb lost user information (not alias) so I executed dirsync -F so I could repopulated aliasdb but again I couldn't read aliases defined in msg-<instance>/imta/config/aliases
>
>
> In iMS addresses contained in
> msg-*/imta/config/aliases will supercede those
> contained in the resulting database files created
> when you ran dirsync, or in the case of iMS 5.2 and
> direct LDAP mode.
>
Yes, I noticed that. Let me show you this:
# imsimta test -rewrite -debug newalias@mydomain.com
10:08:43.27:Variant #1 = newalias@mydomain.mx
10:08:43.27:Variant #2 = *@mydomain.mx
10:08:43.27:Checking for newalias@mydomain.mx in the personal alias database
10:08:43.27:- not found
10:08:43.27:Checking for *@mydomain.mx in the personal alias database
10:08:43.27:- not found
10:08:43.27:Checking for newalias@mydomain.mx in the system alias database
10:08:43.27:- not found
HERE IS WHERE IS SUPPOSED THAT iMS SHOULD MATCH THE ALIAS BECAUSE I CHECKED IT WITH ANOTHER SERVER
10:08:43.27:Checking for *@mydomain.mx in the system alias database
10:08:43.27:- system alias database match for *@mydomain.mx (status: 40000000)
10:08:43.27:- +newalias@ims-ms-daemon
AND HERE THE iMS IS DEFINING THE INCORRECT EXPANSION.
-
As you could see, iMS is not able to read the imta/config/aliases file so it sounds like a permission problem.
I fixed the permission in the file, executed imsimta cnbuild and works!
But it seems that aliasdb lost information and I have to executed dirsync -F
After that again, I couldn't read again the aliases contained in imta/config aliases file.
Maybe there's another file involved that has wrong permissions?
Thanks for your answer.
The aliases were working fine. Now I have to use mailalternate addrees to define the lists but it's hard to mantain.
The strange
Here is the order in which things are checked,
12:39:35.74:Checking for alert@amotken.com in the personal alias database
12:39:35.74:- not found
12:39:35.74:Checking for *@amotken.com in the personal alias database
12:39:35.74:- not found
12:39:35.74:Checking for alert@amotken.com in the system alias database
12:39:35.74:- not found
12:39:35.74:Checking for *@amotken.com in the system alias database
12:39:35.74:- not found
12:39:35.74:Checking for alert@amotken.com in the system alias file
12:39:35.74:- system alias file match for alert@amotken.com
As you can see a match for alert@amotken.com is not found until the system alias file, this is the last resort. This is a good thing as I've not defined that address anywhere but in that file. :)
If a match had been found in say the "system alias database" (imta/db/aliasesdb.db) then the match process would stop and not have gone on to the system alias file.
As it happens this example I use here is a list, where I want to send important events. For example my cell phone is included in this list.
I can run ./imsimta dirsync -F and still have this "list" work.Any form of dirsync does not touch the system alias file, while dirsync is responsible for the system alias database.
Here are the permissions of my db's.
drwxr-x9 mailsrv igroup512 Jan 29 2002 ..
-rw-r--r--1 mailsrv igroup16384 Aug 19 02:00 aliasesdb.db
-rw-r--r--1 mailsrv igroup16384 Aug 19 02:00 domaindb.db
-rw-r--r--1 mailsrv igroup32768 Aug 16 18:27 generaldb.db
-rw-r--r--1 mailsrv igroup16384 Aug 19 12:37 profiledb.db
-rw-r--r--1 mailsrv igroup16384 Aug 19 02:00 reversedb.db
-rw-r--r--1 mailsrv igroup16384 Aug 19 02:00 ssrdb.db
I'm not convinced it is a permissions thing. Rather I think something in your LDAP environment might be over riding what you have defined in the system alias file (imta/config/aliases) and thus confusing you.
You can try using a command like
./imsimta test -rewrite -debug <addr-to-check>
In the output you should see just where the MTA has found a match, either from the system alias database or system alias file. I suspect the database after you've run a dirsync -F and if you were to remove the aliasesdb.db file then from the imta/config/aliases file itself.
btw -- you might want to contact TS and get the latest hotfix bundle. I'm not running it either but I really should be. I applied 09 but it introduced a new bug that annoyed me so I backed out. They have since fixed the new bug in a new bundle (I think we're at 11) but I've been lazy and not taken the time to download / apply it.
Don't forget that things in LDAP can be shared between multiple iMS MTAs while the contents of the system alias file are unique to each machine. That is if you wanted to define things in the system alias file _and_ have them the same across multiple machines then you'll have to write a process to keep the files in sync.
Thanks Chad your comment is correct. It's not a permission problem.
I verified line per line the exit of the command imsimta test -rewrite -debug <alias-address> against a system where alias are working and I noticed this:
16:09:37.06:Address alias@mydomain.mx requires local processing.
16:09:37.06:Variant #1 = alias@mydomain.mx
16:09:37.06:Variant #2 = *@mydomain.mx
16:09:37.06:Checking for alias@mydomain.mx in the personal alias database
16:09:37.06:- not found
16:09:37.06:Checking for *@mydomain.mx in the personal alias database
16:09:37.06:- not found
16:09:37.06:Checking for alias@mydomain.mx in the system alias database
16:09:37.06:- not found
16:09:37.06:Checking for *@mydomain.mx in the system alias database
16:09:37.06:- system alias database match for *@mydomain.mx (status: 40000000)
16:09:37.06:- +alias@ims-ms-daemon
16:09:37.06:Parsing address +mydomain@ims-ms-daemon
So it's correct what you said. It's not checking the aliases file.
>
> If a match had been found in say the "system alias
> database" (imta/db/aliasesdb.db) then the match
> process would stop and not have gone on to the system
> alias file.
I run imsimta crdb -dump IMTA_ALIAS_DATABASE and I found this entry:
!!imta crdb -quoted -remove IMTA_ALIAS_DATABASE
"*@mydomain.mx" +*@ims-ms-daemon"a100200@mydomain.mx" a100200+*@ims-ms-daemon
"a100388@mydomain.mx" a100388+*@ims-ms-daemon
I made again a comparation againsts the server where alias are working and the entry *@mydomain.mx doesn't exist.
May I ask you the following questions?
Can I delete this entry in the file and use it for creating again the aliases db without any problem?
The procedure I know is:
imsimta crdb aliases-new aliases-tmp
imsimta renamedb aliases-tmp IMTA_ALIAS_DATABASE
Which type of entry in my directory server could generate the entry *@mydomain.mx in the aliases file? I
I'm asking this issues because the past week when I was trying to solve the problem I used the imsimta crdb command and I think that it was the reason why the aliases file work but it didn't repopulate the aliasdb completely. When I uses dirsync -F, again it add the entry *@mydomain.com and the aliases file stop working.
Thanks for your comments they where really helpful for understand the process.
If you simply want to view the contents of say IMTA_ALIAS_DATABASE, then all you need to do is
./imsimta dumpdb IMTA_ALIAS_DATABASE
and the contents will dump to your screen. You could also specify a filename as the last parameter and it will dump to that file or you could do say
./imsimta dumpdb IMTA_ALIAS_DATABASE |grep xyz-user > to.some.file
As for changing this file, bad idea! You are using 5.1 so having dirsync run is important, all things being equal. I don't know your site specifics so maybe you can get away without dirsync, but most sites need it so I'm going to answer as if you do.
Assuming you are using UIDs for login, default, then
a100200 is the UID in your DIT where you need to look. If you examine a LDIF of tihs users record I bet you'll find something along the lines of
mailalternateaddress=*@mydomain.mx
Remove that entry, wait for replication, and run a full dirsync. Then check the resulting IMTA_ALIAS_DATABASE file again to be sure.
The next question you should be asking yourself is how did that entry get in there in the first place?
I worked with a very large customer recently where the provisioning system (custom written) did not prohibit their users from requesting addresses like *, feedback, info, customer-service, etc..
Needless to say users pushed and probed the system and found the weaknesses and caused a lot of wasted resources to the mail system. You should check your provisioning system to ensure that similar things can't be done.
If you really want to create the IMTA_ALIAS_DATABASE by hand, knowing that the next incremental or full dirsync will update/replace (respectively) then you can simply
./imsimta dumpd IMTA_ALIAS_DATABASE > /tmp/aliases.orig
cp /tmp/aliases.orig /tmp/aliases.custom
./imsimta crdb -quoted -remove /tmp/alises.custom /tmp/alisesdb
mv /tmp/alisesdb.db IMTA_ALIAS_DATABASE
NOTEmy use of the "mv" command is very intentional. The smtp server process is unhappy if you were to use "cp" instead, so a "mv" is required.
