Description of problem: Defaults entry 'mail_no_user' in sudoOption does not work via LDAP or SSSD provider. Version-Release number of selected component (if applicable): tested and failed on all RHEL8 and RHEL9 How reproducible: Everytime Steps to Reproduce: 1.a) setup sudo to use ldap, using this ldap data: b) setup sudo to use sssd, using this ldap data: # my-domain.com dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organization dc: my-domain o: Test server # Groups, my-domain.com dn: ou=Groups,dc=my-domain,dc=com objectClass: top objectClass: organizationalunit ou: Groups # People, my-domain.com dn: ou=People,dc=my-domain,dc=com objectClass: top objectClass: organizationalunit ou: People # admin, People, my-domain.com dn: cn=admin,ou=People,dc=my-domain,dc=com objectClass: top objectClass: account objectClass: posixAccount cn: admin uidNumber: 11001 gidNumber: 21001 homeDirectory: /home/admin loginShell: /bin/bash uid: admin userPassword:: eA== # admin, Groups, my-domain.com dn: cn=admin,ou=Groups,dc=my-domain,dc=com gidNumber: 21001 objectClass: top objectClass: posixGroup cn: 21001 cn: admin # userallowed, People, my-domain.com dn: cn=userallowed,ou=People,dc=my-domain,dc=com objectClass: top objectClass: account objectClass: posixAccount cn: userallowed uidNumber: 10001 gidNumber: 20001 homeDirectory: /home/userallowed loginShell: /bin/bash uid: userallowed userPassword:: eA== # groupallowed, Groups, my-domain.com dn: cn=groupallowed,ou=Groups,dc=my-domain,dc=com gidNumber: 20001 objectClass: top objectClass: posixGroup cn: groupallowed # usernotallowed, People, my-domain.com dn: cn=usernotallowed,ou=People,dc=my-domain,dc=com objectClass: top objectClass: account objectClass: posixAccount cn: usernotallowed uidNumber: 10002 gidNumber: 20002 homeDirectory: /home/usernotallowed loginShell: /bin/bash uid: usernotallowed userPassword:: eA== # groupnotallowed, Groups, my-domain.com dn: cn=groupnotallowed,ou=Groups,dc=my-domain,dc=com gidNumber: 20002 objectClass: top objectClass: posixGroup cn: groupnotallowed # Sudoers, my-domain.com dn: ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: organizationalUnit ou: Sudoers # defaults, Sudoers, my-domain.com dn: cn=defaults,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: defaults sudoOption: !requiretty sudoOption: !authenticate sudoOption: mailto=emailto sudoOption: mail_no_user # rule1, Sudoers, my-domain.com dn: cn=rule1,ou=Sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole cn: rule1 sudoUser: userallowed sudoHost: ALL sudoCommand: ALL 2. use sudo with an unauthorized user to send the email to the recipient: $ su - usernotallowed -c 'sudo true' 3. check if the recipient emailto received the email Actual results: Email was not sent to emailto: Mail queue is empty Expected results: Email was sent to emailto: ... Aug 31 04:44:31 nbubakov-1mt-rhel-8-7-0-20220829-1-49326-2022-08-31-08-24 postfix/smtp[32416]: 872D62400230: to=<emailto>, relay=none, delay=0.32, delays=0.29/0/0.02/0, dsn=4.4.1, status=deferred (connect to mx.domain.com[66.96.140.72]:25: Connection refused) -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 872D62400230 699 Wed Aug 31 04:44:31 usernotallowed.upshift.rdu2.redhat.com (connect to mx.domain.com[66.96.140.72]:25: Connection refused) emailto Additional info: There is no problem with sending an email when writing the sudo default options directly into sudoers file; and/or when there is used any other option (e.g. 'mail_always') with LDAP or SSSD.