nus-pe-bot
commented
5 months ago [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
Thank you for reporting the bug. However, we feel that the bug should be rejected as the example given is invalid.
According to RFC 5321 2.3.11 Mailbox and Address, "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server. Hence, a-a-a-a is allowed with certain service providers.
For instance, outlook allows for such an email address:
As the concern seems to be regarding email validation, we also decided to change the label to FeatureFlaw as a-a-a-a@example.com is allowed for email inputs with respect to our validation format.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [ ] I disagree
Reason for disagreement: [replace this with your reason]
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]
Description
Attempted to add an email that should be considered invalid was successful instead. In the case where a user mistypes their email and it ends up in this format, it shouldn't be saved as a valid email.
Steps to reproduce
Launch the application for the first time to load initial data.
Run
add n/Hubert Blaine Wolfeschlegelsteinhausenbergerdorff p/98171731 e/a-a-a-a@example.com a/tampines blk123.Expected behaviour
Error message shown to the user, indicating that the email is invalid.
Actual behaviour
User successfully added despite invalid email address.
Reason for severity
It does not adopt validation of most popular email domain providers.