Giters

zytzagoo / smtp-validate-email

A PHP library for performing email addresses validation via SMTP

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problem with a domain that seem to respond correctly

fabiochelly opened this issue · comments

commented

Hi, I'm using this lib on a daily basis.
I have found a problem with the domain bourdette (.com).

This domain can't be checked because there is an exception in the RECV function. With telnet it seems to work fine.

Does anyone can help?

Thanks,
Fabio Chelly

commented

Turn on debug to see the exact output/exception?
When using telnet (which you say works fine), are you connecting from the same machine/host as the script or a different one?

Hard to tell anything else without more details really...

commented
commented

This is what I get, tested using:

<?php

require 'smtp-validate-email.php';

$from = 'a-happy-camper@campspot.net'; // for SMTP FROM:<> command
$emails = array(
    'anything@bourdette.com',
);

$validator = new SMTP_Validate_Email($emails, $from);
$validator->debug = true;
$smtp_results = $validator->validate();

print "\n";
var_dump($smtp_results);

Output:

MX records (bourdette.com): Array
(
    [smtp.bourdette.com] => 10
    [bourdette.com] => 0
)

Connecting to smtp.bourdette.com:25
Connected to smtp.bourdette.com:25 successfully
<<<recv: 220-zimbra.bourdette.com ESMTP Postfix

<<<recv: 220 zimbra.bourdette.com ESMTP Postfix

send>>>: EHLO campspot.net
<<<recv: 250-zimbra.bourdette.com

<<<recv: 250-PIPELINING

<<<recv: 250-SIZE 30000000

<<<recv: 250-VRFY

<<<recv: 250-ETRN

<<<recv: 250-STARTTLS

<<<recv: 250-ENHANCEDSTATUSCODES

<<<recv: 250-8BITMIME

<<<recv: 250 DSN

send>>>: MAIL FROM:<a-happy-camper@campspot.net>
<<<recv: 250 2.1.0 Ok

send>>>: NOOP
<<<recv: 250 2.0.0 Ok

send>>>: NOOP
<<<recv: 250 2.0.0 Ok

send>>>: RCPT TO:<anything@bourdette.com>
<<<recv: 550 5.1.1 <anything@bourdette.com>: Recipient address rejected: bourdette.com

Unexpected response to RCPT TO: 550 5.1.1 <anything@bourdette.com>: Recipient address rejected: bourdette.com

send>>>: NOOP
<<<recv: 250 2.0.0 Ok

send>>>: RSET
<<<recv: 250 2.0.0 Ok

send>>>: QUIT
<<<recv: 221 2.0.0 Bye

Closing socket to smtp.bourdette.com:25
array(2) {
  ["anything@bourdette.com"]=>
  bool(false)
  ["domains"]=>
  array(1) {
    ["bourdette.com"]=>
    array(2) {
      ["users"]=>
      array(1) {
        [0]=>
        string(8) "anything"
      }
      ["mxs"]=>
      array(2) {
        ["smtp.bourdette.com"]=>
        int(10)
        ["bourdette.com"]=>
        int(0)
      }
    }
  }
}

From what you describe, it seems you get a different response from the server at some point?

I have no idea if that address really exists or not, so can't say if this is really working as intended or not...

commented
commented

There's a delay when checking bourdette.com, but only on what appears to be the first connection from a certain ip (subsequent tests/connections from the same ip [if the ip is "healthy"] are almost instant).

This, to me, looks like it's intentional behavior from the server operators. Or the server might be temporarily overloaded or something? (highly doubt it, but still possible).

Here's another log output from my side, with timestamps:

[2017-10-04T10:20:51.496480+0000] MX records (bourdette.com): Array
(
    [smtp.bourdette.com] => 10
    [bourdette.com] => 0
)

[2017-10-04T10:20:51.496630+0000] Connecting to smtp.bourdette.com:25
[2017-10-04T10:20:51.552752+0000] Connected to smtp.bourdette.com:25 successfully
[2017-10-04T10:20:51.604996+0000] <<<recv: 220 zimbra.bourdette.com ESMTP Postfix

[2017-10-04T10:20:51.605342+0000] send>>>: EHLO campspot.net
[2017-10-04T10:20:51.657142+0000] <<<recv: 250-zimbra.bourdette.com

[2017-10-04T10:20:51.657272+0000] <<<recv: 250-PIPELINING

[2017-10-04T10:20:51.657330+0000] <<<recv: 250-SIZE 30000000

[2017-10-04T10:20:51.657382+0000] <<<recv: 250-VRFY

[2017-10-04T10:20:51.657436+0000] <<<recv: 250-ETRN

[2017-10-04T10:20:51.657487+0000] <<<recv: 250-STARTTLS

[2017-10-04T10:20:51.657540+0000] <<<recv: 250-ENHANCEDSTATUSCODES

[2017-10-04T10:20:51.657593+0000] <<<recv: 250-8BITMIME

[2017-10-04T10:20:51.657645+0000] <<<recv: 250 DSN

[2017-10-04T10:20:51.657709+0000] send>>>: MAIL FROM:<a-happy-camper@campspot.net>
[2017-10-04T10:20:51.710578+0000] <<<recv: 250 2.1.0 Ok

[2017-10-04T10:20:51.710691+0000] send>>>: NOOP
[2017-10-04T10:20:51.761789+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T10:20:51.761907+0000] send>>>: NOOP
[2017-10-04T10:20:51.811042+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T10:20:51.811178+0000] send>>>: RCPT TO:<anything@bourdette.com>
[2017-10-04T10:20:51.870558+0000] <<<recv: 550 5.1.1 <anything@bourdette.com>: Recipient address rejected: bourdette.com

[2017-10-04T10:20:51.870693+0000] Unexpected response to RCPT TO: 550 5.1.1 <anything@bourdette.com>: Recipient address rejected: bourdette.com

[2017-10-04T10:20:51.870750+0000] send>>>: NOOP
[2017-10-04T10:20:51.919670+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T10:20:51.919815+0000] send>>>: RSET
[2017-10-04T10:20:51.969110+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T10:20:51.969273+0000] send>>>: QUIT
[2017-10-04T10:20:52.020302+0000] <<<recv: 221 2.0.0 Bye

[2017-10-04T10:20:52.020414+0000] Closing socket to smtp.bourdette.com:25
array(2) {
  ["anything@bourdette.com"]=>
  bool(false)
  ["domains"]=>
  array(1) {
    ["bourdette.com"]=>
    array(2) {
      ["users"]=>
      array(1) {
        [0]=>
        string(8) "anything"
      }
      ["mxs"]=>
      array(2) {
        ["smtp.bourdette.com"]=>
        int(10)
        ["bourdette.com"]=>
        int(0)
      }
    }
  }
}
[Finished in 1.2s]

Either way, not sure what I can do more here? The library does it's checks according to the RFCs.

The log file you provided with the ovh servers seems perfectly fine, I don't see anything in it about getting RCPT TO after QUIT or similar?

I've added timestamps to the debug log now in 3cab8a3, but you have yet to provide a concrete log that actually demonstrates the issues (and changes you've done). Without those, and without a reproducible test case (which I cannot get, because the first address mentioned seems to work just fine from where I'm testing), I find it hard to justify changing anything else.

commented
commented
commented

easycheck.fr (ovh.net really) is doing various things to prevent bulk validations, including sender address validation etc.

they maybe don't do so much when you come for a reputable ip and/or authenticate before issuing RCPT TO -- don't have time to test that now, there's some more (somewhat related) info here: #3

I don't notice the timings you mention when testing something@easycash.fr from my shitty residential broadband at home, here's a log:

[2017-10-04T18:39:29.470666+0000] MX records (easycash.fr): Array
(
    [mx3.ovh.net] => 1
    [mx4.ovh.net] => 5
    [mxb.ovh.net] => 100
    [easycash.fr] => 0
)

[2017-10-04T18:39:29.476489+0000] Connecting to mx3.ovh.net:25
[2017-10-04T18:39:29.549388+0000] Connected to mx3.ovh.net:25 successfully
[2017-10-04T18:39:29.574901+0000] <<<recv: 220-mx3.ovh.net in12

[2017-10-04T18:39:35.899551+0000] <<<recv: 220 mx3.ovh.net in12

[2017-10-04T18:39:35.902294+0000] send>>>: EHLO campspot.net
[2017-10-04T18:39:35.931512+0000] <<<recv: 250-in12.mail.ovh.net

[2017-10-04T18:39:35.933191+0000] <<<recv: 250-SIZE 104850000

[2017-10-04T18:39:35.937472+0000] <<<recv: 250-STARTTLS

[2017-10-04T18:39:35.938440+0000] <<<recv: 250-ENHANCEDSTATUSCODES

[2017-10-04T18:39:35.939575+0000] <<<recv: 250 8BITMIME

[2017-10-04T18:39:35.940105+0000] send>>>: MAIL FROM:<a-happy-camper@campspot.net>
[2017-10-04T18:39:35.971322+0000] <<<recv: 250 2.1.0 Ok

[2017-10-04T18:39:35.973454+0000] send>>>: NOOP
[2017-10-04T18:39:36.001407+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T18:39:36.003403+0000] send>>>: NOOP
[2017-10-04T18:39:36.031642+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T18:39:36.035570+0000] send>>>: RCPT TO:<something@easycash.fr>
[2017-10-04T18:40:26.359878+0000] <<<recv: 450 4.1.8 <a-happy-camper@campspot.net>: Sender address rejected: Domain not found

[2017-10-04T18:40:26.361597+0000] send>>>: NOOP
[2017-10-04T18:40:26.389449+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T18:40:26.390917+0000] send>>>: RSET
[2017-10-04T18:40:26.418883+0000] <<<recv: 250 2.0.0 Ok

[2017-10-04T18:40:26.420075+0000] send>>>: QUIT
[2017-10-04T18:40:26.449634+0000] <<<recv: 221 2.0.0 Bye

[2017-10-04T18:40:26.451707+0000] Closing socket to mx3.ovh.net:25
array(2) {
  ["something@easycash.fr"]=>
  bool(true)
  ["domains"]=>
  array(1) {
    ["easycash.fr"]=>
    array(2) {
      ["users"]=>
      array(1) {
        [0]=>
        string(9) "something"
      }
      ["mxs"]=>
      array(4) {
        ["mx3.ovh.net"]=>
        int(1)
        ["mx4.ovh.net"]=>
        int(5)
        ["mxb.ovh.net"]=>
        int(100)
        ["easycash.fr"]=>
        int(0)
      }
    }
  }
}

The above (probably non-existing) address turning out to be "valid" is due to public $graylisted_considered_valid = true, and the 450 response code being considered as a "graylist" response code.

commented

From here, this all looks like various symptoms of the same disease -- you're being throttled (for whatever reason). If someone else has some other insights and/or similar experiences, do share.