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?

danielbeck

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.

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

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.

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?

danielbeck: 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>

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.

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

same issue here, We use the Github OAuth Plugin

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

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

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.

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.

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

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:

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.

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.

jglick

Steps to reproduce the problem from scratch:

1. 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' )
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.

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.

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?

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

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.

Additional Identities does not work for this AFAICT.

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

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)

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

Details are on the wiki plugin page.

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

2.58 with clearer message released

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 epkabeg 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.
 
 

For the options that epkabeg 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)

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.

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.

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.

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.

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

I am using the Subversion plugin and get this message:

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

Is the user id a valid security user?

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)

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

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.

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)

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.

you end up with user accounts for others

They are not real accounts.

this may be a security issue

It is not.

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