This property provides an opportunity to specify optional validation behaviors. It
defaults to 0 (default behaviors). To get something other than the default, set Options
to the sum of one or more HexValidEmailOptions constants:
- hexVeOptionAllowExtraText (1)
- Allow extra text such as comments in the email address.
- hexVeOptionDisallowDomainLiterals (16)
- Don't allow domain literals in the email address. Example of an email address with a
- hexVeOptionDontRequireDomainDot (4)
- Don't require a dot in the email domain, allowing a domain such as
"hexillion". This is technically legal but not likely to be usable on the
- hexVeOptionRequireMx (32)
- Require that an email domain have MX records--it can't just get by with an A record.
Normally you won't want to set this for validation, but if you're actually just trying to
get MX records you can use this to avoid pseudo-records in MxRecs.
- Try issuing the VRFY and EXPN commands during SMTP validation. This will not affect the
outcome of the validation, but it records the results in SmtpSession.
Occasionally VRFY and EXPN will reveal something interesting about the recipient (such as
a real name), but most servers disable these commands. Using these commands may raise
flags for server administrators because they're sometimes used for intelligence-gathering
prior to a break-in.
- Setting this option causes the validation to begin with a known-bad
test address. If the server accepts this address, the validation will
halt and set Error to hexVeErrDetectedCatchAll.
You should avoid any further SMTP validations for email addresses at
that domain, as they would just waste time and resources.
- Disables the sending of NOOP comments during SMTP validation. The NOOP
comments are much like the UserAgent header in HTTP. They inform mail
server administrators what software is being used and give a link to
more information. They can help allay suspicions when administrators
notice unusual SMTP traffic. We recommend that you not use this option
unless absolutely necessary.