• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major Major
    • email-ext-plugin
    • None
    • Jenkins Version 2.32.3
      Email extension plugin 2.57.1

      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?

       

          [JENKINS-43268] Can't send email to registered users

          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 ?

          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 ?

          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.

          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.

          valentin92 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)

          David van Laatum added a comment - valentin92 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)

          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

          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

          Daniel Beck added a comment -

          valentin92: 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.

          Daniel Beck added a comment - valentin92 : 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.

          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

          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

          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)

          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)

          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.

          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.

          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.

          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.

          jpschewe added a comment -

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

          jpschewe added a comment - That's excellent news! I feel much more comfortable enabling this other places then.

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

              Created:
              Updated:
              Resolved: