Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Email::Valid rejecting emails @example.com today

by grantm (Parson)
on Sep 06, 2019 at 01:45 UTC ( #11105692=perlquestion: print w/replies, xml ) Need Help??

grantm has asked for the wisdom of the Perl Monks concerning the following question:

Numerous tests in our automated test suite started failing this morning. The common factor is that the tests are creating or modifying "customer" records with an email address that uses the example.com domain. These tests are not trying to send email, the part of the code that's failing is the input validation which uses Email::Valid with the MX check enabled.

First thing this morning, the tests were only failing on our CI server. The same tests ran fine on our development server. As we went back and forth comparing different test scripts on the two hosts, we eventually realised that all the same tests were now failing on the dev server too. This could possibly be explained by something having changed about the MX record for example.com which affected different hosts at different times depending on DNS cache expiry.

Of course there is a compelling argument that our tests should not be relying on someone else's DNS setup in general and the MX setup for example.com in particular. However the fact remains, these tests passed yesterday and are failing today.

We have put in a workaround in our validation routine so this is not really a question - more of a heads up, in case something like this happens to you today :-)
  • Comment on Email::Valid rejecting emails @example.com today

Replies are listed 'Best First'.
Re: Email::Valid rejecting emails @example.com today
by jcb (Deacon) on Sep 06, 2019 at 02:16 UTC
    These tests are not trying to send email, the part of the code that's failing is the input validation which uses Email::Valid with the MX check enabled.

    I found your problem: the example.com domain is not really even supposed to resolve, much less have ever had valid MX records. The validation is working correctly: email addresses on example.com are not valid and you should not be using those in test data that is supposed to pass validation.

    I offer a solution: establish a ci-test subdomain on your own domain and use it for your sample customer records.

      I found your problem: the example.com domain is not really even supposed to resolve, much less have ever had valid MX records. The validation is working correctly: email addresses on example.com are not valid and you should not be using those in test data that is supposed to pass validation.

      Prove it :)

Re: Email::Valid rejecting emails @example.com today
by stevieb (Canon) on Sep 06, 2019 at 21:38 UTC

    I personally wrote the patch that caused example.com to be invalid in accordance with the RFCs (in version 1.199, released on 2016-03-27, based on the Email::Valid Changes file).

    Something changed at your end, whether it be an update to the distribution, or your DNS/naming infrastructure. Given that it happened across two separate environments separately, I suspect the latter (as you've stated within this thread).

    jcb suggested to add a sub-domain to your domain for testing. If you go this route, ensure you create an MX record so your MX tests pass. You could also create a dummy example.com domain (with an MX) within your local infrastructure, or simply bypass the MX checks (unadvised).

    Regardless... the reason this is failing is due to the fact that example.com is not a valid domain (technically it's a reserved domain; I say "invalid" for the purposes of the distribution).

      I personally wrote the patch that caused example.com to be invalid in accordance with the RFCs

      Hi,

      Hmm, which rfc are you reading? I see what you did, it goeas against rfc6761.

      - treat restricted/reserved TLDs (invalid, test, example, loca +lhost) as invalid (thanks, Steve Bertrand!) # Purpose: Check whether a top level domain is valid for a domain. sub tld { my $self = shift; my %args = $self->_rearrange([qw( address )], \@_); unless (eval {require Net::Domain::TLD; Net::Domain::TLD->VERSION(1. +65); 1}) { die "Net::Domain::TLD not available"; } my $host = $self->_host( $args{address} or return $self->details('tl +d') ); my ($tld) = $host =~ m#\.(\w+)$#; my %invalid_tlds = map { $_ => 1 } qw(invalid test example localhost +); return defined $invalid_tlds{$tld} ? 0 : Net::Domain::TLD::tld_exist +s($tld); }

      Did you goof? https://tools.ietf.org/html/rfc6761 says

      2. Application software SHOULD NOT recognize example names as special and SHOULD use example names as they would other domain names.
        example.com is a second level domain, not a top level domain.
        The function you quoted deals with TLD, as in not.existing.example

        example.com seems to be treated as any other domain, which is by looking it up in DNS - which fails if there's no corresponding record

        :)

        I must have misunderstood.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://11105692]
Approved by haukex
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2019-12-07 04:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (160 votes). Check out past polls.

    Notices?