Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rejects valid emails #43

Open
bk2204 opened this issue Jul 2, 2021 · 1 comment
Open

Rejects valid emails #43

bk2204 opened this issue Jul 2, 2021 · 1 comment

Comments

@bk2204
Copy link

bk2204 commented Jul 2, 2021

The EmailAddress class uses the fast_chemail crate, which rejects emails that are valid according to RFCs 5322 and 6532:

    use async_smtp::EmailAddress;

    #[test]
    fn accepts_valid_email_addresses() {
        assert!(EmailAddress::new(r#""deliver able"@example.crustytoothpaste.net"#.into()).is_ok());
        assert!(EmailAddress::new("🔵@example.crustytoothpaste.net".into()).is_ok());
        assert!(EmailAddress::new("pingüino@example.crustytoothpaste.net".into()).is_ok());
        assert!(EmailAddress::new("sandals@example.crustytoothpaste.net".into()).is_ok());
    }

All of these addresses are deliverable (to me) if you remove the example.. Only the last is accepted.

Moreover, it appears that this library intentionally does not support the full range of valid email addresses:

A library to validate the email as it is defined in the HTML specification. The RFC 5322 is too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use.

I should point out that the HTML specification is not involved in the sending of email and therefore what it defines as a valid email is totally irrelevant. Moreover, SMTPUTF8 is seeing increasing adoption, and the HTML specification rejects all internationalized email addresses, which is unhelpful since most people on the planet don't speak English at all.

A different implementation, supporting the full range of options specified in RFC 6532, should be used instead.

@Jikstra
Copy link
Contributor

Jikstra commented Aug 11, 2021

Could be fixed by c880062 @link2xt ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants