-
Bug
-
Resolution: Unresolved
-
Major
-
Powered by SuggestiMate
Security patch broke it. If configured email is not attached to a know user fails to send email with
Not sending mail to unregistered user xxx@example.com
turns out it wasn't what I thought but keeping open as so many people have added similar issues
[JENKINS-43178] “Unregistered user” warning skipping addresses under inappropriate conditions
@Rene: I'm not sure this is "fixable", since that was the whole point of the security fix.
There's a workaround here: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin#Email-extplugin-2.57.1%28March20%2C2017%29
Personally, I'd like for it to be configurable from the GUI, rather than from the system properties.
moshe_zvi: I understand the security fix to be to not send email to people that we don't expect to send email to. However if I goto People on my Jenkins system and then click on myself I have my email address in there. I have a job setup to send to that email address. However I'm getting the error "Not sending mail to unregistered user ...". What is the definition of a "registered user"? My access control security realm is set to "Unix user/group database".
Go to Manage Jenkins > Configure System, and scroll down to Extended E-mail Notification.
Did you put 'example.com' in Default user E-mail suffix? I think that's what resolves it.
Although I'm not sure - it could actually be the other way around.
Adding the email suffix allows emails to that domain to go through. However I would like to be able to send emails to multiple domains.
Basically we just need make the check that complains about unregistered users a bit smarter so it understands the difference between explicitly configured email addresses vs user email addresses. Havn't looked into how hard this is yet but it might require the reworking of how it builds the list of addresses up I have been thinking about. (ie pass around a list of objects rather than strings containing email addresses so its possible to tell where they came from). Unfortunately my health is not up for it at the moment so not going to happen quick unless someone else picks it up
jpschewe I think your problem might be a different problem if the email address its complaining about is attached to a jenkins user it should allow it. This bug is for the case where you manually enter a email address directly into a job that doesn't exist on any current users
For this particular problem, before the changes I used the following pre-send script.
recipients = msg.getRecipients(javax.mail.Message.RecipientType.TO)
{{filtered = recipients.findAll { addr -> addr.toString().contains('@domain1.com') || addr.toString().contains('@domain2.com') }}}
msg.setRecipients(javax.mail.Message.RecipientType.TO, filtered as javax.mail.Address[])cancel = build.result.toString().equals("ABORTED");
That worked quite well. With this new change I can't send email to people that aren't explicit users.
the case where you manually enter a email address directly into a job
Please track this down in a debugger. What precisely do you mean by “manually enter”? AFAICT addUsers is called only from methods which are getting a User from some changelog, or from a build trigger. ListRecipientProvider does not call this.
danielbeck have a look through the comments
jglick On closer inspection it is coming from a user that has committed but as its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider?. (Sorry for the confusion most emails to that account are because we hard configured it in the job)
Now that I have given it more thought I think we are going to have to add an option to the recipient providers to turn this check off on a per job basis (and possibly globally) as there will be cases where people have commit access but don't have a jenkins user ie jenkins.ci.cloudbees.com and should still get emails and I don't think the current system property to turn the check off is sufficent
I wonder whether we can allow users with User#canDelete() == true as recipients. Those are accounts actually configured in and persisted by Jenkins (rather than ephemeral by parsing changelogs since Jenkins started).
Of course, SECURITY-372 as reported included emails mistakenly sent to such an account, so should probably be made an opt-in option, if implemented.
Related to this I would like to be able to have Jenkins send email to a mailing list. It seems that this isn't possible with this new security fix.
It seems that this isn't possible with this new security fix.
jpschewe Please file a new issue with reproduction steps for this. This change should only affect email addresses gathered from the changelog ("culprits" etc.), not fixed recipients configured for the build step.
its a service account/shared mailbox it has never logged into jenkins (LDAP auth to AD). I assume it is because it's never been logged into so never been flagged correctly as a user coming from the security provider?
Sounds like a problem in your LDAP configuration to me, or perhaps in the ldap plugin. Changelog generation will look for a User. If your security realm is working correctly, and that actual person is known to LDAP, then that authentication ought to be found.
I added hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS to process's parameters:
/usr/lib/jvm/default-java/bin/java -XX:MaxPermSize=1024m -Dorg.eclipse.jetty.server.Request.maxFormContentSize=500000 -Dhudson.security.csrf.requestfield=Jenkins-Crumb -Djenkins.install.runSetupWizard=false -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpListenAddress=127.0.0.1 --httpPort=9090 --ajp13Port=-1 -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true
Unfortunately Jenkins still cannot send emails to users:
10:54:38 Not sending mail to unregistered user valid.user1@example.org
10:54:38 Not sending mail to unregistered user adam.gabrys@example.org
The job was build on a slave machine. Should I also add this parameter to slaves' processes?
agabrys System properties need to be between "java" and "-jar", otherwise they're program arguments and don't work for the intended purpose.
Please ask for help in appropriate channels, such as IRC or the jenkinsci-users mailing list (when it's back from Google's stupid spam filter).
I have the same problem but I don't have the email extension plugin installed.
Using Jenkins ver. 1.651.
Where else could I look for a solution?
gmiller Mailer Plugin had the same problem, and received a very similar fix.
https://plugins.jenkins.io/mailer#Mailer-Version1.20%28Mar20,2017%29
So in our case we're using ldap and git such that Jenkins user ids and git commit authors are both email (with mail={0} for ldap authentication), seems odd that we'd need to add a default suffix when the information from git should actually have the correct suffix as well.
Could we have options in jenkins configuration for hudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS and hudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ?
I don't have access to jenkins startup options, so the only option for me to fix emails is to downgrade email plugins.
I don't have access to jenkins startup options
Why? There are lots of things controlled by system property. You can also configure these via /script console or init.groovy.
I have learnt that after updating the git configuration to the user used by LDAP, an email can be sent out without a problem:
git config --global user.name [YOUR_LDAP_USER]
In our case, the same LDAP user is also registered with GitHub.
We are using subversion and having the same issue. Our users have an authorized ID that differs from the email address listed on their configuration page. All of the users have the same email address configured that it says is unregistered.
Is this issue being worked on? It's been a problem for months, and I really need this to be resolved soon.
Just released a new version that gives a more detailed message that may help identify the problem (configuration or code)
Currently have 2.60.2 and this is still active. My configuration is similar to danielmish. I have a subversion configuration with active directory in use. The email it complains about is a valid email. Seems that a user is created based on a committer in svn, but that is considered the unregistered user.
Right, this issue is SCM-specific. In the case of Subversion, https://github.com/jenkinsci/subversion-plugin/blob/8ef22113a307da105a5d54d7db7ce7b56af85818/src/main/java/hudson/scm/SubversionChangeLogSet.java#L307 is probably too simple – it should try to do more to look up the actual account inside Jenkins.
FWIW if both SVN and Jenkins are backed by the same LDAP, it can work nicely. The problem occurs on mismatch.
danielbeck Just thinking about the mapping thing I think the best solution for this is to add a generic way for users to associate SCM details with their user account that each SCM can extend as required. This would allow users to tell jenkins I am known by this username on all SVN repositories matching this server name/pattern. For git attaching multiple email addresses to an account is probably sufficient.
I am seeing the same issue since the plugin upgrade from v2.57 to v2.57.1.
Scenario: User "xxx" is registered on the Jenkins instance with email "xxx@example.com".
Log contains: "Not sending mail to unregistered user xxx@example.com"