Rusty Ross

Q: Postfix sacl_check

I am testing mail service on a Lion Server, and am currently seeing several entries related to sacl_check in mail.log.

 

More specifically, if I send a message to an external email address (ie:  "foo@me.com"), I see the following entries:

 

Aug  5 12:23:26 testserver postfix/smtpd[56752]: sacl_check: mbr_user_name_to_uuid(foo) failed: No such file or directory

Aug  5 12:23:26 testserver postfix/smtpd[56752]: sacl_check: mbr_user_name_to_uuid(@me.com) failed: No such file or directory

Aug  5 12:23:26 testserver postfix/smtpd[56752]: sacl_check: mbr_user_name_to_uuid(foo) failed: No such file or directory

 

Aug  5 12:23:26 testserver postfix/cleanup[56756]: sacl_check: mbr_user_name_to_uuid(foo) failed: No such file or directory

Aug  5 12:23:26 testserver postfix/cleanup[56756]: sacl_check: mbr_user_name_to_uuid(@me.com) failed: No such file or directory

 

Aug  5 12:23:27 testserver postfix/cleanup[56756]: sacl_check: mbr_user_name_to_uuid(foo) failed: No such file or directory

Aug  5 12:23:27 testserver postfix/cleanup[56756]: sacl_check: mbr_user_name_to_uuid(@me.com.com) failed: No such file or directory

 

The messages are being delivered successfully, but I don't understand these sacl_check messages from smptd and cleanup. I've not seen them in versions of OS X server prior to Lion.

 

Can anyone help?

Posted on Aug 5, 2011 9:34 AM

Close

Q: Postfix sacl_check

  • All replies
  • Helpful answers

Page 1 Next
  • by Rusty Ross,

    Rusty Ross Rusty Ross Aug 5, 2011 9:35 AM in response to Rusty Ross
    Level 2 (175 points)
    Aug 5, 2011 9:35 AM in response to Rusty Ross

    1 typo above...

     

    (@me.com.com) should actually be (@me.com)

  • by ckillian,

    ckillian ckillian Oct 6, 2011 5:13 PM in response to Rusty Ross
    Level 1 (5 points)
    Oct 6, 2011 5:13 PM in response to Rusty Ross

    Did you make any progress on this?  I see these logs all over my server. -Chip

  • by Rusty Ross,

    Rusty Ross Rusty Ross Oct 6, 2011 8:16 PM in response to ckillian
    Level 2 (175 points)
    Oct 6, 2011 8:16 PM in response to ckillian

    No, I still see this issue on multiple Lion Servers.

  • by Ian L-F,

    Ian L-F Ian L-F Dec 9, 2011 11:01 PM in response to Rusty Ross
    Level 1 (10 points)
    Dec 9, 2011 11:01 PM in response to Rusty Ross

    ANy progress?  I have a printer that scans in emails - my lion server is now giving out this error whenever it receives an email from it.

  • by Michael C M,

    Michael C M Michael C M Dec 10, 2011 12:09 AM in response to Ian L-F
    Level 2 (205 points)
    Dec 10, 2011 12:09 AM in response to Ian L-F

    Same issue here after reinstalling Lion. Was running into corrupt postgres issues every time I rebooted before the reinstall.

  • by Ian L-F,

    Ian L-F Ian L-F Dec 10, 2011 12:17 AM in response to Michael C M
    Level 1 (10 points)
    Dec 10, 2011 12:17 AM in response to Michael C M

    Just to clarify - the postgres was a different problem?

  • by Michael C M,

    Michael C M Michael C M Jan 1, 2012 11:19 PM in response to Ian L-F
    Level 2 (205 points)
    Jan 1, 2012 11:19 PM in response to Ian L-F

    Yep, postgres was another issue... and even after a new reinstall it came back after a few reboots.

  • by ckillian,

    ckillian ckillian Jan 12, 2012 9:56 PM in response to Rusty Ross
    Level 1 (5 points)
    Jan 12, 2012 9:56 PM in response to Rusty Ross

    So here's what I found in looking around today:

     

    I found what looks like the implementation of sacl_check() here [1] -- at least, there is the error message being printed.  The implementation of mbr_user_name_to_uuid() can be found in [2,3], where it returns either EINVAL, ENOENT, or EIO.  The message that the file cannot be found would correspond to ENOENT [4], which is being returned because _mbr_MapName() returned KERN_FAILURE.  For comparison, in DS-Tools, a different call to that function can be found here [5], where the error message is more helpful -- ENOENT maps to "user cannot be found", while EIO maps to not reachable.

     

    In my case, I am using a virtual_map, which I am wondering if it is messing up the sacl check, because the email addresses passed to receive errors either has a full hostname - (the MX record hostname) or has a modifier (i.e. a+b@foo.com).

     

    It seems you can test the function yourself using the command line utility dsmemberutil.  Try:

    dsmemberutil getuuid -U <user>

     

    The strings from my error messages generate an error (there is no uuid for user X), while the "correct" email addresses work.

     

    Not sure whether this is "working as intended" or not, but as we've said before - mail delivery seems to be working...

     

    [1]: http://opensource.apple.com/source/postfix/postfix-229/postfix/src/global/aod.c

    [2]: http://opensource.apple.com/source/Libinfo/Libinfo-221/membership.subproj/member ship.c

    [3]: http://opensource.apple.com/source/Libinfo/Libinfo-392/membership.subproj/member ship.c

    [4]: http://opensource.apple.com/source/gcc/gcc-926/libiberty/strerror.c

    [5]: http://www.opensource.apple.com/source/DSTools/DSTools-134/dsmbrutil/dsmbrutil.c

  • by mossm,

    mossm mossm May 23, 2012 1:48 PM in response to ckillian
    Level 1 (0 points)
    May 23, 2012 1:48 PM in response to ckillian

    Good info.  I've been checking Apple's changes to postfix from the 229.3 source. But I did find a way to get rid of the messages by turning on local debug level increase.  You then see, in addition to the sacl_checks, the rewrite checks on recipient_canonical_maps, canonical_maps, virtual_alias_maps, and virtual_mailbox_maps.  I'm only using virtual_mailbox_maps so that's where it ends.  For some reason, I had left in local_recipient_maps, and this is what causes Apple's sacl_checks.  Since I'm all virtual, i changed this to

     

    local_recipient_maps =

     

    and the sacl_check messages stopped.  Now locals aren't checked, which is what I wanted.  Plus no messages.  I do know that before this, a local OSX user was being accepted even though it wasn't in my local_recipient_maps file, though the sacl_errors showed up.  Apple is using it's Open Directory lookups to find real /Users type users, but nulling local_recipient maps seems to stop this.  Just do this and fugedabotit.

  • by mossm,

    mossm mossm May 24, 2012 1:34 PM in response to mossm
    Level 1 (0 points)
    May 24, 2012 1:34 PM in response to mossm

    I went back and re-tested.  The virtual_alias_maps is what causes the sacl_checks (and failure messages), thought it eventually gets the mail through.

  • by powercore,

    powercore powercore Dec 16, 2012 3:58 AM in response to Rusty Ross
    Level 1 (10 points)
    Dec 16, 2012 3:58 AM in response to Rusty Ross

    Hi Rusty,

     

    I've a similar problem in the past. Like already mentioned in this mail thread the "sacl_check()" try to resolve the UUID from a user (special apple implementation).

    So normally this should happen if a mail should be delivered to a local recipient (mailboxes of local users).

    There are different parameters in the /etc/postfix/main.cf to tell the service what is your local network / domain etc.. You should verify this settings.

     

    For Example:

     

    myhostname = mail.domain.tld # means the official public name (internet)
    mydomain = domain.tld # your official public internet domain name

    myorigin = apfelbox.domain.tld # IMPORTANT set your local host name
    myorigin = $mydomain
    mynetworks = 127.0.0.0/8, [::1]/128, 10.10.1.0/26, ... # IMPORTANT your local networks
    mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain # valid dns names of your mail service
    relay_domains = $mydestination, $mydomain # domains where the service is responsible

     

     

    In my case, I'did not define the "myorigin" variable, and this leads to the problem that sacl_check() was unable to resolve recipients UUID.

     

    For example:

     

    Hostname: apfelbox.domain.tld

    Official Mail MX Record (DNS Internet Name): mail.domain.tld

     

    Valid resolvable user names are (KDC / Local / OpenLDAP):

     

    - username

    - username@domain.tld

    - username@apfelbox.domain.tld

     

    Not valid usernames:

     

    - username@mail.domain.tld

     

     

    To solve this, set the "myorigin" name correctly. To verify what is valid or not for local users, user the "dsmemberutil getuuid -U <user>" command like

    already described by "ckillian".

     

    But I believe in your case, it seems that the MTA (Postfix) is unable to identify the responsibility correctly.

     

    Good luck & Regards,

    Daniel

  • by powercore,

    powercore powercore Dec 16, 2012 5:38 AM in response to powercore
    Level 1 (10 points)
    Dec 16, 2012 5:38 AM in response to powercore

    There is one more thing,

     

    if you are not using a directory service (openldap, etc.) the username resolution "hostname.domain.tld" will not be valid to receive the UUID. In that case postfix will display the sacl_check() error too.

     

    In that case, set the "$myorigin" variable to your domain.

     

    Example:

     

    myorigin = "mydomain.tld"

     

     

    This force postfix to use alway the full domain only in the internal delivery process. This should solve the

    seen problem with sacl_check(). But please verify that the basic settings (like in my last post above) are valid and available.

     

    Regards,

    Daniel

  • by Gerben Wierda,

    Gerben Wierda Gerben Wierda Apr 6, 2013 3:28 AM in response to powercore
    Level 1 (144 points)
    Mac OS X
    Apr 6, 2013 3:28 AM in response to powercore

    Removed because it contained a nasty error. I'll be back when I know all about it.

  • by Gerben Wierda,

    Gerben Wierda Gerben Wierda Apr 6, 2013 4:16 AM in response to Gerben Wierda
    Level 1 (144 points)
    Mac OS X
    Apr 6, 2013 4:16 AM in response to Gerben Wierda

    Thanks to those for giving the info above. It helped me find out what was going on. To add a bit to general knowledge on what I understand about postfix and mail adresses/users:

     

    Postfix uses at certain stages the $myorigin variable to add to addresses that have no @domain part attached. [1]. If you run a postfix server on a ML Server, that will normally work, because the default value for $myorigin is $myhostname and that $myhostname is normally where your network users (and local users) live (at least when you follow the default setup by Apple)

     

    But if you have configured postfix to use an alias when talking to the outside world, e.g. (default pattern by Apple Server.app setup)

     

    Your domain is server.foo.com

    Your server is called server.foo.com

     

    But your server uses an alias mail.foo.com ($myhostname) when talking to the outside world. As a result a name like bar will become bar@mail.foo.com inside postfix at certain points.

     

    You server, however can only recognize the name without the @domain part or with the name of the server, so, for user bar, your server server.foo.com recognizes

     

    bar

    bar@server.foo.com

     

    but it does not recognize

     

    bar@mail.foo.com

     

    and that leads to the sacl_check() error. (check with "dsmemberutil getuuid -U <user>") as explained by ckillian above

     

    When you empty $local_alias_maps, you in fact tell postfix it should not check if a local user exists at all, as this will be done downstream. That works to prevent the sasl_check() error, but it also stops postfix from filtering a lot of mail (spam) that is directed at non-existing users.

     

    So, the only true solution for the local part (I haven't looked into anything with aliases that translate to an external address yet) seems to be to set $myorigin to the hostname of the server (but beware!, see below)

    sudo serveradmin settings mail:postfix:myorigin = server.foo.com

     

    Note: if you set up ML Server and you choose a domain name, this becomes both the name of the machine and the name of the domain. E.g.

     

    Your domain is server.foo.com

    Your server is called server.foo.com

     

    I prefer to have those separated, so I have set up my domain as foo.com. That means that after ML setup is complete I need to change the machine name to server.foo.com. That effects the validity of your setup, so you have to run the following command after having done the basic setup:

    sudo changeip 192.168.x.x 192.168.x.x foo.com server.foo.com

    Where 192.168.x.x should be replaced by the IP address of your server (a local address, assuming your server is behind a NAT router). That leads to:

     

    Your domain is foo.com (also in DNS, you cover all of the foo.com domain in your own DNS)

    Your server is called server.foo.com

     

    That means that in using $mydomain for $myorigin does not work anymore, because the server does not recognize bar@foo.com, it only recognizes bar and bar@server.foo.com. So, you set the $myorigin to server.foo.com.

     

    BUT THERE IS A NASTY CATCH: if bar is rewritten to bar@server.foo.com, postfix does not know yet that server.foo.com is a local destination. So, it happily sends the mail for bar@server.foo.com to your outside relay (if you're lucky to have one) or to your own mail server creating and endless loop (if your luck runs out). The solution is to add $myorigin to $mydestinations.

     

    serveradmin won't let you change $mydestinations. Even with a simple argument it crashes:

    $ sudo serveradmin settings mail:postfix:mydestination = 'localhost'

    2013-04-06 12:50:47.913 serveradmin[22575:707] -[__NSCFString objectEnumerator]: unrecognized selector sent to instance 0x7fb92a41e3b0

    2013-04-06 12:50:47.914 serveradmin[22575:707] Exception in doCommand for module servermgr_mail on thread 0x7fb92a40c700: -[__NSCFString objectEnumerator]: unrecognized selector sent to instance 0x7fb92a41e3b0

    (seems a bug) so you need to edit /Library/Server/Mail/Config/postfix/main.cf by hand and make sure $myorigin is added to $mydestinations.

     

    [1] If you use canonical names, e.g. user jonsmith inside becomes Jon.Smith@foo.com on the outside you also have aliases that do the reverse Jon.Smith@foo.com becomes jonsmith. But that latter name may get $myorigin added by postfix. If your aliases al are fqdn in the form of jonsmith@server.foo.com this will not happen, but that is a bad solution (you won't catch all uses and it is hard to keep consistent).

    [2] http://www.postfix.org/LOCAL_RECIPIENT_README.html

     

    PS. I haven't tested a solution where you make $myorigin empty. It can work, but you need to have a canonical for all users, another consistency nightmare. The easiest solution would be if my Open Directory domain server.foo.com would accept mail.foo.com as an alias for password checking, uuid.

Page 1 Next