Kerberos authentication fails if realm is not FQDN

Our Active Directory domain is historically named sa.c, and consequently the AD provides a Kerberos realm named SA.C. This name ostensibly does not play well with GitLab through OmniAuth: an attempt to authenticate ends up in a 422 error page showing the error Sign-in failed because email is invalid, notification_email is invalid. There is a record in GitLab's application.log created at the same time:

(OAuth) Error saving user: ["Email is invalid", "Notification email is invalid"] 

My conjecture is that the Kerberos ID, which has the form user@SA.C, is somehow checked for validity as if it was an email address during account creation, and the code rejects this string in the email and notification_email of the new user record. I came to this assumption when I tried to add user@SA.C as one of my alternative e-mail addresses on the Account page, and got the error that read the same: "Email is invalid".

Below is the relevant snippet of configuration:

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_providers'] = [
  {
    "name" => "kerberos",
    "keytab" => "/etc/gitlab.keytab"
  }
]

Added 150923: Confirmed the source of the problem is email validation by temporarily disabling it in app/models/user.rb:

--- user.rb.bak 2015-09-23 15:33:41.153046701 -0700
+++ user.rb     2015-09-23 15:34:32.044741054 -0700
@@ -144,4 +144,4 @@
   # duplicate that here as the validation framework will have duplicate errors in the event of a failure.
-  validates :email, presence: true, email: { strict_mode: true }
+  validates :email, presence: true
-  validates :notification_email, presence: true, email: { strict_mode: true }
+  validates :notification_email, presence: true
   validates :public_email, presence: true, email: { strict_mode: true }, allow_blank: true, uniqueness: true

With this change, a new user is created just fine with a lowercased version of Kerb ID as their email, user@sa.c.

I have no idea what a permanent fix would look like. It seems that this ball is in your court now.