There are two differing acl schemes floating around. We are discussing the older scheme that is in use on Solaris ufs file systems. Setting an acl on a directory does not propagate to any pre-existing files under that directory. If a file is created in a directory with an acl set, that acl is not automatically applied to the file. You can't set a file's umask with a setfacl or by any other technique. Files do not have umasks, processes have umasks.

This form of acl does have a "mask" concept. It is intended to enable a non-acl aware program to be able to interact with a file that has acls. The file owner is immune from the mask and so is the "world" (or "other"). These two classes of users are clearly defined in an identical fashion whether or not you use acls. But an acl can specify various other groups and users and these folks don't make sense to a non-acl aware program. So the idea is to use this "mask" concept. For example, if a program uses the chmod() system call to remove group execute permission, execute permission is removed from the mask. This is a controversial idea, but it does make some sense... older programs can continue to run.

If you still don't understand the mask concept, just do this:
Whenever you change the permission on a non-owner user or a group with a setfacl command, specify the -r option to recompute the mask and other than that leave the mask alone.