Acceptance of invalid email address

[T-Wan-Lin]

Sometimes users may accidentally hit enter before they complete the email address. Instead of checking for the presence of @, perhaps you could check if the email at least has a suffix like (.com.sg)

[nus-pe-bot]

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

The email address accepted is not an actual email address

Though its stated in their UG that an email address is only valid in their program if there is a @, but I believe there should be a .edu/.gov/.sg or .com that should be checked

---

_{[original: nus-cs2113-AY2223S2/pe-interim#2843] [original labels: severity.Low type.FeatureFlaw]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Valid email domains need not include those fields, as specified in our UG.

ex) https://en.wikipedia.org/wiki/Email_address

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:**  By going on to any free online email verification website, it is obvious that the user input is not a valid email address. Hence, it becomes apparent that the way the development team checked for invalid email inputs is inadequate.  In the Wikipedia article that the development team has provided in their justification, it is stated that the domain 'has a list of **dot-separated** labels. The development team also justified the rejection of this bug saying that `hello@s` is a valid email input but nowhere in the Wikipedia article was there an example of a valid email address without a dot-separated domain label.  Furthermore, upon research, these are the various forms of **invalid** email addresses, which match the input. For a minimally viable valid email address checker, I feel that the team should have considered IETF standards and checked for some level of dot-separation and domain levels, which does not take much effort as the implementation is similar to that when the team checked for the presence of @ as stated in the UG.

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:**  Per the textbook guidelines, this falls under functionality bug as the program is expected to throw an error message when an invalid email address is an input, which is a reasonable response to possible invalid user inputs.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:**  Mistyping email addresses is a relatable and not-so-rare occurrence in our daily lives. As this application is optimised for fast typers, they may accidentally hit enter before they can finish inputting the email and they would have to find the company and delete it from the list. Such hassle could be avoided if there was a minimally viable valid email address checker to block them from inputting companies with invalid email contact addresses.

---