[JENKINS-16332] Leading and trailing underscores are added to commiters email address, unable to send build notification #13210

Activity

1. jenkins-infra-bot commented on Jan 14, 2013

   

   jenkins-infra-bot

   on Jan 14, 2013

   Author

   More actions

   jglick:

   • Original comment link
   • Raw content of original comment:

     The user ID will typically include underscores, but there ought to be a separate email property (shown at /user/*/configure) that includes the original email address. Perhaps this got broken by the recent split of the mailer plugin out of core; definitely assigning of emails to users who sign themselves up in the web UI was broken (fix will be in 1.500), but user creation from SCM changelogs is a different code path. Need to check if it is reproducible.
     

   The user ID will typically include underscores, but there ought to be a separate email property (shown at /user/*/configure) that includes the original email address. Perhaps this got broken by the recent split of the mailer plugin out of core; definitely assigning of emails to users who sign themselves up in the web UI was broken (fix will be in 1.500), but user creation from SCM changelogs is a different code path. Need to check if it is reproducible.
2. jenkins-infra-bot commented on Jan 14, 2013

   

   jenkins-infra-bot

   on Jan 14, 2013

   Author

   More actions

   sgr:

   • Original comment link
   • Raw content of original comment:

     In my case the commiters don't sign up themselves, they don't have Jenkins accounts and cannot login into Jenkins. Emails are extracted from SCM log only.
     

   In my case the commiters don't sign up themselves, they don't have Jenkins accounts and cannot login into Jenkins. Emails are extracted from SCM log only.
3. jenkins-infra-bot commented on Jan 15, 2013

   

   jenkins-infra-bot

   on Jan 15, 2013

   Author

   More actions

   sgr:

   • Original comment link
   • Raw content of original comment:

     The problem has gone after  'sudo service jenkins restart'. 
     

   The problem has gone after 'sudo service jenkins restart'.
4. jenkins-infra-bot commented on Jan 15, 2013

   

   jenkins-infra-bot

   on Jan 15, 2013

   Author

   More actions

   jglick:

   • Original comment link
   • Raw content of original comment:

     Hmm if even @sgr cannot reproduce after restarting Jenkins then it is unlikely I will be able to reproduce either.
     

   Hmm if even @​sgr cannot reproduce after restarting Jenkins then it is unlikely I will be able to reproduce either.
5. jenkins-infra-bot commented on Jan 15, 2013

   

   jenkins-infra-bot

   on Jan 15, 2013

   Author

   More actions

   sgr:

   • Original comment link
   • Raw content of original comment:

     Cannot reproduce
     

   Cannot reproduce
6. jenkins-infra-bot commented on Mar 1, 2013

   

   jenkins-infra-bot

   on Mar 1, 2013

   Author

   More actions

   pykler2:

   • Original comment link
   • Raw content of original comment:

     Try setting up a repo with your username = First MyName <email@email.com>
     
     then make a commit that fails the build, or triggers the email and look at the console log ... it will clearly have underscores instead of <> ... also check the details log as mentioned ... the issue should be visible. We hit this as soon as we upgraded to the lates jenkins.
     

   Try setting up a repo with your username = First MyName

   then make a commit that fails the build, or triggers the email and look at the console log ... it will clearly have underscores instead of <> ... also check the details log as mentioned ... the issue should be visible. We hit this as soon as we upgraded to the lates jenkins.
7. jenkins-infra-bot commented on Mar 1, 2013

   

   jenkins-infra-bot

   on Mar 1, 2013

   Author

   More actions

   jglick:

   • Original comment link
   • Raw content of original comment:

     Still cannot reproduce. Using 1.505-SNAPSHOT (Mailer Plugin 1.4 was bundled) and dev version of Mercurial plugin, created a Maven job based on a new Hg repo created from a quickstart archetype, built it. Committed a test failure where my ~/.hgrc has
     
     
     [ui]
     username = Jesse Glick <jglick@netbeans.org>
     
     
     and checked changelog. http://localhost:8080/user/Jesse%20Glick%20_jglick@netbeans.org_/configure now has Your name set to Jesse Glick <jglick@netbeans.org> and E-mail address set to jglick@netbeans.org, as expected.
     (Again it is normal for http://localhost:8080/user/Jesse%20Glick%20_jglick@netbeans.org_/ to show Jesse Glick <jglick@netbeans.org> as the display name followed by Jenkins User Id: Jesse Glick jglick@netbeans.org since IDs are always escaped to not contain dangerous characters such as <, but this should not affect mail delivery or other functions since the email address is stored as a user property.)
     Also installed email-ext plugin, added an Unstable trigger to send to committers, committed another test failure and built again. Log showed
     
     Sending email to: jglick@netbeans.org
     
     
     as expected (I did not configure SMTP so did not check that it really sent mail).
     If you can still reproduce an issue with the latest versions of the Mercurial plugin, Jenkins core, and the Mailer plugin (now responsible for email address maintenance in a User), feel free to debug and file a pull request with a fix.
     

   Still cannot reproduce. Using 1.505-SNAPSHOT (Mailer Plugin 1.4 was bundled) and dev version of Mercurial plugin, created a Maven job based on a new Hg repo created from a quickstart archetype, built it. Committed a test failure where my ~/.hgrc has

   [ui]
   username = Jesse Glick 
   

   and checked changelog. http://localhost:8080/user/Jesse%20Glick%20_jglick@​netbeans.org_/configure now has Your name set to Jesse Glick and E-mail address set to jglick@​netbeans.org, as expected.

   (Again it is normal for http://localhost:8080/user/Jesse%20Glick%20_jglick@​netbeans.org_/ to show Jesse Glick as the display name followed by Jenkins User Id: Jesse Glick jglick@​netbeans.org since IDs are always escaped to not contain dangerous characters such as <, but this should not affect mail delivery or other functions since the email address is stored as a user property.)

   Also installed email-ext plugin, added an Unstable trigger to send to committers, committed another test failure and built again. Log showed

   Sending email to: jglick@​netbeans.org
   

   as expected (I did not configure SMTP so did not check that it really sent mail).

   If you can still reproduce an issue with the latest versions of the Mercurial plugin, Jenkins core, and the Mailer plugin (now responsible for email address maintenance in a User), feel free to debug and file a pull request with a fix.
8. jenkins-infra-bot commented on Mar 3, 2013

   

   jenkins-infra-bot

   on Mar 3, 2013

   Author

   More actions

   sgr:

   • Original comment link
   • Raw content of original comment:

     After upgrading Jenkins to version 1500 the issue has gone.
     

   After upgrading Jenkins to version 1500 the issue has gone.
9. jenkins-infra-bot commented on Apr 19, 2013

   

   jenkins-infra-bot

   on Apr 19, 2013

   Author

   More actions

   gzilla:

   • Original comment link
   • Raw content of original comment:

     I hope it's ok to reopen this, because I'm also seeing the same issue and have not seen it go away across jenkins upgrades.  I'm currently running version 1.511-1.1 on a RHEL 5 system, using the officially supplied rpm.  I also he emailext plugin, in case that has anything to do with this.  There are not full user accounts that were explicitly registered with passwords.  These are all auto-created users from the mercurial SCM change sets.
     
     My main concern with this bug is that submitters are no longer receiving email notifications when the build fails.
     

   I hope it's ok to reopen this, because I'm also seeing the same issue and have not seen it go away across jenkins upgrades. I'm currently running version 1.511-1.1 on a RHEL 5 system, using the officially supplied rpm. I also he emailext plugin, in case that has anything to do with this. There are not full user accounts that were explicitly registered with passwords. These are all auto-created users from the mercurial SCM change sets.

   My main concern with this bug is that submitters are no longer receiving email notifications when the build fails.
10. jenkins-infra-bot commented on Apr 19, 2013

    

    jenkins-infra-bot

    on Apr 19, 2013

    Author

    More actions

    sgr:

    • Original comment link
    • Raw content of original comment:

      This issue happen again 1 week ago on the latest version of Jenkins.
      

    This issue happen again 1 week ago on the latest version of Jenkins.
11. jenkins-infra-bot commented on Apr 20, 2013

    

    jenkins-infra-bot

    on Apr 20, 2013

    Author

    More actions

    sgr:

    • Original comment link
    • Raw content of original comment:

      Another incident happened in Jenkins 1.511. The build was triggered by an SCM change (Mercurial), culrprits have received emails, but the commiter didn't recieve the email because Jenkins appended leading and trailing underscores to his email address
      
      Apr 20, 2013 5:22:04 PM hudson.plugins.emailext.ExtendedEmailPublisher addAddressesFromRecipientList
      WARNING: Could not create email address.
      javax.mail.internet.AddressException: Domain contains illegal character in string ``_developer@yyyy.com_''
              at javax.mail.internet.InternetAddress.checkAddress(InternetAddress.java:1269)
              at javax.mail.internet.InternetAddress.parse(InternetAddress.java:1091)
              at javax.mail.internet.InternetAddress.parse(InternetAddress.java:633)
              at javax.mail.internet.InternetAddress.parse(InternetAddress.java:610)
              at hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(EmailRecipientUtils.java:33)
              at hudson.plugins.emailext.ExtendedEmailPublisher.addAddressesFromRecipientList(ExtendedEmailPublisher.java:706)
              at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:522)
              at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:304)
              at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:296)
              at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:256)
              at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
              at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
              at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
              at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
              at hudson.model.Run.execute(Run.java:1620)
              at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
              at hudson.model.ResourceController.execute(ResourceController.java:88)
              at hudson.model.Executor.run(Executor.java:237)
      
      
      
      

    Another incident happened in Jenkins 1.511. The build was triggered by an SCM change (Mercurial), culrprits have received emails, but the commiter didn't recieve the email because Jenkins appended leading and trailing underscores to his email address

    Apr 20, 2013 5:22:04 PM hudson.plugins.emailext.ExtendedEmailPublisher addAddressesFromRecipientList
    WARNING: Could not create email address.
    javax.mail.internet.AddressException: Domain contains illegal character in string ``_developer@​yyyy.com_''
    at javax.mail.internet.InternetAddress.checkAddress(InternetAddress.java:1269)
    at javax.mail.internet.InternetAddress.parse(InternetAddress.java:1091)
    at javax.mail.internet.InternetAddress.parse(InternetAddress.java:633)
    at javax.mail.internet.InternetAddress.parse(InternetAddress.java:610)
    at hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(EmailRecipientUtils.java:33)
    at hudson.plugins.emailext.ExtendedEmailPublisher.addAddressesFromRecipientList(ExtendedEmailPublisher.java:706)
    at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:522)
    at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:304)
    at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:296)
    at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:256)
    at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
    at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
    at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
    at hudson.model.Run.execute(Run.java:1620)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:237)
    
    
    
12. jenkins-infra-bot commented on Apr 25, 2013

    

    jenkins-infra-bot

    on Apr 25, 2013

    Author

    More actions

    jglick:

    • Original comment link
    • Raw content of original comment:

      You can reopen whatever you like, but until someone who is able to reproduce the bug goes through it with a debugger, nothing is going to happen.
      
      By the way I no longer use Mercurial and barely maintain this plugin. If there is someone who does use Mercurial full-time and is proficient at Jenkins plugin development, please consider taking it over.
      

    You can reopen whatever you like, but until someone who is able to reproduce the bug goes through it with a debugger, nothing is going to happen.

    By the way I no longer use Mercurial and barely maintain this plugin. If there is someone who does use Mercurial full-time and is proficient at Jenkins plugin development, please consider taking it over.
13. jenkins-infra-bot commented on May 3, 2013

    

    jenkins-infra-bot

    on May 3, 2013

    Author

    More actions

    sgr:

    • Original comment link
    • Raw content of original comment:

      The body of the email sent by ext-email contains invalid emails.
      
      
      Changes for Build #10770
      [John Doe _dev@xyz.com_] Fixed JUnit tests
      
      However, the Mercurial changeset has a correct email
      
      
      changeset:   71777:dd8d779c3d30
      parent:      71760:76b2fa2dfefb
      user:        John Doe <dev@xyz.com>
      date:        Thu Apr 18 11:30:02 2013 +0300
      summary:     Fixed JUnit tests
      

    The body of the email sent by ext-email contains invalid emails.

    Changes for Build #10770
    [John Doe _dev@​xyz.com_] Fixed JUnit tests

    However, the Mercurial changeset has a correct email

    changeset: 71777:dd8d779c3d30
    parent: 71760:76b2fa2dfefb
    user:John Doe
    date:Thu Apr 18 11:30:02 2013 +0300
    summary: Fixed JUnit tests
14. jenkins-infra-bot commented on May 4, 2013

    

    jenkins-infra-bot

    on May 4, 2013

    Author

    More actions

    sgr:

    • Original comment link
    • Raw content of original comment:

      I have run a script in Jenkins console 
      
      
      import java.util.logging.Logger
      import java.util.logging.Level;
      import hudson.model.*
      import hudson.plugins.emailext.EmailRecipientUtils  
      import hudson.tasks.MailAddressResolver  
      import hudson.model.User  
        
      def mailAddressResolverLogger = Logger.getLogger(MailAddressResolver.class.getName());
      mailAddressResolverLogger.setLevel(Level.FINE)
      
      
      def job = Hudson.instance.getJob("sms-dev-jdk7");  
      def build = job.getBuild("46")
      
      build.culprits.each {   
        def userMailProp = it.properties.find { it.toString().contains('Mailer') }.value	
        println "${it.id} -- ${userMailProp.address}  resolved to  ${MailAddressResolver.resolve(it)}"  
      } 
      
      
      it prints
      
      Igor Ivanov _igor12345@yahoo.com_ -- igor12345@yahoo.com resolved to igor12345@yahoo.com
      John Doe  _dev@xyz.com_ -- John Doe  _dev@xyz.com_ resolved to John Doe  _dev@xyz.com_  
      
      
      So the user object for which Jenkins uses a wrong email, has a different value for email than normal users, see hudson.tasks.Mailer.UserProperty#getAddress.
      For normal users getAddress returns email, while for John Doe not email, but user's id is returned.
      

    I have run a script in Jenkins console

    import java.util.logging.Logger
    import java.util.logging.Level;
    import hudson.model.*
    import hudson.plugins.emailext.EmailRecipientUtils  
    import hudson.tasks.MailAddressResolver  
    import hudson.model.User  
      
    def mailAddressResolverLogger = Logger.getLogger(MailAddressResolver.class.getName());
    mailAddressResolverLogger.setLevel(Level.FINE)
    
    
    def job = Hudson.instance.getJob("sms-dev-jdk7");  
    def build = job.getBuild("46")
    
    build.culprits.each {   
      def userMailProp = it.properties.find { it.toString().contains('Mailer') }.value	
      println "${it.id} -- ${userMailProp.address}  resolved to  ${MailAddressResolver.resolve(it)}"  
    } 
    

    it prints

    Igor Ivanov _igor12345@​yahoo.com_ -- igor12345@​yahoo.com resolved to igor12345@​yahoo.com
    John Doe  _dev@​xyz.com_ -- John Doe  _dev@​xyz.com_ resolved to John Doe  _dev@​xyz.com_  
    
    

    So the user object for which Jenkins uses a wrong email, has a different value for email than normal users, see hudson.tasks.Mailer.UserProperty#getAddress.
    For normal users getAddress returns email, while for John Doe not email, but user's id is returned.
15. jenkins-infra-bot commented on May 4, 2013

    

    jenkins-infra-bot

    on May 4, 2013

    Author

    More actions

    sgr:

    • Original comment link
    • Raw content of original comment:

      I don't think that this bug is mercurial-specific, the script shows that the problem is that Jenkins cannot detect a user's email by user's id, even though the email is the part of the id.
      

    I don't think that this bug is mercurial-specific, the script shows that the problem is that Jenkins cannot detect a user's email by user's id, even though the email is the part of the id.
16. 59 remaining items

    Load more
17. jenkins-infra-bot

    closed this as completedon Feb 24, 2014
18. jenkins-infra-bot commented on Feb 24, 2014

    

    jenkins-infra-bot

    on Feb 24, 2014

    Author

    More actions

    dogfood:

    • Original comment link
    • Raw content of original comment:

      Integrated in  jenkins_main_trunk #3192
           [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id. (Revision fdda9ca65689423794a8378c1f28faca7dffddf0)
      
           Result = SUCCESS
      Jesse Glick : fdda9ca65689423794a8378c1f28faca7dffddf0
      Files : 
      
      	
      test/src/test/java/hudson/model/UserTest.java
      	
      changelog.html
      	
      core/src/main/java/hudson/model/User.java
      
      
      

    Integrated in jenkins_main_trunk #3192
    [FIXED JENKINS-16332] Ensure that User records are saved when the fullName is not recoverable from the id. (Revision fdda9ca)

    Result = SUCCESS
    Jesse Glick : fdda9ca65689423794a8378c1f28faca7dffddf0
    Files :

    • test/src/test/java/hudson/model/UserTest.java
    • changelog.html
    • core/src/main/java/hudson/model/User.java
19. jenkins-infra-bot commented on Feb 25, 2014

    

    jenkins-infra-bot

    on Feb 25, 2014

    Author

    More actions

    cowwoc:

    • Original comment link
    • Raw content of original comment:

      Jesse,
      
      Will this fix jobs where malformed culprits were being copied from earlier builds, or do we need to manually "flush" the job history somehow?
      

    Jesse,

    Will this fix jobs where malformed culprits were being copied from earlier builds, or do we need to manually "flush" the job history somehow?
20. jenkins-infra-bot commented on Feb 25, 2014

    

    jenkins-infra-bot

    on Feb 25, 2014

    Author

    More actions

    jglick:

    • Original comment link
    • Raw content of original comment:

      This fix will not handle all cases involving historical records. If a new build is run after upgrade whose changelog mentions the given committer’s full name, that name will be properly registered and you should not see the problem for that user again. The main problem I can foresee is a build which was failing at the time of upgrade, and continues to fail without new changes being committed (to that or other jobs developed by the same people), and is using an email trigger configured to repeatedly send mail for every unstable build.
      
      Again there are no “malformed” culprits fields here. The culprits list is correct; the problem only arises when the culprits list contains the only record of a given user in the system. You ought to be able to work around the problem for a given user by visiting that user’s page as hyperlinked from a changelog (logged in as an administrator), and explicitly setting a full name (and/or email address).
      

    This fix will not handle all cases involving historical records. If a new build is run after upgrade whose changelog mentions the given committer’s full name, that name will be properly registered and you should not see the problem for that user again. The main problem I can foresee is a build which was failing at the time of upgrade, and continues to fail without new changes being committed (to that or other jobs developed by the same people), and is using an email trigger configured to repeatedly send mail for every unstable build.

    Again there are no “malformed” culprits fields here. The culprits list is correct; the problem only arises when the culprits list contains the only record of a given user in the system. You ought to be able to work around the problem for a given user by visiting that user’s page as hyperlinked from a changelog (logged in as an administrator), and explicitly setting a full name (and/or email address).
21. jenkins-infra-bot commented on Feb 25, 2014

    

    jenkins-infra-bot

    on Feb 25, 2014

    Author

    More actions

    cowwoc:

    • Original comment link
    • Raw content of original comment:

      I see. So just to make sure I understand correctly:
      
      Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs. Alternatively, deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.
      
      Is that correct?
      

    I see. So just to make sure I understand correctly:

    Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs. Alternatively, deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.

    Is that correct?
22. jenkins-infra-bot commented on Feb 25, 2014

    

    jenkins-infra-bot

    on Feb 25, 2014

    Author

    More actions

    jglick:

    • Original comment link
    • Raw content of original comment:

      Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs.
      
      Right. You can simply look in $JENKINS_HOME/users/ to see whether the user has been defined or not.
      
      deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.
      
      No. If you deleted all historical builds, then either the next build has commits from the relevant user(s), in which case their email addresses will be recorded; or it does not, in which case the culprits list for that build will simply be empty and no email will be sent (unless you have an unconditional recipient configured in the job). In the former case, deleting the old build records does not improve your situation at all. In the latter case, deleting them could make the new build’s status be “unstable” due to test failures or whatever, rather than “failed” due to an attempt to send mail to bogus addresses, but the email addresses of users mentioned in those old builds would still be missing.
      

    Until a user makes a new commit, any existing jobs will keep on using the incorrect email address. Once a user makes a new commit, his email address will get corrected system-wide across all jobs.

    Right. You can simply look in $JENKINS_HOME/users/ to see whether the user has been defined or not.

    deleting the contents of the "builds" directory will remove all changelogs and force re-evaluation of the email address.

    No. If you deleted all historical builds, then either the next build has commits from the relevant user(s), in which case their email addresses will be recorded; or it does not, in which case the culprits list for that build will simply be empty and no email will be sent (unless you have an unconditional recipient configured in the job). In the former case, deleting the old build records does not improve your situation at all. In the latter case, deleting them could make the new build’s status be “unstable” due to test failures or whatever, rather than “failed” due to an attempt to send mail to bogus addresses, but the email addresses of users mentioned in those old builds would still be missing.
23. jenkins-infra-bot commented on Apr 7, 2014

    

    jenkins-infra-bot

    on Apr 7, 2014

    Author

    More actions

    olivergondza:

    • Original comment link
    • Raw content of original comment:

      Fixed in 1.554. No need to backport.
      

    Fixed in 1.554. No need to backport.
24. jenkins-infra-bot

    added

    bugFor changelog: Minor bug. Will be listed after featuresFor changelog: Minor bug. Will be listed after features

    imported-jira-issue

    component:core

    priority:major

    resolution:fixed

    on Nov 24, 2025
25. jenkins-infra-bot commented on Nov 24, 2025

    

    jenkins-infra-bot

    on Nov 24, 2025

    Author

    More actions

    [Original is_duplicated_by from Jira: JENKINS-15253]
26. jenkins-infra-bot

    added the

    Bug

    issue type on Nov 25, 2025
27. jenkins-infra-bot

    removed

    bugFor changelog: Minor bug. Will be listed after featuresFor changelog: Minor bug. Will be listed after features

    on Nov 25, 2025