Small uncertainty in email restrictions

[potatodudedude]

According to the UG, the domain name must end with at least two characters:

However, an email ending with a-a as the domain name is not valid, even though it is three characters long.

It seems the domain name is only valid when the there are at least 2 characters in a row that are not -.
aa-a and a-aa are both valid.

It seems unlikely a user would be messing around with the email domains like this, but it's probably a good thing to update the restrictions in case a client has some strange obscure email.

[nus-pe-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

I acknowledge that it is good to account for all possible permutations of valid / invalid. However, this is an edge case out of the many possible edge cases when it comes to input validation for emails. Effort is required to deal with each and every edge case when it comes to input validation for emails. We intend to take a closer look at input validation for future iteration.

This is considered NotInScope as rectifying it is less important than the work that has been done already (in accordance with guidelines on CS2103T website). Furthermore, when the user inputs an invalid email, the software fails gracefully with a suitable error message, and does not crash.

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue type

Team chose [type.DocumentationBug]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement: [replace this with your explanation]

---