Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43178

“Unregistered user” warning skipping addresses under inappropriate conditions

      Security patch broke it. If configured email is not attached to a know user fails to send email with

       Not sending mail to unregistered user xxx@example.com

       turns out it wasn't what I thought but keeping open as so many people have added similar issues

          [JENKINS-43178] “Unregistered user” warning skipping addresses under inappropriate conditions

          René Scheibe added a comment -

          I am seeing the same issue since the plugin upgrade from v2.57 to v2.57.1.

          Scenario: User "xxx" is registered on the Jenkins instance with email "xxx@example.com".

          Log contains: "Not sending mail to unregistered user xxx@example.com"

          René Scheibe added a comment - I am seeing the same issue since the plugin upgrade from v2.57 to v2.57.1. Scenario: User "xxx" is registered on the Jenkins instance with email "xxx@example.com". Log contains: "Not sending mail to unregistered user xxx@example.com"

          Moshe Zvi added a comment -

          @Rene: I'm not sure this is "fixable", since that was the whole point of the security fix.

          There's a workaround here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin#Email-extplugin-2.57.1%28March20%2C2017%29

           Personally, I'd like for it to be configurable from the GUI, rather than from the system properties.

           

          Moshe Zvi added a comment - @Rene: I'm not sure this is "fixable", since that was the whole point of the security fix. There's a workaround here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin#Email-extplugin-2.57.1%28March20%2C2017%29  Personally, I'd like for it to be configurable from the GUI, rather than from the system properties.  

          jpschewe added a comment -

          moshe_zvi: I understand the security fix to be to not send email to people that we don't expect to send email to. However if I goto People on my Jenkins system and then click on myself I have my email address in there. I have a job setup to send to that email address. However I'm getting the error "Not sending mail to unregistered user ...". What is the definition of a "registered user"? My access control security realm is set to "Unix user/group database".

          jpschewe added a comment - moshe_zvi : I understand the security fix to be to not send email to people that we don't expect to send email to. However if I goto People on my Jenkins system and then click on myself I have my email address in there. I have a job setup to send to that email address. However I'm getting the error "Not sending mail to unregistered user ...". What is the definition of a "registered user"? My access control security realm is set to "Unix user/group database".

          Moshe Zvi added a comment -

          Go to Manage Jenkins > Configure System, and scroll down to Extended E-mail Notification.

          Did you put 'example.com' in Default user E-mail suffix? I think that's what resolves it. 

          Although I'm not sure - it could actually be the other way around.

          Moshe Zvi added a comment - Go to Manage Jenkins > Configure System , and scroll down to Extended E-mail Notification. Did you put 'example.com' in Default user E-mail suffix? I think that's what resolves it.  Although I'm not sure - it could actually be the other way around.

          jpschewe added a comment -

          Adding the email suffix allows emails to that domain to go through. However I would like to be able to send emails to multiple domains.

          jpschewe added a comment - Adding the email suffix allows emails to that domain to go through. However I would like to be able to send emails to multiple domains.

          Basically we just need make the check that complains about unregistered users a bit smarter so it understands the difference between explicitly configured email addresses vs user email addresses. Havn't looked into how hard this is yet but it might require the reworking of how it builds the list of addresses up I have been thinking about. (ie pass around a list of objects rather than strings containing email addresses so its possible to tell where they came from). Unfortunately my health is not up for it at the moment so not going to happen quick unless someone else picks it up

          David van Laatum added a comment - Basically we just need make the check that complains about unregistered users a bit smarter so it understands the difference between explicitly configured email addresses vs user email addresses. Havn't looked into how hard this is yet but it might require the reworking of how it builds the list of addresses up I have been thinking about. (ie pass around a list of objects rather than strings containing email addresses so its possible to tell where they came from). Unfortunately my health is not up for it at the moment so not going to happen quick unless someone else picks it up

          jpschewe I think your problem might be a different problem if the email address its complaining about is attached to a jenkins user it should allow it. This bug is for the case where you manually enter a email address directly into a job that doesn't exist on any current users

          David van Laatum added a comment - jpschewe I think your problem might be a different problem if the email address its complaining about is attached to a jenkins user it should allow it. This bug is for the case where you manually enter a email address directly into a job that doesn't exist on any current users

          jpschewe added a comment -

          For this particular problem, before the changes I used the following pre-send script. 

           

          recipients = msg.getRecipients(javax.mail.Message.RecipientType.TO)
          {{filtered = recipients.findAll { addr -> addr.toString().contains('@domain1.com') || addr.toString().contains('@domain2.com') }}}
          msg.setRecipients(javax.mail.Message.RecipientType.TO, filtered as javax.mail.Address[])cancel = build.result.toString().equals("ABORTED");

           

          That worked quite well. With this new change I can't send email to people that aren't explicit users.

          jpschewe added a comment - For this particular problem, before the changes I used the following pre-send script.    recipients = msg.getRecipients(javax.mail.Message.RecipientType.TO) {{filtered = recipients.findAll { addr -> addr.toString().contains('@domain1.com') || addr.toString().contains('@domain2.com') }}} msg.setRecipients(javax.mail.Message.RecipientType.TO, filtered as javax.mail.Address[]) cancel = build.result.toString().equals("ABORTED");   That worked quite well. With this new change I can't send email to people that aren't explicit users.

          Jesse Glick added a comment -

          davidvanlaatum

           the case where you manually enter a email address directly into a job

          Please track this down in a debugger. What precisely do you mean by “manually enter”? AFAICT addUsers is called only from methods which are getting a User from some changelog, or from a build trigger. ListRecipientProvider does not call this.

          Jesse Glick added a comment - davidvanlaatum  the case where you manually enter a email address directly into a job Please track this down in a debugger. What precisely do you mean by “manually enter”? AFAICT addUsers is called only from methods which are getting a User from some changelog, or from a build trigger. ListRecipientProvider does not call this.

          danielbeck have a look through the comments

          jglick On closer inspection it is coming from a user that has committed but as its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider?. (Sorry for the confusion most emails to that account are because we hard configured it in the job)

          Now that I have given it more thought I think we are going to have to add an option to the recipient providers to turn this check off on a per job basis (and possibly globally) as there will be cases where people have commit access but don't have a jenkins user ie jenkins.ci.cloudbees.com and should still get emails and I don't think the current system property to turn the check off is sufficent 

          David van Laatum added a comment - danielbeck  have a look through the comments jglick On closer inspection it is coming from a user that has committed but as its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider?. (Sorry for the confusion most emails to that account are because we hard configured it in the job) Now that I have given it more thought I think we are going to have to add an option to the recipient providers to turn this check off on a per job basis (and possibly globally) as there will be cases where people have commit access but don't have a jenkins user ie jenkins.ci.cloudbees.com and should still get emails and I don't think the current system property to turn the check off is sufficent 

          Daniel Beck added a comment -

          I wonder whether we can allow users with User#canDelete() == true as recipients. Those are accounts actually configured in and persisted by Jenkins (rather than ephemeral by parsing changelogs since Jenkins started).

          Of course, SECURITY-372 as reported included emails mistakenly sent to such an account, so should probably be made an opt-in option, if implemented.

          Daniel Beck added a comment - I wonder whether we can allow users with User#canDelete() == true as recipients. Those are accounts actually configured in and persisted by Jenkins (rather than ephemeral by parsing changelogs since Jenkins started). Of course, SECURITY-372 as reported included emails mistakenly sent to such an account, so should probably be made an opt-in option, if implemented.

          jpschewe added a comment -

          Related to this I would like to be able to have Jenkins send email to a mailing list. It seems that this isn't possible with this new security fix.

          jpschewe added a comment - Related to this I would like to be able to have Jenkins send email to a mailing list. It seems that this isn't possible with this new security fix.

          Daniel Beck added a comment -

          It seems that this isn't possible with this new security fix.

          jpschewe Please file a new issue with reproduction steps for this. This change should only affect email addresses gathered from the changelog ("culprits" etc.), not fixed recipients configured for the build step.

          Daniel Beck added a comment - It seems that this isn't possible with this new security fix. jpschewe Please file a new issue with reproduction steps for this. This change should only affect email addresses gathered from the changelog ("culprits" etc.), not fixed recipients configured for the build step.

          Jesse Glick added a comment -

          its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider?

          Sounds like a problem in your LDAP configuration to me, or perhaps in the ldap plugin. Changelog generation will look for a User. If your security realm is working correctly, and that actual person is known to LDAP, then that authentication ought to be found.

          Jesse Glick added a comment - its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider? Sounds like a problem in your LDAP configuration to me, or perhaps in the ldap plugin. Changelog generation will look for a User . If your security realm is working correctly, and that actual person is known to LDAP, then that authentication ought to be found.

          Adam Gabryś added a comment -

          I added hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS to process's parameters:

          /usr/lib/jvm/default-java/bin/java -XX:MaxPermSize=1024m -Dorg.eclipse.jetty.server.Request.maxFormContentSize=500000 -Dhudson.security.csrf.requestfield=Jenkins-Crumb -Djenkins.install.runSetupWizard=false -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpListenAddress=127.0.0.1 --httpPort=9090 --ajp13Port=-1 -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true

          Unfortunately Jenkins still cannot send emails to users:

          10:54:38 Not sending mail to unregistered user valid.user1@example.org
          10:54:38 Not sending mail to unregistered user adam.gabrys@example.org

          The job was build on a slave machine. Should I also add this parameter to slaves' processes?

          Adam Gabryś added a comment - I added hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS to process's parameters: /usr/lib/jvm/default-java/bin/java -XX:MaxPermSize=1024m -Dorg.eclipse.jetty.server.Request.maxFormContentSize=500000 -Dhudson.security.csrf.requestfield=Jenkins-Crumb -Djenkins.install.runSetupWizard=false -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpListenAddress=127.0.0.1 --httpPort=9090 --ajp13Port=-1 -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true Unfortunately Jenkins still cannot send emails to users: 10:54:38 Not sending mail to unregistered user valid.user1@example.org 10:54:38 Not sending mail to unregistered user adam.gabrys@example.org The job was build on a slave machine. Should I also add this parameter to slaves' processes?

          Daniel Beck added a comment -

          agabrys System properties need to be between "java" and "-jar", otherwise they're program arguments and don't work for the intended purpose.

          Please ask for help in appropriate channels, such as IRC or the jenkinsci-users mailing list (when it's back from Google's stupid spam filter).

          Daniel Beck added a comment - agabrys System properties need to be between "java" and "-jar", otherwise they're program arguments and don't work for the intended purpose. Please ask for help in appropriate channels, such as IRC or the jenkinsci-users mailing list (when it's back from Google's stupid spam filter).

          Gary Miller added a comment -

          I have the same problem but I don't have the email extension plugin installed.

          Using Jenkins ver. 1.651.

          Where else could I look for a solution?

          Gary Miller added a comment - I have the same problem but I don't have the email extension plugin installed. Using  Jenkins ver. 1.651. Where else could I look for a solution?

          Daniel Beck added a comment -

          gmiller Mailer Plugin had the same problem, and received a very similar fix.

          https://plugins.jenkins.io/mailer#Mailer-Version1.20%28Mar20,2017%29

          Daniel Beck added a comment - gmiller Mailer Plugin had the same problem, and received a very similar fix. https://plugins.jenkins.io/mailer#Mailer-Version1.20%28Mar20,2017%29

          Kevin Browder added a comment - - edited

          So in our case we're using ldap and git such that Jenkins user ids and git commit authors are both email (with mail={0} for ldap authentication), seems odd that we'd need to add a default suffix when the information from git should actually have the correct suffix as well.

          Kevin Browder added a comment - - edited So in our case we're using ldap and git such that Jenkins user ids and git commit authors are both email (with mail={0} for ldap authentication), seems odd that we'd need to add a default suffix when the information from git should actually have the correct suffix as well.

          Jesse Glick added a comment -

          Very likely an issue in git not email-ext, like JENKINS-9016 perhaps.

          Jesse Glick added a comment - Very likely an issue in  git not email-ext , like  JENKINS-9016 perhaps.

          Igor Kostenko added a comment -

          Could we have options in jenkins configuration for hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS and hudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ?

          I don't have access to jenkins startup options, so the only option for me to fix emails is to downgrade email plugins.

          Igor Kostenko added a comment - Could we have options in jenkins configuration for hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS and hudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ? I don't have access to jenkins startup options, so the only option for me to fix emails is to downgrade email plugins.

          Jesse Glick added a comment -

          I don't have access to jenkins startup options

          Why? There are lots of things controlled by system property. You can also configure these via /script console or init.groovy.

          Jesse Glick added a comment - I don't have access to jenkins startup options Why? There are lots of things controlled by system property. You can also configure these via /script console or init.groovy .

          Igor Orlov added a comment - - edited

          I have learnt that after updating the git configuration to the user used by LDAP, an email can be sent out without a problem:

          git config --global user.name [YOUR_LDAP_USER]

          In our case, the same LDAP user is also registered with GitHub.

           

          Igor Orlov added a comment - - edited I have learnt that after updating the git configuration to the user used by LDAP, an email can be sent out without a problem: git config --global user.name [YOUR_LDAP_USER] In our case, the same LDAP user is also registered with GitHub.  

          Daniel Mish added a comment - - edited

          We are using subversion and having the same issue. Our users have an authorized ID that differs from the email address listed on their configuration page. All of the users have the same email address configured that it says is unregistered.

          Daniel Mish added a comment - - edited We are using subversion and having the same issue. Our users have an authorized ID that differs from the email address listed on their configuration page. All of the users have the same email address configured that it says is unregistered.

          Dave Miller added a comment -

          Is this issue being worked on?  It's been a problem for months, and I really need this to be resolved soon.

          Dave Miller added a comment - Is this issue being worked on?  It's been a problem for months, and I really need this to be resolved soon.

          Just released a new version that gives a more detailed message that may help identify the problem (configuration or code)

          David van Laatum added a comment - Just released a new version that gives a more detailed message that may help identify the problem (configuration or code)

          Which version ?

          What message ?

          Valentin Chartier added a comment - Which version ? What message ?

          Ron Quintos added a comment -

          Currently have 2.60.2 and this is still active. My configuration is similar to danielmish. I have a subversion configuration with active directory in use. The email it complains about is a valid email. Seems that a user is created based on a committer in svn, but that is considered the unregistered user.

          Ron Quintos added a comment - Currently have 2.60.2 and this is still active. My configuration is similar to danielmish . I have a subversion configuration with active directory in use. The email it complains about is a valid email. Seems that a user is created based on a committer in svn, but that is considered the unregistered user.

          Daniel Beck added a comment -

          Right, this issue is SCM-specific. In the case of Subversion, https://github.com/jenkinsci/subversion-plugin/blob/8ef22113a307da105a5d54d7db7ce7b56af85818/src/main/java/hudson/scm/SubversionChangeLogSet.java#L307 is probably too simple – it should try to do more to look up the actual account inside Jenkins.

          FWIW if both SVN and Jenkins are backed by the same LDAP, it can work nicely. The problem occurs on mismatch.

          Daniel Beck added a comment - Right, this issue is SCM-specific. In the case of Subversion, https://github.com/jenkinsci/subversion-plugin/blob/8ef22113a307da105a5d54d7db7ce7b56af85818/src/main/java/hudson/scm/SubversionChangeLogSet.java#L307 is probably too simple – it should try to do more to look up the actual account inside Jenkins. FWIW if both SVN and Jenkins are backed by the same LDAP, it can work nicely. The problem occurs on mismatch.

          danielbeck Just thinking about the mapping thing I think the best solution for this is to add a generic way for users to associate SCM details with their user account that each SCM can extend as required. This would allow users to tell jenkins I am known by this username on all SVN repositories matching this server name/pattern. For git attaching multiple email addresses to an account is probably sufficient. 

          David van Laatum added a comment - danielbeck Just thinking about the mapping thing I think the best solution for this is to add a generic way for users to associate SCM details with their user account that each SCM can extend as required. This would allow users to tell jenkins I am known by this username on all SVN repositories matching this server name/pattern. For git attaching multiple email addresses to an account is probably sufficient. 

            Unassigned Unassigned
            davidvanlaatum David van Laatum
            Votes:
            33 Vote for this issue
            Watchers:
            40 Start watching this issue

              Created:
              Updated: