GithubHelp home page GithubHelp logo

jstedfast / emailvalidation Goto Github PK

View Code? Open in Web Editor NEW
265.0 26.0 72.0 123 KB

A simple (but correct) .NET class for validating email addresses

License: MIT License

C# 100.00%
c-sharp email email-validation

emailvalidation's Introduction

EmailValidation

What is EmailValidation?

A simple (but correct) .NET class for validating email addresses.

Supports Internationalized Mail Address standards (rfc653x).

Installing via NuGet

The easiest way to install EmailValidation is via NuGet.

In Visual Studio's Package Manager Console, enter the following command:

Install-Package EmailValidation

Getting the Source Code

First, you'll need to clone EmailValidation from my GitHub repository. To do this using the command-line version of Git, you'll need to issue the following command in your terminal:

git clone https://github.com/jstedfast/EmailValidation.git

If you are using TortoiseGit on Windows, you'll need to right-click in the directory where where you'd like to clone EmailValidation and select Git Clone... in the menu. Once you do that, you'll get a dialog asking you to specify the repository you'd like to clone. In the textbox labeled URL:, enter https://github.com/jstedfast/EmailValidation.git and then click OK. This will clone EmailValidation onto your local machine.

Updating the Source Code

Occasionally you might want to update your local copy of the source code if I have made changes to EmailValidation since you downloaded the source code in the step above. To do this using the command-line version fo Git, you'll need to issue the following command in your terminal within the EmailValidation directory:

git pull

If you are using TortoiseGit on Windows, you'll need to right-click on the EmailValidation directory and select Git Sync... in the menu. Once you do that, you'll need to click the Pull button.

Building

Open the EmailValidation.sln solution file in Visual Studio, choose the desired build configuration (Debug or Release) and then build.

Note: The Release build will generate the xml API documentation, but the Debug build will not.

Using EmailValidation

This is quite possibly the easiest API ever to use. There is simply 1 class with 1 method.

using System;

using EmailValidation;

namespace Example {
    public class Program
    {
        public static void Main ()
        {
            do {
                Console.Write ("Enter an email address: ");

                var input = Console.ReadLine ();
                if (input == null)
                    break;

                input = input.Trim ();
                Console.WriteLine ("{0} is {1}!", input, EmailValidator.Validate (input) ? "valid" : "invalid");
            } while (true);

            Console.WriteLine ();
        }
    }
}

License Information

EmailValidation is Copyright (C) 2013-2023 Jeffrey Stedfast and is licensed under the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Other Implementations:

If you need an implementation in something other than C#, perhaps one of the following ports will be helpful:

emailvalidation's People

Contributors

0xced avatar azanov avatar dependabot[bot] avatar evanrobertson avatar fredeil avatar jstedfast avatar vcsjones avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

emailvalidation's Issues

Any chance of a NuGet package?

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?

netstandard1.6 support

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!

IPv6 address literals should not start with a single colon

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 .

Some valid domain IP literals fail validation

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]

Nullabe ValidationContext is required

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.

NuGet package update

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

`EmailAttribute` should allow null values

Specifically:

if (value == null)
return new ValidationResult ("Email can't be null", memberNames);

return value != null && EmailValidator.Validate ((string) value, AllowTopLevelDomains, AllowInternational);


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

Examples:

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.)

release fix for max-length bugs

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 :)

allowInternational breaks with four-byte UTF-8 characters

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.

Valid E-Mail addresses aren't recognized

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

Addresses with quoted string with a folding white space fail validation

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");

Incorrect length checking

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.

Question/feedback

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:

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

Add a ValidationAttribute

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.

Digits in domain names clarification

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

Quoted strings with control characters pass validation

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.

Could not load assembly 'Portable.DataAnnotations

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(

Possible Incorrect Validations?

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.

Sign NuGet package

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.

About temp emails

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.