Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5625

Honor the "Default user e-mail suffix" setting in E-Mail recipients field

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • mailer-plugin
    • None

      There is a setting called "Default user e-mail suffix" under Manage Hudson->Configure System that allows you to set a default suffix to append to the end of email addresses, for example if you set it as "@example.com" and then in your projects you set email recipient to be "foo" it used to send the email to "foo@example.com". This setting is no longer honored and now the attempt to send the email is sent to just "foo" which of course fails.

      I am unsure which version this started to fail in but it has been within the last few releases. It affects the current 1.345 and also affected 1.344 for sure.

          [JENKINS-5625] Honor the "Default user e-mail suffix" setting in E-Mail recipients field

          km added a comment -

          After talking to Kohsuke, it was clear that it never worked that way. That is, the code was never written to append default suffix to recipients (without the suffix). The recipients are supposed to be "users" in the system and as such their email addresses are derived separately. So, what this bug turns out to be is an enhancement request in that if the default suffix is provided and recipients' list contains a stray email address, then the email address should be formed by concatenation.

          Just curious – you said you were able to see this working like you say – i.e. email was sent to recipient.default-suffix. Do you remember which version it was, and more importantly that your mail server did not alias the email address you sent it to? (e.g. "joe" is not an invalid email address if your mail server aliases it to joe@somedomain).

          km added a comment - After talking to Kohsuke, it was clear that it never worked that way. That is, the code was never written to append default suffix to recipients (without the suffix). The recipients are supposed to be "users" in the system and as such their email addresses are derived separately. So, what this bug turns out to be is an enhancement request in that if the default suffix is provided and recipients' list contains a stray email address, then the email address should be formed by concatenation. Just curious – you said you were able to see this working like you say – i.e. email was sent to recipient.default-suffix. Do you remember which version it was, and more importantly that your mail server did not alias the email address you sent it to? (e.g. "joe" is not an invalid email address if your mail server aliases it to joe@somedomain).

          mjparme added a comment -

          I don't remember which version it started not working on; it was a long time ago (originally opened in the pre-Jira bug tracker).

          However, you are probably right that it was my mail server that was appending the domain to the username. I didn't think of that

          It is a corporate exchange server so I would have no knowledge if some configuration change occurred that made it stop doing that.

          I probably confused a mail server config change with a hudson change.

          mjparme added a comment - I don't remember which version it started not working on; it was a long time ago (originally opened in the pre-Jira bug tracker). However, you are probably right that it was my mail server that was appending the domain to the username. I didn't think of that It is a corporate exchange server so I would have no knowledge if some configuration change occurred that made it stop doing that. I probably confused a mail server config change with a hudson change.

          kutzi added a comment -

          Changed issue type and summary according to previous comments.

          kutzi added a comment - Changed issue type and summary according to previous comments.

          Neon Ngo added a comment -

          If the "Default user e-mail suffix" field is NOT fixed, then it should probably be DISABLED until it is fixed or REMOVED to prevent confusion.

          Neon Ngo added a comment - If the "Default user e-mail suffix" field is NOT fixed, then it should probably be DISABLED until it is fixed or REMOVED to prevent confusion.

          Alex Earl added a comment -

          I'm pretty sure this is working now, can you test?

          Alex Earl added a comment - I'm pretty sure this is working now, can you test?

          Hi slide_o_mix
          I was trying this out. And it is not working. However, if you go to the user list and configure the emails for the users then the email is sent.

          siddharth bisht added a comment - Hi slide_o_mix I was trying this out. And it is not working. However, if you go to the user list and configure the emails for the users then the email is sent.

          Alex Earl added a comment -

          I just tried this and it worked for me. Maybe you can give more information (build log) or something?

          Alex Earl added a comment - I just tried this and it worked for me. Maybe you can give more information (build log) or something?

          We updated to Jenkins v2.8 two days ago and the option default user e-mail suffix does not work.

          It works full qualified alexander.schael@deutschebahn.com but not by setting @deutschebahn.com as default user e-mail suffix at the global Jenkins configuration and enter alexander.schael as recipient in the job. There is even no log-entry. It just does not write the mail!

          Alexander Schäl added a comment - We updated to Jenkins v2.8 two days ago and the option default user e-mail suffix does not work. It works full qualified alexander.schael@deutschebahn.com but not by setting @deutschebahn.com as default user e-mail suffix at the global Jenkins configuration and enter alexander.schael as recipient in the job. There is even no log-entry. It just does not write the mail!

            Unassigned Unassigned
            mjparme mjparme
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: