-
Bug
-
Resolution: Not A Defect
-
Major
-
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?
- duplicates
-
JENKINS-9016 Git creates usernames based on 'name' not the email.
-
- Open
-
- is related to
-
-
- Open
-
[JENKINS-43268] Can't send email to registered users
jpschewe
created issue -
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.
jpschewe
added a comment - OK, so only users that have names that match their unix username will count. Is that correct?
jpschewe
added a comment - 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.
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?
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? 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.
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?