Incorrect Email Validation and Persistent display of error message on message selection in MailExportForm

[smritidoneria]

Description:

The validateEmail function does not correctly validate email addresses according to the RFC standard. The error message for the messagesCount field is persistently displayed whenever a message is selected.

Steps to reproduce:

1. Go to export messages
2. Write any invalid email.
3. click on send

Expected behavior:

If an invalid email is entered, it should display an error. Additionally, if the message is not selected first and the send button is clicked, it should display an error. However, if the user then selects the message, the error should not be displayed.

Actual behavior:

Screen.Recording.2024-08-03.at.5.15.55.PM.mov

Server Setup Information:

• Version of Rocket.Chat Server: 6.12.0
• License Type: Enterprise
• Number of Users: 2
• Operating System: MacOs
• Deployment Method: Docker
• Number of Running Instances: 2
• DB Replicaset Oplog: Enabled
• NodeJS Version: 14.21.4
• MongoDB Version: 7.0.5

Client Setup Information

• Desktop App or Browser Version: Safari Version 17.5
• Operating System: MacOs

Additional context

Relevant logs:

[smritidoneria]

If the issue is relevant, I want to work upon this

[reetp]

Thanks for reporting.

Server: 6.12.0

I don't think so - 6.11 hasn't been released yet?

Please confirm the version.

function does not correctly validate email addresses

It looks like you mean it does not validate addresses at all?

[smritidoneria]

Rocket chat version-6.10.2

yes, the validator do not seems to render the email address properly

[reetp]

Thanks for your work.

I have requested that this be reviewed.

Please note that this may take some time as it will have to go in the queue with lots of other work.

[casalsgh]

FYI - Community Liaison (reetp) shared this with internal teams and we'll be working on it soon (including review to existing proposed PR)

[Starkz24]

I have solved this issue if this is not resolved till now please assign it to me.

[reetp]

I have solved this issue if this is not resolved till now please assign it to me.

No one assigns issue here.

You are free to work on whatever you want.

However, please see the previous team response.

This already has a PR and is is under review by the team so look at other issues - feature requests is a good place, or look at apps.

[rique223]

Dotless or no TLD emails are valid emails according to the most recent RFC regarding emails (RFC 5322), this is not a bug.

[smritidoneria]

hey @rique223 , according to RFC 5322 , a general email pattern takes this form: local-part@domain

[reetp]

hey @rique223 , according to RFC 5322 , a general email pattern takes this form: local-part@domain

Said it once. Please don't keep using @

People will get notifications regardless.

Thanks.

[rique223]

hey @rique223 , according to RFC 5322 , a general email pattern takes this form: local-part@domain

Exactly, and the email in your video follows this pattern, was it supposed to be an example of an invalid email?

[Starkz24]

I have linked a pull request #33012 can you check that this resolve the problem

[reetp]

As per the comment here

#32974 (comment)

Dotless or no TLD emails are valid emails according to the most recent RFC regarding emails (RFC 5322), this is not a bug.

And here:

#33012 (comment)

Top-level domains (.com, .org, etc) are not mandatory for an email to be considered valid, there is no need to change this regex as this was a purposeful decision on email validation done by our engineering team.

Although it seems a bit incongruous, user@domain is valid according to RFC 5322 and therefore this is not a bug and should be closed.

[github-actions]

This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.