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

Can't send email to registered users

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: email-ext-plugin
    • Labels:
      None
    • Environment:
      Jenkins Version 2.32.3
      Email extension plugin 2.57.1
    • Similar Issues:

      Description

      I see that some security was added so that emails don't get sent to people that shouldn't get emails. I had fixed this by using a pre-send script that filtered out email addresses. However now with the new change, emails are not getting sent at all. I use the unix database backend for my Jenkins system. If I goto the People page I see 2 entries for myself, one as "Jon Schewe" with an email address "jon@domain1.com". I see a second one as "user1" (which is my unix username) with email address "jon@domain2.com". If I setup a job to send email to "jon@domain1.com" I get the error that the email will not be sent to unregistered users. If I send an email to "jon@domain2.com", then it works. Note that I've set "domain2.com" as my default email suffix.

       

      So the first question here is what is a registered user when using the unix database backend?

      Second, what is considered the email address for a registered user when using the unix database backend?

       

        Attachments

          Issue Links

            Activity

            jpschewe jpschewe created issue -
            Hide
            cryect John Rittenhouse added a comment -

            Seeing basically the same issue where I'm using Github for auth and as a result its saying
            Not sending mail to user $EMAIL_ADDRESS$ with no permission to view $JOB_NAME$
            though all github users with the ability to commit to the repo causing the build do have access to view the job.  Is there anyway to disable the security check that I'm not seeing in the options?

            Show
            cryect John Rittenhouse added a comment - Seeing basically the same issue where I'm using Github for auth and as a result its saying Not sending mail to user $EMAIL_ADDRESS$ with no permission to view $JOB_NAME$ though all github users with the ability to commit to the repo causing the build do have access to view the job.  Is there anyway to disable the security check that I'm not seeing in the options?
            Hide
            davidvanlaatum David van Laatum added a comment -
            Show
            davidvanlaatum David van Laatum added a comment - Daniel Beck
            Hide
            danielbeck Daniel Beck added a comment - - edited

            If I goto the People page

            The "People" page contains everyone, including SCM users (which isn't good enough to receive email now). It looks like your "Jon Schewe" user is ephemeral, created from SCM, and therefore not considered a valid email recipient – only users backed by the auth realm are considered as dynamic email recipients now.

            Show
            danielbeck Daniel Beck added a comment - - edited If I goto the People page The "People" page contains everyone, including SCM users (which isn't good enough to receive email now). It looks like your "Jon Schewe" user is ephemeral, created from SCM, and therefore not considered a valid email recipient – only users backed by the auth realm are considered as dynamic email recipients now.
            Hide
            jpschewe jpschewe added a comment -

            OK, so only users that have names that match their unix username will count. Is that correct?

            Show
            jpschewe jpschewe added a comment - OK, so only users that have names that match their unix username will count. Is that correct?
            Hide
            danielbeck Daniel Beck added a comment -

            In the Unix/PAM auth realm case, yes. Or rather, whatever mapping is happening in the SCM (JENKINS-42951) to assign changelog entries to "People" needs to result in a user that is able to log in.

            Note that you can change email address and display name of your user, so perhaps there's a way to get Git Plugin to consider your commits to be 'yours'.

            Also, https://plugins.jenkins.io/additional-identities-plugin may help, but I don't know how well it works.

            Show
            danielbeck Daniel Beck added a comment - In the Unix/PAM auth realm case, yes. Or rather, whatever mapping is happening in the SCM ( JENKINS-42951 ) to assign changelog entries to "People" needs to result in a user that is able to log in. Note that you can change email address and display name of your user, so perhaps there's a way to get Git Plugin to consider your commits to be 'yours'. Also, https://plugins.jenkins.io/additional-identities-plugin may help, but I don't know how well it works.
            Hide
            jpschewe jpschewe added a comment -

            Additional identities let's me specify another username in a different realm, but not associate another email address with the same user.

            I have users with multiple email addresses and I need to be able to send to mailing lists. Is this no longer possible?

            Show
            jpschewe jpschewe added a comment - Additional identities let's me specify another username in a different realm, but not associate another email address with the same user. I have users with multiple email addresses and I need to be able to send to mailing lists. Is this no longer possible?
            Hide
            ericthieme Eric Thieme added a comment -

            Daniel Beck: I am facing a similar problem but I am using the AD authentication. I have messages complaining about: "Not sending mail to unregistered user Mijk.Van.Dijk@man-those-were-times.com" although I have a jenkins user with (almost) "exactly" this email adress, but only with smaller letters (mijk.van.dijk@man-those-were-times.com). If I look into ${JENKINS_HOME}/users/mvd1/config.xml I see that this user has many informations queried from the AD and that it is not just a created user based on a log entry.

            mvd1 is the ID in our AD for this user with the above emailadress.

            Could it be that this problem is some kind of "lower / upper case" related?

            jpschewe: You are using only small letters, aren't you?

            <user>
              <fullName>Mijk van Dijk</fullName>
              <properties>
                <jenkins.security.ApiTokenProperty>
                  <apiToken>{f....z==}</apiToken>
                </jenkins.security.ApiTokenProperty>
                <com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin="credentials@2.1.13">
                  <domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash"/>
                </com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty>
                <hudson.plugins.emailext.watching.EmailExtWatchAction_-UserProperty plugin="email-ext@2.57.1">
                  <triggers/>
                </hudson.plugins.emailext.watching.EmailExtWatchAction_-UserProperty>
                <hudson.model.MyViewsProperty>
                  <views>
                    <hudson.model.AllView>
                      <owner class="hudson.model.MyViewsProperty" reference="../../.."/>
                      <name>all</name>
                      <filterExecutors>false</filterExecutors>
                      <filterQueue>false</filterQueue>
                      <properties class="hudson.model.View$PropertyList"/>
                    </hudson.model.AllView>
                  </views>
                </hudson.model.MyViewsProperty>
                <org.jenkinsci.plugins.displayurlapi.user.PreferredProviderUserProperty plugin="display-url-api@1.1.1">
                  <providerId>default</providerId>
                </org.jenkinsci.plugins.displayurlapi.user.PreferredProviderUserProperty>
                <hudson.model.PaneStatusProperties>
                  <collapsed/>
                </hudson.model.PaneStatusProperties>
                <hudson.search.UserSearchProperty>
                  <insensitiveSearch>false</insensitiveSearch>
                </hudson.search.UserSearchProperty>
                <hudson.tasks.Mailer_-UserProperty plugin="mailer@1.20">
                  <emailAddress>mijk.van.dijk@man-those-were-times.com</emailAddress>
                </hudson.tasks.Mailer_-UserProperty>
                <jenkins.security.LastGrantedAuthoritiesProperty>
                  <roles>
                    <string>authenticated</string>
                    <string>ROLE_FRRZ</string>
                    <string>ROLE_BRRZ</string>
                  </roles>
                  <timestamp>1490891205583</timestamp>
                </jenkins.security.LastGrantedAuthoritiesProperty>
              </properties>
            </user>
            

             

            Show
            ericthieme Eric Thieme added a comment - Daniel Beck : I am facing a similar problem but I am using the AD authentication. I have messages complaining about: "Not sending mail to unregistered user Mijk.Van.Dijk@man-those-were-times.com " although I have a jenkins user with (almost) "exactly" this email adress, but only with smaller letters (mijk.van.dijk@man-those-were-times.com). If I look into ${JENKINS_HOME}/users/mvd1/config.xml I see that this user has many informations queried from the AD and that it is not just a created user based on a log entry. mvd1 is the ID in our AD for this user with the above emailadress. Could it be that this problem is some kind of "lower / upper case" related? jpschewe : You are using only small letters, aren't you? <user>   <fullName>Mijk van Dijk</fullName>   <properties>     <jenkins.security.ApiTokenProperty>       <apiToken>{f....z==}</apiToken>     </jenkins.security.ApiTokenProperty>     <com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin= "credentials@2.1.13" >       <domainCredentialsMap class= "hudson.util.CopyOnWriteMap$Hash" />     </com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty>     <hudson.plugins.emailext.watching.EmailExtWatchAction_-UserProperty plugin= "email-ext@2.57.1" >       <triggers/>     </hudson.plugins.emailext.watching.EmailExtWatchAction_-UserProperty>     <hudson.model.MyViewsProperty>       <views>         <hudson.model.AllView>           <owner class= "hudson.model.MyViewsProperty" reference= "../../.." />           <name>all</name>           <filterExecutors> false </filterExecutors>           <filterQueue> false </filterQueue>           <properties class= "hudson.model.View$PropertyList" />         </hudson.model.AllView>       </views>     </hudson.model.MyViewsProperty>     <org.jenkinsci.plugins.displayurlapi.user.PreferredProviderUserProperty plugin= "display-url-api@1.1.1" >       <providerId> default </providerId>     </org.jenkinsci.plugins.displayurlapi.user.PreferredProviderUserProperty>     <hudson.model.PaneStatusProperties>       <collapsed/>     </hudson.model.PaneStatusProperties>     <hudson.search.UserSearchProperty>       <insensitiveSearch> false </insensitiveSearch>     </hudson.search.UserSearchProperty>     <hudson.tasks.Mailer_-UserProperty plugin= "mailer@1.20" >       <emailAddress>mijk.van.dijk@man-those-were-times.com</emailAddress>     </hudson.tasks.Mailer_-UserProperty>     <jenkins.security.LastGrantedAuthoritiesProperty>       <roles>         <string>authenticated</string>         <string>ROLE_FRRZ</string>         <string>ROLE_BRRZ</string>       </roles>       <timestamp>1490891205583</timestamp>     </jenkins.security.LastGrantedAuthoritiesProperty>   </properties> </user>  
            Hide
            danielbeck Daniel Beck added a comment -

            Could it be that this problem is some kind of "lower / upper case" related?

            Jenkins needs to consider the commit to be done from an actual user of Jenkins. There's no search done to see whether some user in Jenkins has a similar email address. (And if it did, different capitalization would prevent that anyway, email address local-parts can be case sensitive and Jenkins has no way to tell.)

            Here's a way to determine whether it should work: Click the user name in the changelog of the job (a link to /user/username. If you end up at an actual user of Jenkins, sending email should work. If not, you were relying on Jenkins just sending email to anyone before.

            Show
            danielbeck Daniel Beck added a comment - Could it be that this problem is some kind of "lower / upper case" related? Jenkins needs to consider the commit to be done from an actual user of Jenkins. There's no search done to see whether some user in Jenkins has a similar email address. (And if it did, different capitalization would prevent that anyway, email address local-parts can be case sensitive and Jenkins has no way to tell.) Here's a way to determine whether it should work: Click the user name in the changelog of the job (a link to /user/username . If you end up at an actual user of Jenkins, sending email should work. If not, you were relying on Jenkins just sending email to anyone before.
            Hide
            jpschewe jpschewe added a comment -

            I have all lowercase email addresses and usernames, so it's not a case-sensitivity issue.

            Show
            jpschewe jpschewe added a comment - I have all lowercase email addresses and usernames, so it's not a case-sensitivity issue.
            waffel Thomas Wabner made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-43386 [ JENKINS-43386 ]
            Hide
            emoshaya_cognitoiq Ebrahim Moshaya added a comment -

            same issue here, We use the Github OAuth Plugin

            https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+Plugin

            Show
            emoshaya_cognitoiq Ebrahim Moshaya added a comment - same issue here, We use the Github OAuth Plugin https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+Plugin
            jglick Jesse Glick made changes -
            Link This issue relates to SECURITY-372 [ SECURITY-372 ]
            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.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-9016 [ JENKINS-9016 ]
            Hide
            danielmish Daniel Mish added a comment - - edited

            We are not using Git. We are using subversion and having the same issue. Our users have an authorized ID that is different 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 not using Git. We are using subversion and having the same issue. Our users have an authorized ID that is different 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
            igorkostenko Igor Kostenko added a comment - - edited

            Yes, I see the same issue with mercurial. I had to revert mailer to 1.19 and email-ext to 2.57 in order to fix emails.

            Show
            igorkostenko Igor Kostenko added a comment - - edited Yes, I see the same issue with mercurial. I had to revert mailer to 1.19 and email-ext to 2.57 in order to fix emails.
            Hide
            jglick Jesse Glick added a comment -

            Mapping from email addresses to user ID is specific to an SCM. Not a bug in this plugin.

            Show
            jglick Jesse Glick added a comment - Mapping from email addresses to user ID is specific to an SCM. Not a bug in this plugin.
            danielmish Daniel Mish made changes -
            Attachment image-2017-06-22-08-01-34-424.png [ 38593 ]
            Hide
            danielmish Daniel Mish added a comment -

            Jenkins has a record of the email address in People -> Config under that registered user. I can see the email address correctly attributed to a registered user. Emails were going out just fine until we upgraded to Jenkins 2.

            Here is the message that appears in the log:

            Recording test results
            Not sending mail to unregistered user Sxxx.Cxxx@xxx.com

            Here is the user's configure screen:

            Show
            danielmish Daniel Mish added a comment - Jenkins has a record of the email address in People -> Config under that registered user. I can see the email address correctly attributed to a registered user. Emails were going out just fine until we upgraded to Jenkins 2. Here is the message that appears in the log: Recording test results Not sending mail to unregistered user Sxxx.Cxxx@xxx.com Here is the user's configure screen:
            Hide
            danielbeck Daniel Beck added a comment -

            The log message with the email address is misleading as it hides the actual problem.

            Example: I commit to Git as "Daniel Beck <daniel@example.org>". Git plugin then associates that commit with the user ID "Daniel Beck", who has the email address daniel@example.org.

            If I however log in to Jenkins as the user dbeck, it's still a different user, and Jenkins will refuse to send an email, even if both have the same email address, and the log message will be an unhelpful

            Not sending mail to unregistered user daniel@example.org

            As I wrote before:

            Here's a way to determine whether it should work: Click the user name in the changelog of the job (a link to /user/username. If you end up at an actual user of Jenkins, sending email should work. If not, you were relying on Jenkins just sending email to anyone before.

            Hence the link to JENKINS-9016, as the Git plugin doesn't associate commits with actual users of Jenkins in what I expect is the majority of configurations.

            Show
            danielbeck Daniel Beck added a comment - The log message with the email address is misleading as it hides the actual problem. Example: I commit to Git as "Daniel Beck <daniel@example.org>". Git plugin then associates that commit with the user ID "Daniel Beck", who has the email address daniel@example.org. If I however log in to Jenkins as the user dbeck, it's still a different user, and Jenkins will refuse to send an email, even if both have the same email address, and the log message will be an unhelpful Not sending mail to unregistered user daniel@example.org As I wrote before: Here's a way to determine whether it should work: Click the user name in the changelog of the job (a link to /user/username . If you end up at an actual user of Jenkins, sending email should work. If not, you were relying on Jenkins just sending email to anyone before. Hence the link to JENKINS-9016 , as the Git plugin doesn't associate commits with actual users of Jenkins in what I expect is the majority of configurations.
            Hide
            jglick Jesse Glick added a comment -

            Not quite sure I followed that explanation. What are the user IDs, associated addresses, and presence/absence in the security realm in this case?

            If there is a straightforward way to reproduce a problem of this kind from scratch, it may be possible to improve the messaging from the plugin to assist in diagnosis.

            Show
            jglick Jesse Glick added a comment - Not quite sure I followed that explanation. What are the user IDs, associated addresses, and presence/absence in the security realm in this case? If there is a straightforward way to reproduce a problem of this kind from scratch, it may be possible to improve the messaging from the plugin to assist in diagnosis.
            Hide
            danielbeck Daniel Beck added a comment -

            Jesse Glick

            Steps to reproduce the problem from scratch:

            1. Create a Git repo on your local machine, path e.g. /Users/danielbeck/foogit init foo ; cd foo ; date > foo ; git add foo ; git commit -a -m 'initial commit' )
            2. Install Jenkins 2.46.3 from scratch
            3. Install Git and Mailer plugins in setup wizard
            4. Customize admin user: danielbeck (or whatever is NOT your email address's local-part), password, password, Daniel Beck, daniel-beck@users.noreply.github.com (or whatever your Git email address is)
            5. create a freestyle project
            6. Configure Git SCM with file:///Users/danielbeck/foo or equivalent{{}}
            7. Add a shell build step with exit 1{{}}
            8. Add an email notification and check 'send email to individuals who broke the build'
            9. Start a build.
            10. Now, create a change in the Git repo ( date > foo ; git commit -a -m 'second commit' )
            11. Start another build

            Result in the build log:

            Not sending mail to unregistered user daniel-beck@users.noreply.github.com

            …when that email address is the one used for my admin user who started the build.

            Why? http://localhost:8080/job/$NAME/2/changes reveals: Git associated the commit with the user daniel-beck, when my actual Jenkins username is danielbeck

            So it looks like I got the previous description slightly wrong, Git plugin uses the local-part of the email address rather than the display name – which makes sense given what issue SECURITY-372 fixed. But the log message is just confusing, as two users (one SCM user, one actual Jenkins account with legitimate access) may have the same email address.

            Show
            danielbeck Daniel Beck added a comment - Jesse Glick Steps to reproduce the problem from scratch: Create a Git repo on your local machine, path e.g.  /Users/danielbeck/foo (  git init foo ; cd foo ; date > foo ; git add foo ; git commit -a -m 'initial commit' ) Install Jenkins 2.46.3 from scratch Install Git and Mailer plugins in setup wizard Customize admin user: danielbeck (or whatever is NOT your email address's local-part), password, password, Daniel Beck, daniel-beck@users.noreply.github.com (or whatever your Git email address is) create a freestyle project Configure Git SCM with  file:///Users/danielbeck/foo or equivalent{{}} Add a shell build step with exit 1 {{}} Add an email notification and check 'send email to individuals who broke the build' Start a build. Now, create a change in the Git repo ( date > foo ; git commit -a -m 'second commit' ) Start another build Result in the build log: Not sending mail to unregistered user daniel-beck@users.noreply.github.com …when that email address is the one used for my admin user who started the build . Why?  http://localhost:8080/job/$NAME/2/changes reveals: Git associated the commit with the user daniel-beck , when my actual Jenkins username is danielbeck So it looks like I got the previous description slightly wrong, Git plugin uses the local-part of the email address rather than the display name – which makes sense given what issue SECURITY-372 fixed. But the log message is just confusing, as two users (one SCM user, one actual Jenkins account with legitimate access) may have the same email address.
            jglick Jesse Glick made changes -
            Attachment JENKINS-43268.diff [ 38603 ]
            Hide
            jglick Jesse Glick added a comment -

            Yes I think I see your point. Given the attached patch (to the mailer plugin, not email-ext, and not complete) would that make the issue more obvious? Does not necessarily guide the user toward the right fix—that would likely require broader changes—but it is a start.

            Show
            jglick Jesse Glick added a comment - Yes I think I see your point. Given the attached patch (to the mailer plugin, not email-ext , and not complete) would that make the issue more obvious? Does not necessarily guide the user toward the right fix—that would likely require broader changes—but it is a start.
            Hide
            danielbeck Daniel Beck added a comment -

            I expect that

            Not sending mail to unregistered user daniel-beck with address daniel-beck@users.noreply.github.com

            instead of

            Not sending mail to unregistered user daniel-beck@users.noreply.github.com

            would be useful to at least reduce the confusion around the current behavior.

            Acknowledging that this isn't a proper fix, obviously, what do the other watchers think about this change? Would this reduce the confusion around why no email gets sent?

            Show
            danielbeck Daniel Beck added a comment - I expect that Not sending mail to unregistered user daniel-beck with address daniel-beck@users.noreply.github.com instead of Not sending mail to unregistered user daniel-beck@users.noreply.github.com would be useful to at least reduce the confusion around the current behavior. Acknowledging that this isn't a proper fix, obviously, what do the other watchers think about this change? Would this reduce the confusion around why no email gets sent?
            Hide
            bherb Benjamin Herbert added a comment -

            I would appreciate thix clarification. For me it was completely unclear that two different users with the same email address even existed... 

             

            Show
            bherb Benjamin Herbert added a comment - I would appreciate thix clarification. For me it was completely unclear that two different users with the same email address even existed...   
            Hide
            jglick Jesse Glick added a comment -

            A real message would probably need to read something more like

            Not sending mail todaniel-beck@users.noreply.github.com because your SCM claimed this was associated with a user ID ‘daniel-beck’ which your security realm does not recognize; you may need changes in your SCM plugin or to install the Additional Identities plugin yada yada yada https://wiki.jenkins.io/Something+Here

            depending on what we are able to fix mechanically.

            Show
            jglick Jesse Glick added a comment - A real message would probably need to read something more like Not sending mail to daniel-beck@users.noreply.github.com  because your SCM claimed this was associated with a user ID ‘daniel-beck’ which your security realm does not recognize; you may need changes in your SCM plugin or to install the Additional Identities plugin yada yada yada  https://wiki.jenkins.io/Something+Here depending on what we are able to fix mechanically.
            Hide
            danielbeck Daniel Beck added a comment -

            Additional Identities does not work for this AFAICT.

            Show
            danielbeck Daniel Beck added a comment - Additional Identities does not work for this AFAICT.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: David van Laatum
            Path:
            src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
            http://jenkins-ci.org/commit/email-ext-plugin/6d4cbac1ff096b3ecd37bc1a1da184252a342c57
            Log:
            JENKINS-43268 make message clearer
            todo unit test

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: David van Laatum Path: src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java http://jenkins-ci.org/commit/email-ext-plugin/6d4cbac1ff096b3ecd37bc1a1da184252a342c57 Log: JENKINS-43268 make message clearer todo unit test
            Hide
            davidvanlaatum David van Laatum added a comment -

            I have updated the message but haven't tested nor can I get a unit test to work for some reason (bit out of practice) I assume user.getId() is the username (correct me if I am wrong)

            Show
            davidvanlaatum David van Laatum added a comment - I have updated the message but haven't tested nor can I get a unit test to work for some reason (bit out of practice) I assume user.getId() is the username (correct me if I am wrong)
            Hide
            danielmish Daniel Mish added a comment - - edited

            Please indicate how to turn off the unregistered user functionality. All our checkins that are failing are valid email addresses. The user ID used by the SCM is correctly mapped to their valid email address. The user ID used by the SCM is identical to the Jenkins user ID. The Jenkins user ID also has the correct email address associated to it, as I indicated in the previous post. The error message is indicating that it can not send to the unregistered user with the correct email address. Since the user ID is identical in both Jenkins and the SCM, one of them must be finding the correct email address to display. There is something wrong here. It is not a configuration issue in the SCM. It was working in previous versions.

            If someone can check in to a repo and break it, they must receive an email. I fail to see why this would not be the case or why this would be complex. I would rather see the send fail because the user is not a well formed email address than to never attempt to send email at all.

             

            Example:

            User vxxxz logs in to the SCM and commits their changes.

            Sxxx.Cxxx@xxx.com is registered to vxxxz in the SCM.

            Jenkins user vxxxz is correctly associated with Sxxx.Cxxx@xxx.com.

            Error is displayed in output from Jenkins job:
            Recording test results
            Not sending mail to unregistered user Sxxx.Cxxx@xxx.com

            Show
            danielmish Daniel Mish added a comment - - edited Please indicate how to turn off the unregistered user functionality. All our checkins that are failing are valid email addresses. The user ID used by the SCM is correctly mapped to their valid email address. The user ID used by the SCM is identical to the Jenkins user ID. The Jenkins user ID also has the correct email address associated to it, as I indicated in the previous post. The error message is indicating that it can not send to the unregistered user with the correct email address. Since the user ID is identical in both Jenkins and the SCM, one of them must be finding the correct email address to display. There is something wrong here. It is not a configuration issue in the SCM. It was working in previous versions. If someone can check in to a repo and break it, they must receive an email. I fail to see why this would not be the case or why this would be complex. I would rather see the send fail because the user is not a well formed email address than to never attempt to send email at all.   Example: User vxxxz logs in to the SCM and commits their changes. Sxxx.Cxxx@xxx.com  is registered to vxxxz in the SCM. Jenkins user vxxxz is correctly associated with Sxxx.Cxxx@xxx.com. Error is displayed in output from Jenkins job: Recording test results Not sending mail to unregistered user Sxxx.Cxxx@xxx.com
            Hide
            davidvanlaatum David van Laatum added a comment -

            Details are on the wiki plugin page.

            Show
            davidvanlaatum David van Laatum added a comment - Details are on the wiki plugin page.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: David van Laatum
            Path:
            src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
            http://jenkins-ci.org/commit/email-ext-plugin/4cb744c3d9d031bd6ef9d95a76d35703525f56c2
            Log:
            JENKINS-43268 make message clearer
            todo unit test

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: David van Laatum Path: src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java http://jenkins-ci.org/commit/email-ext-plugin/4cb744c3d9d031bd6ef9d95a76d35703525f56c2 Log: JENKINS-43268 make message clearer todo unit test
            Hide
            davidvanlaatum David van Laatum added a comment -

            2.58 with clearer message released

            Show
            davidvanlaatum David van Laatum added a comment - 2.58 with clearer message released
            Hide
            jose_camacho Jose Camacho added a comment -

            This is a copy of the comment in a different issue (JENKINS-9016 see duplicates list), copied here if anyone is tracking this issue

            ----------
            I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho).

            My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears.

            For the options that Andréas Berg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?

            – Workaround

            Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround".

            We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code:

            def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS

            RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true

            // Send Email with emailext

            RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal

            (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation)

            I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.
             
             

            Show
            jose_camacho Jose Camacho added a comment - This is a copy of the comment in a different issue ( JENKINS-9016 see duplicates list), copied here if anyone is tracking this issue ---------- I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho). My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears. For the options that  Andréas Berg  suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"? – Workaround Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround". We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code: def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS  = true // Send Email with emailext RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal (this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation) I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.    
            Hide
            davidvanlaatum David van Laatum added a comment -

            For the options that Andréas Berg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?

            The reason is jenkins kinda lumps users that can login and scm users into the same bucket so if your build uses any sort of external SCM eg pipeline libraries from github people that have committed to that SCM can start getting emails from your jenkins. Unfortunately how jenkins matches up users is outside of my control as the plugin maintainer, but I would have expected it to combine users with the same email address between AD and GIT. If I remember Ill have a play at work and see what I see (in the process of switching to GIT from SVN)

            Show
            davidvanlaatum David van Laatum added a comment - For the options that  Andréas Berg  suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"? The reason is jenkins kinda lumps users that can login and scm users into the same bucket so if your build uses any sort of external SCM eg pipeline libraries from github people that have committed to that SCM can start getting emails from your jenkins. Unfortunately how jenkins matches up users is outside of my control as the plugin maintainer, but I would have expected it to combine users with the same email address between AD and GIT. If I remember Ill have a play at work and see what I see (in the process of switching to GIT from SVN)
            Hide
            igorkostenko Igor Kostenko added a comment -

            Reason is fine, but implementation is not. Check should be done vs email and not vs user and RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS option should be accessible via jenkins configuration without workarounds.

            Show
            igorkostenko Igor Kostenko added a comment - Reason is fine, but implementation is not. Check should be done vs email and not vs user and RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS option should be accessible via jenkins configuration without workarounds.
            Hide
            danielbeck Daniel Beck added a comment -

            For Git Plugin 3.3.2 and up should allow associating users by "Full Name" (which gets shown to the top right in Jenkins when logged in).

            E.g. if I'm dbeck/Daniel Beck/dbeck@example.com in Jenkins, and Daniel Beck <daniel@example.org> in Git, that should associate my Jenkins account with the Git commit and send me an email to dbeck@example.com.

            Since the display name is editable by users, it would be interesting to get feedback whether that works for anyone. In a test run very similar to my comment on June 22, it worked for me.

            Sure, it's still not the desirable mapping using email, but still. In some cases (users.noreply.github.com for example), it's even better.

            Show
            danielbeck Daniel Beck added a comment - For Git Plugin 3.3.2 and up should allow associating users by "Full Name" (which gets shown to the top right in Jenkins when logged in). E.g. if I'm  dbeck/Daniel Beck/dbeck@example.com in Jenkins, and  Daniel Beck <daniel@example.org> in Git, that should associate my Jenkins account with the Git commit and send me an email to dbeck@example.com. Since the display name is editable by users, it would be interesting to get feedback whether that works for anyone. In a test run very similar to my comment on June 22, it worked for me. Sure, it's still not the desirable mapping using email, but still. In some cases (users.noreply.github.com for example), it's even better.
            Hide
            davidvanlaatum David van Laatum added a comment -

            My only worry is common names 'Daniel Smith' for example (come across a number of them), if you have two people with the same name (but different emails) you don't want jenkins assuming they are the same person. I really think email is only truly uniq id we can rely on. But when matching up with something like AD it should match against all emails not just the primary one. The number of times my work email gets changed (then the old ones randomly disappearing) is getting frustrating.

            Show
            davidvanlaatum David van Laatum added a comment - My only worry is common names 'Daniel Smith' for example (come across a number of them), if you have two people with the same name (but different emails) you don't want jenkins assuming they are the same person. I really think email is only truly uniq id we can rely on. But when matching up with something like AD it should match against all emails not just the primary one. The number of times my work email gets changed (then the old ones randomly disappearing) is getting frustrating.
            Hide
            danielbeck Daniel Beck added a comment -

            if you have two people with the same name (but different emails) you don't want jenkins assuming they are the same person

            Right; a possible problem for larger orgs. I'm not saying this approach is perfect. But note that the email will then only be sent when the 'wrong' person does have access to the job in question, so will at worst result in no email.

            In such a case, the affected user can edit their display name / user.name to disambiguate e.g. with middle initial or department (for Git at least). They should have full control over both. Inconvenient, but that's it.

            Show
            danielbeck Daniel Beck added a comment - if you have two people with the same name (but different emails) you don't want jenkins assuming they are the same person Right; a possible problem for larger orgs. I'm not saying this approach is perfect. But note that the email will then only be sent when the 'wrong' person does have access to the job in question, so will at worst result in no email. In such a case, the affected user can edit their display name / user.name to disambiguate e.g. with middle initial or department (for Git at least). They should have full control over both. Inconvenient, but that's it.
            Hide
            davidvanlaatum David van Laatum added a comment -

            I don't see why using email is a problem if it is available?

            Show
            davidvanlaatum David van Laatum added a comment - I don't see why using email is a problem if it is available?
            Hide
            davida2009 David Aldrich added a comment -

            I am using the Subversion plugin and get this message:

            Not sending mail to unregistered user <snip> because your SCM claimed this was associated with a user ID ‘<snip>' which your security realm does not recognize; you may need changes in your SCM plugin
            An attempt to send an e-mail to empty list of recipients, ignored.

            I do want this user to get a notification email. How can I resolve this?

            Show
            davida2009 David Aldrich added a comment - I am using the Subversion plugin and get this message: Not sending mail to unregistered user <snip> because your SCM claimed this was associated with a user ID ‘<snip>' which your security realm does not recognize; you may need changes in your SCM plugin An attempt to send an e-mail to empty list of recipients, ignored. I do want this user to get a notification email. How can I resolve this?
            Hide
            davidvanlaatum David van Laatum added a comment -

            Is the user id a valid security user?

            Show
            davidvanlaatum David van Laatum added a comment - Is the user id a valid security user?
            Hide
            valentin92 Valentin Chartier added a comment - - edited

            Also having this message
            Not sending mail to unregistered user <user-email@domain.com> because your SCM claimed this was associated with a user ID <User Name> which your security realm does not recognize; you may need changes in your SCM plugin
            which gives hints that the issue may be with the Security Realm or with the SCM plugin config.

            My SCM plugin is Git and I am not seeing any Git setting in Jenkins configuration page that could have any impact on this issue. What should we be looking for ? Where ?

            My Security Realm is configured with "Jenkins own user database" and the only option "Allow users to sign up" does not seem to be related to our issue. Am I wrong ? Can the issue lie in the "Authorization" part which in my case is configured as "Project-based Matrix Authorization Strategy" ?

            Hence it is not obvious to me how the above message helps figuring out the issue. At this point it looks like it is leading into 2 different false tracks.

            So, what it the correct way to interpret this message and what should the one having it really be looking at ?

            Show
            valentin92 Valentin Chartier added a comment - - edited Also having this message Not sending mail to unregistered user <user-email@domain.com> because your SCM claimed this was associated with a user ID <User Name> which your security realm does not recognize; you may need changes in your SCM plugin which gives hints that the issue may be with the Security Realm or with the SCM plugin config. My SCM plugin is Git and I am not seeing any Git setting in Jenkins configuration page that could have any impact on this issue. What should we be looking for ? Where ? My Security Realm is configured with "Jenkins own user database" and the only option "Allow users to sign up" does not seem to be related to our issue. Am I wrong ? Can the issue lie in the "Authorization" part which in my case is configured as "Project-based Matrix Authorization Strategy" ? Hence it is not obvious to me how the above message helps figuring out the issue. At this point it looks like it is leading into 2 different false tracks. So, what it the correct way to interpret this message and what should the one having it really be looking at ?
            Hide
            jpschewe jpschewe added a comment -

            Having seen this issue go round and round for some time I have a suggestion. If you add a per-job checkbox that enables the filtering or disables the filtering, then 90% (or more) of the people that have issues with this could the behavior they want, when they want it. I would suggest it live under the advanced settings for the email+ext plugin and the standard mail plugin. It can default to filter email addresses. That should be easy enough to add.

            A more advanced version would be to allow each job to have a list of email addresses that are allowed, perhaps using glob notation. This would allow me to accept '*@company.com' and 'foo@other-company.com' and exclude everything else.

            I could even imagine an advanced setting that also allows a blacklist, never send to 'evil@competitor.com', but send to anyone else.

            Remember the goal here is to keep from sending emails to people one doesn't want to send to. This doesn't need to tie into the Jenkins user database. It could just be a friendly interface to specifying a white list and optionally a black list. Then you don't need to fight with how SCMs define users vs. how Jenkins defines users.

            Show
            jpschewe jpschewe added a comment - Having seen this issue go round and round for some time I have a suggestion. If you add a per-job checkbox that enables the filtering or disables the filtering, then 90% (or more) of the people that have issues with this could the behavior they want, when they want it. I would suggest it live under the advanced settings for the email+ext plugin and the standard mail plugin. It can default to filter email addresses. That should be easy enough to add. A more advanced version would be to allow each job to have a list of email addresses that are allowed, perhaps using glob notation. This would allow me to accept '*@company.com' and 'foo@other-company.com' and exclude everything else. I could even imagine an advanced setting that also allows a blacklist, never send to 'evil@competitor.com', but send to anyone else. Remember the goal here is to keep from sending emails to people one doesn't want to send to. This doesn't need to tie into the Jenkins user database. It could just be a friendly interface to specifying a white list and optionally a black list. Then you don't need to fight with how SCMs define users vs. how Jenkins defines users.
            Hide
            davidvanlaatum David van Laatum added a comment -

            Valentin Chartier The message tells us how jenkins mapped the scm user to a jenkins user so now you need to tell us does <User Name> exist in the user database? Not entirely sure how the git plugin maps users but I'm guessing by email so if your user doesn't have an email configured to match one used in git or it doesn't match username@jenkins-default-domain then it won't map correctly ie in my case it might map to a user david.vanlaatum insted of dvanlaatum (following the common corporate naming policy where my git email is something like david.vanlaatum@example.com)

            Show
            davidvanlaatum David van Laatum added a comment - Valentin Chartier The message tells us how jenkins mapped the scm user to a jenkins user so now you need to tell us does <User Name> exist in the user database? Not entirely sure how the git plugin maps users but I'm guessing by email so if your user doesn't have an email configured to match one used in git or it doesn't match username@jenkins-default-domain then it won't map correctly ie in my case it might map to a user david.vanlaatum insted of dvanlaatum (following the common corporate naming policy where my git email is something like david.vanlaatum@example.com)
            Hide
            davidvanlaatum David van Laatum added a comment -

            jpschewe I kinda agree with you unfortunately my health is bad atm so not going to happen anytime soon.  If someone wants to implement a whitelist/blacklist at job and global level that can cover domain level as well as full email I will review and accept a pull request

            Show
            davidvanlaatum David van Laatum added a comment - jpschewe I kinda agree with you unfortunately my health is bad atm so not going to happen anytime soon.  If someone wants to implement a whitelist/blacklist at job and global level that can cover domain level as well as full email I will review and accept a pull request
            Hide
            danielbeck Daniel Beck added a comment -

            Valentin Chartier: Your comment only makes sense to me if you haven't read my previous two or so comments – perhaps do that now, the explanation and workaround described there may work for you.

            Show
            danielbeck Daniel Beck added a comment - Valentin Chartier : Your comment only makes sense to me if you haven't read my previous two or so comments – perhaps do that now, the explanation and workaround described there may work for you.
            Hide
            aflat aflat added a comment -

            I have hit the same issue with ldap backed git server, and ldap backed jenkins. This looks like a git scm issue, as it's getting a username of first.last from the email address first.last@actifio.com. Yet my users have a username of firstlast.

            It looks like svn may have the same issue. Sadly it crops up in this plugin as a bug.

            I have added a pull request to add a checkbox to the global config to allow unregistered emails to be sent, so you don't have to set the prop on the jenkins statup command line

            Show
            aflat aflat added a comment - I have hit the same issue with ldap backed git server, and ldap backed jenkins. This looks like a git scm issue, as it's getting a username of first.last from the email address first.last@actifio.com. Yet my users have a username of firstlast. It looks like svn may have the same issue. Sadly it crops up in this plugin as a bug. I have added a pull request to add a checkbox to the global config to allow unregistered emails to be sent, so you don't have to set the prop on the jenkins statup command line
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: George
            Path:
            src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java
            src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
            src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy
            src/main/webapp/help/globalConfig/allowUnregistered.html
            http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8
            Log:
            JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: George Path: src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy src/main/webapp/help/globalConfig/allowUnregistered.html http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8 Log: JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)
            Hide
            jpschewe jpschewe added a comment -

            I have found that the git SCM plugin now allows me to automatically create users for authors in commits. Enabling this appears to have fixed most issues with emailing users. It does have the downside that you end up with user accounts for others and this may be a security issue.

            Show
            jpschewe jpschewe added a comment - I have found that the git SCM plugin now allows me to automatically create users for authors in commits. Enabling this appears to have fixed most issues with emailing users. It does have the downside that you end up with user accounts for others and this may be a security issue.
            Hide
            jglick Jesse Glick added a comment -

            you end up with user accounts for others

            They are not real accounts.

            this may be a security issue

            It is not.

            Show
            jglick Jesse Glick added a comment - you end up with user accounts for others They are not real accounts. this may be a security issue It is not.
            Hide
            jpschewe jpschewe added a comment -

            That's excellent news! I feel much more comfortable enabling this other places then.

            Show
            jpschewe jpschewe added a comment - That's excellent news! I feel much more comfortable enabling this other places then.
            slide_o_mix Alex Earl made changes -
            Status Open [ 1 ] Closed [ 6 ]
            Resolution Not A Defect [ 7 ]

              People

              • Assignee:
                davidvanlaatum David van Laatum
                Reporter:
                jpschewe jpschewe
              • Votes:
                20 Vote for this issue
                Watchers:
                29 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: