Support

Can you please check your email template? Maybe you have added the domain name manually? I am suspecting that because the code which produces the link to the ticket is actually the same in all instances. In fact, there's just one piece of code parsing all the email templates for all possible emails sent out when a ticket is created, replied to, assigned or closed. The only variables it accepts is the name of the email template and the ticket object itself. If one email is correct and the other is not then the only reasonable culprit can be the email template.

With a post from the back-end, the link is NOT using SEF

All URLs are passed through Joomla!'s JRoute::_() routing API. For reasons that have to do with how Joomla! works SEF URLs are only generated in the front-end. The back-end can not and will not generate SEF URLs. There's no workaround to that (unless we rewrite Joomla! from top to bottom).

The problem is, with back-end created links (not SEF), after I log in, I am directed to the home page, not the ticket. While SEF versions of the same link, work as expected.

Yes, definitely a 3PD extension. The definitive URL for anything running inside Joomla! is the non-SEF one. I would understand it if the SEF URL didn't work but the non-SEF one did. After all Joomla! translates the SEF URL to a non-SEF one to show you the pages. So what happened screamed "some 3PD extensions is killing my site" ;)

We are using ssl on the back-end of a site and not on the front-end (at least not every page)

If I post to a ticket on the back-end - using ssl, the link for the user in the email has https:// - I would imagine a setting similar to the global params, asking if the link should use SSL or not (although this is not a major issue, I thought I'd bring it to your attention)

I have intentionally NOT added and will NOT add such a parameter. If you've gotten to the trouble of implementing SSL then implement it throughout your site (front-end and back-end). Otherwise your site is just as good as not enabling SSL at all for these reasons:

• Front-end login. If you login to the front-end with the credentials of a user with back-end access consider your back-end compromised. A man in the middle attack can easily trick you into running Javascript to steal your login information even though you might be accessing the login page via SSL (all other pages on the site are not SSL, therefore as easily modifiable en route as the writing on a postcard)
• Cookie HTTPS flag. Without explicit SSL throughout you get a cookie which is valid for both the plain HTTP and encrypted HTTPS version of your site. Stealing that cookie is trivial for anyone on the same network as you. If you have ever used any of your devices on public WiFi or allow guest connections on any network you've used you are vulnerable to this attack.
• With HTTPS throughout you can enable HSTS. With HSTS it's perfectly sure that your browser will never, ever try to contact your site over HTTP. This mitigates a whole lot of potential security issues. Without it it's possible for you to see an HTTPS URL in the browser's address bar which has nevertheless come as a redirection from accessing an HTTP URL, usually without noticing. That first request to HTTP before you get redirected back to HTTPS can reveal a whole lot of information, including your login cookie under certain conditions.

Since we are a web site security company first and foremost we cannot possibly implement a feature which is telling our clients to actively degrade their security. I understand why you'd want it, but it's for all the wrong reasons. Think of it as a car's e-brake not engaging at speeds over 6 MPH (at least my car has this feature): it's designed to protect you from yourself.