Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-31238

Exchange with authentication requires From address matches the authenticated user

      I upgraded from 4.4.1 to 5.2.4 and I have enabled sending email but not reading email with:

      DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=false - Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true"
      

      Sending email with no authentication via Exchange works fine. But using authentication produces the message

      An error has occurred with sending the test email:
      com.atlassian.mail.MailException: com.sun.mail.smtp.SMTPSendFailedException: 550 5.7.1 Client does not have permissions to send as this sender
      

      Googling found http://community.office365.com/en-us/forums/160/p/77364/296367.aspx#296367 which suggests that this is a response from Exchange when the From address doesn't match the userid that authenticated with Exchange.

      Sure enough, when I changed the From address in my mail server configuration to match the user id that authenticated with Exchange, it worked.

      This regression is likely going to be a problem for people who have been using different From addresses for each JIRA project in their Notification Scheme configuration (https://confluence.atlassian.com/display/JIRA/Configuring+Email+Notifications#ConfiguringEmailNotifications-Configuringaproject'semailaddress)

      More information at https://answers.atlassian.com/questions/114796/jira-unable-to-send-mail-after-5-2-upgrade?page=1#123213

      Workaround
      Please refer to 550 5.7.1 Unable to Relay Mail From Exchange Server for a list of symptoms and the resolution.

            [JRASERVER-31238] Exchange with authentication requires From address matches the authenticated user

            Ornaldo added a comment - - edited

            Hello dears,

            I was looking for an issue that we have with our Jira Server and i found this topic. We have the same error. If we try to authenticate with a normal user and try to send mail we have error:

            An error has occurred with sending the test email:

            com.atlassian.mail.MailException: com.sun.mail.smtp.SMTPSendFailedException: 550 5.7.1 Client does not have permissions to send as this sender

            But if we try to authenticate with a domain admin the error is gone and the mail is working fine.

            If we try to change the From address in my mail server configuration to match the user id that authenticated with Exchange, it's not working .If we try to change the From address in my mail server configuration to match the domain user admin id that authenticated with Exchange, it's working 

            Please could you help us solving this issue?

            Thank You

            Ornaldo added a comment - - edited Hello dears, I was looking for an issue that we have with our Jira Server and i found this topic. We have the same error. If we try to authenticate with a normal user and try to send mail we have error: An error has occurred with sending the test email: com.atlassian.mail.MailException: com.sun.mail.smtp.SMTPSendFailedException: 550 5.7.1 Client does not have permissions to send as this sender But if we try to authenticate with a domain admin the error is gone and the mail is working fine. If we try to change the From address in my mail server configuration to match the user id that authenticated with Exchange, it's not working .If we try to change the From address in my mail server configuration to match the domain user admin id that authenticated with Exchange, it's working  Please could you help us solving this issue? Thank You

            Hi,

            Just re-triaging this issue in light of a recent update.

            We have already investigated this behaviour in the past as part of addressing JRA-34817 and as per jgarcia's last comments on this issue, this behaviour has nothing to do with JIRA and it is actually a result of mail server configuration to avoid spam being sent with spoofed addresses. This is a limitation imposed by the mail server for security reasons and not by JIRA.

            Following on there is a suggestion open to be able to link a complete email account per project such that you can customise the from address with a different email address per project and not run into issues with the mail server at JRA-43109 This might be of interest to some of the watchers on this issue.

            In summary, the requirement that the from address matches the user used to connect to the mail account is not imposed by JIRA but by the mail server so there's nothing that can be fixed in JIRA to prevent that.

            Regards,

            Oswaldo Hernández.
            JIRA Bugmaster.
            [Atlassian].

            Oswaldo Hernandez (Inactive) added a comment - - edited Hi, Just re-triaging this issue in light of a recent update. We have already investigated this behaviour in the past as part of addressing JRA-34817 and as per jgarcia 's last comments on this issue, this behaviour has nothing to do with JIRA and it is actually a result of mail server configuration to avoid spam being sent with spoofed addresses. This is a limitation imposed by the mail server for security reasons and not by JIRA. Following on there is a suggestion open to be able to link a complete email account per project such that you can customise the from address with a different email address per project and not run into issues with the mail server at JRA-43109 This might be of interest to some of the watchers on this issue. In summary, the requirement that the from address matches the user used to connect to the mail account is not imposed by JIRA but by the mail server so there's nothing that can be fixed in JIRA to prevent that. Regards, Oswaldo Hernández. JIRA Bugmaster. [Atlassian] .

            MattS added a comment -

            And using an unauthenticated sender means I can't get Exchange to relay email to addresses outside the domain. So JIRA can't be used as a service desk for some of my clients. Which is a blocker for them.

            MattS added a comment - And using an unauthenticated sender means I can't get Exchange to relay email to addresses outside the domain. So JIRA can't be used as a service desk for some of my clients. Which is a blocker for them.

            MattS added a comment -

            John, mail configuration is always fiddly I reckon (and Exchange also has knobs to tweak to allow this), but the problem is that the behaviour changed between 4.4 and 5.2. I have two systems in parallel. The per-project From Address works in 4.4 with authenticated senders. In 5.2 it doesn't work for me, so I have to use an unauthenticated sender.

            MattS added a comment - John, mail configuration is always fiddly I reckon (and Exchange also has knobs to tweak to allow this), but the problem is that the behaviour changed between 4.4 and 5.2. I have two systems in parallel. The per-project From Address works in 4.4 with authenticated senders. In 5.2 it doesn't work for me, so I have to use an unauthenticated sender.

            From experience, I've always had to use an Open Relay to do mail address spoofing. I think the behaviour we're seeing from gMail and Exchange is normal program behaviour to prevent third parties using their (in gMail's case) or your (in Exchange's case) server to send a fusillade of spam with spoofed addresses.

            In Windows Server, I've always had great luck with configuring IIS's integrated SMTP server as the MTA for JIRA, because I can set it to Open Relay and put only localhost on the whitelist.

            John Garcia (Inactive) added a comment - From experience, I've always had to use an Open Relay to do mail address spoofing. I think the behaviour we're seeing from gMail and Exchange is normal program behaviour to prevent third parties using their (in gMail's case) or your (in Exchange's case) server to send a fusillade of spam with spoofed addresses. In Windows Server, I've always had great luck with configuring IIS's integrated SMTP server as the MTA for JIRA, because I can set it to Open Relay and put only localhost on the whitelist.

            I've flagged this as needing verification so we can determine which version is first affected.

            Eric Dalgliesh added a comment - I've flagged this as needing verification so we can determine which version is first affected.

            MattS added a comment -

            Odd. But the configurable Sender per JIRA project has been around for a while, so I'd expect it was tested and worked at some point. Just not retested with 5.2

            MattS added a comment - Odd. But the configurable Sender per JIRA project has been around for a while, so I'd expect it was tested and worked at some point. Just not retested with 5.2

            It surprises me that this would just show up. I don't think we have ever handled this case specially (that is, I would have expected it to not work in all versions of JIRA).

            Eric Dalgliesh added a comment - It surprises me that this would just show up. I don't think we have ever handled this case specially (that is, I would have expected it to not work in all versions of JIRA).

            MattS added a comment -

            Hmm, this didn't used to be the case with JIRA 4.x, and it makes the Sender configuration for each project useless. Is that feature no longer supported?

            MattS added a comment - Hmm, this didn't used to be the case with JIRA 4.x, and it makes the Sender configuration for each project useless. Is that feature no longer supported?

            ChrisA added a comment -

            Gmail also requires the same rules, unless the From address is already an authorised address in your gmail account.

            ChrisA added a comment - Gmail also requires the same rules, unless the From address is already an authorised address in your gmail account.

              Unassigned Unassigned
              73d805a2526b MattS
              Affected customers:
              7 This affects my team
              Watchers:
              19 Start watching this issue

                Created:
                Updated:
                Resolved: