A few years back, the Army finished its migration to the DoD Enterprise email solution based on Microsoft solutions to meet a number of accessibility and security requirements. There were many complaints from users across the board, myself included. Years later, I'm still complaining.

Is it really that hard to implement an automatic server redirection policy so that various old or unmaintained links within DISA's infrastructure actually get you to the right server without requiring continuous clicking? A 301 redirect is a pretty straightforward practice recognized everywhere apparently except for DoD Enterprise email. It's pretty well documented in the IETF RFC 2616 for Hypertext Transfer Protocol -- HTTP/1.1. There are also pretty easy, official guides on configuring IIS servers or Apache servers for this behavior. Let's walk through a basic example:

Step One: For starters, a user can simply log into AKO at https://www.us.army.mil. At the top, the user is offered a button to take them directly to their AKO email:

Step Two: Clicking on that button, takes the user to an informational page at https://www.us.army.mil/suite/portal/defaulthomepage.do# that recommends bookmarking and browsing to the new link at https://web.mail.mil. While its nice of DISA to tell me for the past several years that email is no longer managed by AKO, frankly, not one user actually cares. Clicking on the "email" link pretty much signified the intent to see actual email. Perform a 3xx series redirect!

Step Three: Following the provided link takes the user to a standard, government warning and consent banner. One would think at this point that simply acknowledging the warning, clicking OK, and following the credentials validation process would get them to their email.

Step Four: After logging in, the system tells the user this server is basically not optimal and that performance would best be found at https://web-mech02.mail.mil/owa. For the record, the system used to recommend https://web-cols02.mail.mil/owa but recently made this change to another name. This should have been handled by the server with a redirect especially as the nuance of which particular hostname-du-jour chosen by DISA is not a concern of the user. Furthermore, this implies there are additional, lower performance server options. But whether there are additional hosts that are not recommended is irrelevant information as the user does not care. The user wants to click on "email" and get their email. Perform a 3xx series redirect!

Step Five: Clicking the link, the user expects to finally be taken to the recommended server. Unfortunately, most AKO users are all too familiar with getting the access policy evaluation error message. Since most users are still in the only open browser tab, users resign themselves to clicking and creating a new session. But it begs the question, if the solution is pretty much to always follow the link and create the new session ... why not use a server side redirect? Make the error transparent to the user? Perform a 3xx series redirect!

Step Six: Once again, the user manually follows the link. Instead of getting the government warning and consent banner, many users are probably pretty familiar with getting other errors between their browser and the AKO servers.

Step Seven: Feeling angry at this point, many users try and go directly the server. Perhaps they try a URL that would be intuitively obvious to basically every user alive - http://mail.mil - because why not, that's basically the extension on all Army AKO accounts. It's also the great premise behind DNS, that a user knows a simple name and the backend infrastructure identifies the host they really want to find. Other than DISA, who wouldn't think mail.mil is more obvious than web-mech02.mail.mil? Perform a 3xx series redirect!

Despite owning the mail.mil domain, the Enterprise solution is incapable of receiving a request to the unencrypted port 80 and redirecting users to use SSL over 443. Even better would be not only redirecting to an SSL port but taking users from mail.mil to web-mech02.mail.mil. Perform a 3xx series redirect!

Step Eight Option One: The user realizes they forgot the "s" in https://, so a manual fix to the URL brings them to https://mail.mil which lovingly presents a failed certificate. If the mail.mil server is not supposed to be the target for actually accessing AKO, then it really begs the question, why is it even serving up bad certificates? And if the server is live, would it not be easier to serve up a valid redirection? Perform a 3xx series redirect!

Step Eight Option Two: What if the user realized on the URL they typed - mail.mil - was the wrong address and instead opted to use web.mail.mil (NOTE: The same one still recommended by AKO itself). The user this time types the recommended address but forgets to use SSL encryption, an error which often brings this lovely error. Once again, the server is functioning enough to provide an error message regarding how busy it is, but can't seem to provide a redirection to simplify the entire process. Maybe the server wouldn't be so busy if people were not hammering away at it trying to figure out which particular AKO box is recommended today. Perform a 3xx series redirect!

Step Nine: At this point, the user may finally have everything right yet again and simply gets stymied by another type of session failure. The solution is provided in a link on the error page to open a new session. PERFORM A 3xx SERIES REDIRECT!!!