| Copyright | This file is part of the package addy. It is subject to the license terms in the LICENSE file found in the top-level directory of this distribution and at: https://code.devalot.com/open/addy No part of this package including this file may be copied modified propagated or distributed except according to the terms contained in the LICENSE file. |
|---|---|
| License | BSD-2-Clause |
| Safe Haskell | None |
| Language | Haskell2010 |
Addy.Internal.Validation
Description
Internal data validation functions.
Synopsis
- validateHostName :: Text -> Validation (NonEmpty Error) HostName
- validateDomainName :: Text -> Validation (NonEmpty Error) DomainName
- validateLocalPart :: Text -> Validation (NonEmpty Error) LocalPart
- validateDisplayName :: Text -> Validation (NonEmpty Error) DisplayName
- validateLiteral :: Text -> Validation (NonEmpty Error) Literal
- validateAddressTag :: Text -> Validation (NonEmpty Error) AddressTag
- validateCommentContent :: Text -> Validation (NonEmpty Error) CommentContent
- validateEmailAddr :: EmailAddr -> Validation (NonEmpty Error) EmailAddr
Documentation
validateHostName :: Text -> Validation (NonEmpty Error) HostName Source #
Validate a single host name. Each host name in a domain name (referred to as a label) must validate with this function.
RFC 2181 §11 clearly states that there are no restrictions placed on which characters may appear in a label. However, due to legacy issues we enforce the rule from RFC 952 §1 that disallows hyphens as the first or last character of a label.
RFC 5322 §3.4.1 restricts the characters that may appear in the
domain component of an email address. Even though a DNS label
does not impose such restrictions, in order to be a valid email
address the label must only be composed of so-called atext
characters or UTF8-non-ascii characters.
Finally, RFC 2181 §11 restricts the length of a label to 63 bytes and the fully-qualified domain name to 255 bytes. RFC 6532 which extends the email syntax to allow UTF-8 encoded Unicode characters briefly states in §3.4 to continue using bytes, and not characters. It also states that Unicode text should be normalized (which we do).
Since: 0.1.0.0
validateDomainName :: Text -> Validation (NonEmpty Error) DomainName Source #
Validate a domain name.
The domain name is split into host names (labels) and each label is
validated with validateHostName.
Since: 0.1.0.0
validateLocalPart :: Text -> Validation (NonEmpty Error) LocalPart Source #
Validate and normalize the text content of the LocalPart of an
email address.
RFC 3696 §3 restricts the length of the local part to a maximum of 64 bytes. RFC 6532 extends the character set to include Unicode characters but maintains the length measurement as bytes and not characters.
Since: 0.1.0.0
validateDisplayName :: Text -> Validation (NonEmpty Error) DisplayName Source #
Validate the content of a DisplayName.
There does not appear to be a limit on the length of the display name. For consistency and efficiency we limit it to 64 bytes, the same as the local part.
Since: 0.1.0.0
validateLiteral :: Text -> Validation (NonEmpty Error) Literal Source #
Validate the Literal content of a domain literal.
There does not appear to be a limit on the length of an address literal but for consistency with DNS labels we limit them to 63 bytes.
Since: 0.1.0.0
validateAddressTag :: Text -> Validation (NonEmpty Error) AddressTag Source #
Validate the content of an AddressTag. Uses the same rules as
validateLiteral.
Since: 0.1.0.0
validateCommentContent :: Text -> Validation (NonEmpty Error) CommentContent Source #
Validate the content of a comment.
There does not appear to be a limit on the length of a comment. For consistency and efficiency we limit it to 64 bytes, the same as the local part.
Since: 0.1.0.0
validateEmailAddr :: EmailAddr -> Validation (NonEmpty Error) EmailAddr Source #
Validate an entire EmailAddr. This is used by the parser to
validate rules that are not encoded in the various component parsers.
Since: 0.1.0.0