jstedfast / emailvalidation Goto Github PK

It would be great if the NuGet package was updated to reflect the latest changes.

I am using version 1.0.4 and noticed that domains with fewer then 2 chars are not detected as invalid.
e.g. [email protected]

I found there is already a fix checked in for top-level domains cannot be fewer than 2 characters, but it is not released yet.
298cd95

Could you make a new release with the latest fixes? Would be really cool :)

john.smith(comment)@example.com
or
(comment)[email protected]

Both are same as [email protected]

Source : https://en.wikipedia.org/wiki/Email_address

Is it possible to disable validation of temp emails like "guerrillamail"

Hi, after searching for a solution I found your awesome nugget!! 🍰

• I was wondering if it checked for all TLD's, and how is that updated everyday I see new ones come out.
• Also can you please consider honeypot as an add-on to this, it would fit naturally.
• And recaptcha

thanks

I would like to use the NuGet package in a project I'm working on, however this project needs to be signed, and as such any references need to be signed as well. Is there any possibility of having the NuGet package signed? I can get the source and sign it myself, but it'd be much more beneficial to keep it pristine and maintain the benefit of simple updates through NuGet.

I would like to suggest the addition of a second class to the project, a ValidationAttribute (something like this) so an user can mark an email property with an Attriute and speed up validation. This is specially useful in MVVM scenarios.

The following calls return true even though the quoted strings contain deprecated characters:

EmailValidator.Validate("\"\u007f\"@test.com");
EmailValidator.Validate("\"\u001f\"@test.com");
EmailValidator.Validate("\"\\\u007f\"@test.com");

As specified by RFC 5321 these fall outside of allowed character codes:

Quoted-string = DQUOTE *QcontentSMTP DQUOTE

QcontentSMTP = qtextSMTP / quoted-pairSMTP

quoted-pairSMTP = %d92 %d32-126
; i.e., backslash followed by any ASCII
; graphic (including itself) or SPace

qtextSMTP = %d32-33 / %d35-91 / %d93-126
; i.e., within a quoted string, any
; ASCII graphic or space is permitted
; without blackslash-quoting except
; double-quote and the backslash itself.

\u007f is DEL (Delete) character (127 decimal ASCII code) which is above the 32-126 range.
\u001f is US (Unit Separator) character (31 decimal ASCII code) which is below the 32-126 range.

Hey @jstedfast,
Can you upload a NuGet package supporting netstandard1.6?

Installing EmailValidation 1.0.2.
Package EmailValidation 1.0.2 is not compatible with netstandard1.6 (.NETStandard,Version=v1.6). Package EmailValidation 1.0.2 supports: portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
One or more packages are incompatible with .NETStandard,Version=v1.6.
Package restore failed. Rolling back package changes for 'XYZ'.

Thanks man, either way!

At least the following two valid E-Mail adresses are not recognized correctly:

üñîçøðé@example.com (Unicode characters in the local part)
"very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com (correct escaping of quotes in the local part)

Please see for reference and additional test cases the list of valid E-Mail addresses at http://en.wikipedia.org/wiki/Email_address

[email protected]
abc."defghi"[email protected]

is that intended?

Hi,

Due to the limitations of .NET's implementation of string with UTF-16, characters from the upper end like "\U00010348" (𐍈) have a length of 2. This unfortunately breaks length checks in the validator.

For example:
"test@𐍈" passes the validation, while other single-character TLD addresses don't
"𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈𐍈@example.com" doesn't pass 64-character local part length check, even though it has 33 characters.

I don't think there is a built-in function to get character count in a string, but maybe char.IsSurrogatePair() will be of use.

The following are valid email adresses but fail the validation:
test@[1.1.1.1]
test@[IPv6:::]
test@[IPv6:::12.34.56.78]
test@[IPv6:::3333:4444:5555:6666:7777:8888]

I suspect that the first two fail because of this check:

// we need at least 8 more characters
if (index + 8 >= email.Length)
    return false;

but I'm not sure about the last two. This one for example passes validation correctly:
test@[IPv6:::b3:b4]

when allowInternational is true, the following string is reported as a valid email (there is a space before the dot):
info@axtur .it

I think is wrong because a domain name doesn't allow space, as reported here:
https://www.dynadot.com/community/blog/domain-name-rules.html

best regards,
LP

Hi,

I have had users enter the following addresses, which the code currently passes as valid.

02102535517@example
094222523example@com
3327156@example

Given the complexity of the relevant RCF specs, I am not sure if these are actually valid or if the system is incorrectly saying they are valid (not my area of expertise). Third party systems we integrate to say they are invalid, and several online validators said they were invalid, but it's possible they don't follow the RFC spec.

Can you advise if these are valid, and if not, how the code should be modified to reject them?

Thanks.

Hi,

As a user of MimeKit I was happy to come across this simple class. I was wondering if you would consider publishing a NuGet package?

Or at worst is there a way to access the same functionalty within MimeKit?

Is it possible to find out the reason why the mail is invalid? Some friendly message...
Thanks.

Hi, are emails:

gü[email protected]
majka.jeż[email protected]
あいうえお@example.com

correct?

Do you really need validationContext not nullable?
We have scenario when validationContext is always null and as far as I investigated code it is possible to let validationContext to be null without any affect for functionality of your component.

In C# I use EmailValidation and in JS I use popular isemail library.

I noticed the following.
In isemail both foo@1111 and foo@1bar are invalid because they start with a digit.
In EmailValidation foo@1111 is invalid but foo@1bar is valid I guess because it contains letters.

I tried to understand who is correct.
According to rfc5321 domain consists of ascii letters, digits and hyphens and nowhere it says that it shouldn't start with a digit or that domain shouldn't consist of digits only.
To me both implementations are too restrictive here.

BTW in JS port you mentioned foo@1111 is considered valid so the port is kind a different

I get the following error after updating (and installing new) 1.0.1 in both Android and iOS projects.

Error Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Portable.DataAnnotations, Version=1.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile?
File name: 'Portable.DataAnnotations.dll'
at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters)
at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(ICollection`1 assemblies, AssemblyDefinition assembly, Boolean topLevel)
at Xamarin.Android.Tasks.ResolveAssemblies.Execute(

I would like to ask about another email address, which makes some issues.

I found that the emails below are treated like proper addresses, but is impossible to send a message:

• email@[123.123.123.123]
• "email"@example.com
• test/[email protected]
• mailhost![email protected]

Same situation but in reverse, this looks like a proper address, but is treated as invalid:

• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com

Would you be able to verify that?

Specifically:

Most (all?) attributes in System.ComponentModel.DataAnnotations of a similar nature to EmailAttribute consider null to be valid.

Examples:

• https://github.com/dotnet/runtime/blob/88868b7a781f4e5b9037b8721f30440207a7aa42/src/libraries/System.ComponentModel.Annotations/src/System/ComponentModel/DataAnnotations/PhoneAttribute.cs#L23-L28
• https://github.com/dotnet/runtime/blob/88868b7a781f4e5b9037b8721f30440207a7aa42/src/libraries/System.ComponentModel.Annotations/src/System/ComponentModel/DataAnnotations/CreditCardAttribute.cs#L18-L23
• https://github.com/dotnet/runtime/blob/88868b7a781f4e5b9037b8721f30440207a7aa42/src/libraries/System.ComponentModel.Annotations/src/System/ComponentModel/DataAnnotations/RegularExpressionAttribute.cs#L63-L67

Generally speaking, one should use RequiredAttribute if a value should not be allowed to be null. (Higher-level frameworks like ASP.NET Core will additionally use C# nullability annotations to infer RequiredAttribute.)

Hi Jeffrey,

Was browsing your repositories (I'm a fan) and came upon this one.

I've been using the IsEmail (of which I stripped the DNS lookup validation) for years and thought I'd ask you how your EmailValidation would compare?

Links:

• http://code.google.com/p/isemail/source/browse/Csharp/trunk/IsEmail/IsEmail.cs
• https://code.google.com/p/isemail/source/browse/Csharp/trunk/IsEmailTests/UnitTests.cs

I've also included a link to IsEmail's unit tests in case you want to look it over and possibly include them.

You could also drop the byte cast in your implementation as I don't see how it has any benefit/effect on the result. E.g.

text[index] == (byte) '\\'

String indexing returns a Char, my gut feel here is that the (byte) '' is then implicitly converted to a Char (again) for comparison.

Keep well.

Kind regards,
Schalk

Hi, I've noticed that these addresses fail to validate but should be allowed under RFC 5322:

EmailValidator.Validate("\"FWS\r\n test\"@iana.org");
EmailValidator.Validate("\"FWS\r\n\ttest\"@iana.org");

I've gathered the necessary definitions from sections 3.4.1

addr-spec       =   local-part "@" domain

local-part      =   dot-atom / quoted-string / obs-local-part

3.2.4

qtext           =   %d33 /             ; Printable US-ASCII
                    %d35-91 /          ;  characters not including
                    %d93-126 /         ;  "\" or the quote character
                    obs-qtext

qcontent        =   qtext / quoted-pair

quoted-string   =   [CFWS]
                    DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                    [CFWS]

3.2.2

FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
                                       ; Folding white space

and RFC 5234 Appendix B.1

CR             =  %x0D
                       ; carriage return

CRLF           =  CR LF
                       ; Internet standard newline
(...)
DQUOTE         =  %x22
                       ; " (Double Quote)
(...)
HTAB           =  %x09
                       ; horizontal tab

LF             =  %x0A
                       ; linefeed
(...)
SP             =  %x20
(...)
WSP            =  SP / HTAB
                       ; white space

This shows that the local-part of an address can be a quoted-string that contains a FWS (Folding white space) anywhere, separated by qcontent. Right now only spaces inside quotes are considered valid by the validator. Spaces alone also form a Folding white space but it can also consist of horizontal tabs and a single Windows-style newline .

I've prepared a few test cases for this. These should validate:

EmailValidator.Validate("\"FWS\ttest\"@iana.org");
EmailValidator.Validate("\" \t\"@iana.org");
EmailValidator.Validate("\" \t\r\n \t\"@iana.org");
EmailValidator.Validate("\"FWS\r\n x\r\n test\"@iana.org");

These should fail:

EmailValidator.Validate("\"FWS\r\ntest\"@iana.org");
EmailValidator.Validate("\"FWS\r test\"@iana.org");
EmailValidator.Validate("\"FWS\n test\"@iana.org");
EmailValidator.Validate("\"FWS\r\n \r\n test\"@iana.org");

The following invalid email addresses are passing validation:

test@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl.com - here the label in domain part is 64 characters long, but according to RFC 2181 a maximum of 63 is allowed.

The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators).

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghij - here total length of the address is 255 but 254 should be the limit, see Errata 1690.

In addition to restrictions on syntax, there is a length limit on
email addresses. That limit is a maximum of 64 characters (octets)
in the "local part" (before the "@") and a maximum of 255 characters
(octets) in the domain part (after the "@") for a total length of 320
characters. However, there is a restriction in RFC 2821 on the length of an
address in MAIL and RCPT commands of 254 characters. Since addresses
that do not fit in those fields are not normally useful, the upper
limit on address lengths should normally be considered to be 254.

It would be great if the NuGet package will be updated to reflect the changes from Is it possible to find out the reason why the mail is invalid? #42.

Hi,

Please correct me if I'm wrong. According to the RFC 5321 section 4.1.3

IPv4-address-literal  = Snum 3("."  Snum)

IPv6-address-literal  = "IPv6:" IPv6-addr

General-address-literal  = Standardized-tag ":" 1*dcontent

Standardized-tag  = Ldh-str
                  ; Standardized-tag MUST be specified in a
                  ; Standards-Track RFC and registered with IANA

dcontent       = %d33-90 / ; Printable US-ASCII
               %d94-126 ; excl. "[", "\", "]"

Snum           = 1*3DIGIT
               ; representing a decimal integer
               ; value in the range 0 through 255

IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp

IPv6-hex       = 1*4HEXDIG

IPv6-full      = IPv6-hex 7(":" IPv6-hex)

IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
               [IPv6-hex *5(":" IPv6-hex)]
               ; The "::" represents at least 2 16-bit groups of
               ; zeros.  No more than 6 groups in addition to the
               ; "::" may be present.

IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
               [IPv6-hex *3(":" IPv6-hex) ":"]
               IPv4-address-literal
               ; The "::" represents at least 2 16-bit groups of
               ; zeros.  No more than 4 groups in addition to the
               ; "::" and IPv4-address-literal may be present.

email addresses like invalid@[IPv6::1::1] should not be valid. IPv6-addr should either start with a HEXDIG or a double colon ::. But in the example that passes the validation it is equal to :1::1 as the colon immediately after IPv6 string is actually part of the prefix defined in IPv6-address-literal .

Hi,
Email address validation fails I try to validate an email address with 64 letters before '@'.
Email address for example: "testaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@outlook.com"
As far as I know, the rfc653x standard allows an email address to contain up to 64 letters before '@' so in this case the validation should succeed and return 'True'.
Could you please look into it?

Thanks,
Yaniv