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

“Unregistered user” warning skipping addresses under inappropriate conditions

    Details

    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            renescheibe 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"

            Show
            renescheibe 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"
            Hide
            moshe_zvi 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.

             

            Show
            moshe_zvi 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.  
            Hide
            jpschewe 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".

            Show
            jpschewe 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".
            Hide
            moshe_zvi 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.

            Show
            moshe_zvi 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.
            Hide
            jpschewe 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.

            Show
            jpschewe 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.
            Hide
            davidvanlaatum 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

            Show
            davidvanlaatum 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
            Hide
            davidvanlaatum 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

            Show
            davidvanlaatum 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
            Hide
            jpschewe 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.

            Show
            jpschewe 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.
            Hide
            jglick Jesse Glick added a comment -

            David van Laatum

             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.

            Show
            jglick Jesse Glick added a comment - David van Laatum  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.
            Hide
            davidvanlaatum David van Laatum added a comment -

            Daniel Beck have a look through the comments

            Jesse Glick 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 

            Show
            davidvanlaatum David van Laatum added a comment - Daniel Beck  have a look through the comments Jesse Glick 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 
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            jpschewe 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.

            Show
            jpschewe 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.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            agabrys 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?

            Show
            agabrys 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?
            Hide
            danielbeck Daniel Beck added a comment -

            Adam Gabryś 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).

            Show
            danielbeck Daniel Beck added a comment - Adam Gabryś 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).
            Hide
            gmiller 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?

            Show
            gmiller 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?
            Hide
            danielbeck Daniel Beck added a comment -

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

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

            Show
            danielbeck Daniel Beck added a comment - Gary Miller Mailer Plugin had the same problem, and received a very similar fix. https://plugins.jenkins.io/mailer#Mailer-Version1.20%28Mar20,2017%29
            Hide
            kbrowder 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.

            Show
            kbrowder 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Very likely an issue in  git not email-ext , like  JENKINS-9016 perhaps.
            Hide
            igorkostenko 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.

            Show
            igorkostenko 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.
            Hide
            jglick 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.

            Show
            jglick 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 .
            Hide
            iorlov2 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.

             

            Show
            iorlov2 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.  
            Hide
            danielmish 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.

            Show
            danielmish 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.
            Hide
            millda4 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.

            Show
            millda4 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.
            Hide
            davidvanlaatum 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)

            Show
            davidvanlaatum 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)
            Hide
            valentin92 Valentin Chartier added a comment -

            Which version ?

            What message ?

            Show
            valentin92 Valentin Chartier added a comment - Which version ? What message ?
            Hide
            rqueue Ron Quintos added a comment -

            Currently have 2.60.2 and this is still active. My configuration is similar to Daniel Mish. 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.

            Show
            rqueue Ron Quintos added a comment - Currently have 2.60.2 and this is still active. My configuration is similar to Daniel Mish . 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.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            davidvanlaatum David van Laatum added a comment -

            Daniel Beck 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. 

            Show
            davidvanlaatum David van Laatum added a comment - Daniel Beck 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. 

              People

              • Assignee:
                slide_o_mix Alex Earl
                Reporter:
                davidvanlaatum David van Laatum
              • Votes:
                32 Vote for this issue
                Watchers:
                39 Start watching this issue

                Dates

                • Created:
                  Updated: