Problem with a domain that seem to respond correctly #23
Labels
Comments
|
Turn on debug to see the exact output/exception? Hard to tell anything else without more details really... |
|
I tried to connect from the same IP machine with telnet (a linux centos
server).
I tried to follow the problem step by step:
- After the HELO, in the expect(), the first RECV works fine but the
second one (located in a while loop) triggers a Timeout exception.
- I tried to catch this exception (in the expect() while loop) and your
library has been able to go further but in the end, every response code was
out of sync (shifted one command further) : for instance, I had a 550
response code for the QUIT command (it was the response code of the
previous RCPT TO).
Maybe the problem is that for this domain (bourdette.com), I get a 220
response after the HELO too soon (this domain is very fast). So maybe I get
a timeout because the response has already been sent?
You can try by yourself with [email protected]
Cordialement,
Fabio Chelly
2017-09-13 15:26 GMT+02:00 zytzagoo <[email protected]>:
… 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...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD32UXpy1piYlx8ZqfExciC3MjBiQBflks5sh9gIgaJpZM4PUxJs>
.
|
|
This is what I get, tested using: <?php
require 'smtp-validate-email.php';
$from = '[email protected]'; // for SMTP FROM:<> command
$emails = array(
'[email protected]',
);
$validator = new SMTP_Validate_Email($emails, $from);
$validator->debug = true;
$smtp_results = $validator->validate();
print "\n";
var_dump($smtp_results);Output: 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... |
|
Hi,
Thanks for your answer.
I have found the origin of the problem. In fact your library takes too much
time to check some domains.
For some domains (bourdette.com, easycash.fr) the connect part is extremely
slow. Those domains response with a first response:
220-XXXXX
Then a :
220 YYYY a lot of time later (without the "-")
The problem is that your library waits for the second 220 response and it
takes forever to check those domains (many other check tools can check the
same domains instantly).
I tried to bypass this 220 wait by detecting "220-" line in the expect()
function and sending the HELO just after. It worked. In that case, the
checking is complete and takes a 300 ms instead of 10 seconds!
But I have problems checking the result because all messages are shifted (I
get the "RCPT TO" response after the "QUIT". Here is the log I get in that
case (checking [email protected]):
Connecting to mx3.ovh.net:25
Connected to mx3.ovh.net:25 successfully
<<<recv: 220-mx3.ovh.net in10
send>>>: EHLO free.fr
<<<recv: 220 mx3.ovh.net in10
send>>>: HELO free.fr
<<<recv: 250-in10.mail.ovh.net
<<<recv: 250-SIZE 104850000
Reception 2: 250-SIZE 104850000
<<<recv: 250-STARTTLS
Reception 2: 250-STARTTLS
<<<recv: 250-ENHANCEDSTATUSCODES
Reception 2: 250-ENHANCEDSTATUSCODES
<<<recv: 250 8BITMIME
Reception 2: 250 8BITMIME
send>>>: MAIL FROM:<[email protected]>
<<<recv: 250 in10.mail.ovh.net
send>>>: RCPT TO:<[email protected]>
<<<recv: 250 2.1.0 Ok
send>>>: QUIT
<<<recv: 550 5.1.1 <[email protected]>: Recipient address rejected:
User unknown
Closing socket to mx3.ovh.net:25
Cordialement,
Fabio Chelly
2017-09-13 16:15 GMT+02:00 zytzagoo <[email protected]>:
… This is what I get, tested using:
<?phprequire 'smtp-validate-email.php';$from = ***@***.***'; // for SMTP FROM:<> command$emails = array( ***@***.***',);$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 ***@***.***>
<<<recv: 250 2.1.0 Ok
send>>>: NOOP
<<<recv: 250 2.0.0 Ok
send>>>: NOOP
<<<recv: 250 2.0.0 Ok
send>>>: RCPT ***@***.***>
<<<recv: 550 5.1.1 ***@***.***>: Recipient address rejected: bourdette.com
Unexpected response to RCPT TO: 550 5.1.1 ***@***.***>: 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) {
***@***.***"]=>
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...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD32UfXFzfPIyFbrGUlhd1z8QVkWpv5Vks5sh-OMgaJpZM4PUxJs>
.
|
|
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: 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. |
|
Hi,
On my log, you can see that I get the wrong response to each command ; I
get a 250 to my RCPT TO (instead of 550) and the 550 is the response to QUIT
send>>>: RCPT TO:<[email protected]>
<<<recv: 250 2.1.0 Ok
send>>>: QUIT
<<<recv: 550 5.1.1 <[email protected]>: Recipient address rejected:
User unknown
Here is the modification I made to the expect() function to by-pass the
wait after connecting:
protected function expect($codes, $timeout = null,
$empty_response_allowed = false) {
$is220 = $codes == self::SMTP_CONNECT_SUCCESS;
...
if ($is220 && substr($line, 0, 4) == '220-') {
$this->debug('By-passing 220');
}
else {
while (preg_match("/^[0-9]+-/", $line)) {
$line = $this->recv($timeout);
$text .= $line;
}
}
...
}
Cordialement,
Fabio Chelly
2017-10-04 12:35 GMT+02:00 zytzagoo <[email protected]>:
… 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 ***@***.***>
[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 ***@***.***>
[2017-10-04T10:20:51.870558+0000] <<<recv: 550 5.1.1 ***@***.***>: Recipient address rejected: bourdette.com
[2017-10-04T10:20:51.870693+0000] Unexpected response to RCPT TO: 550 5.1.1 ***@***.***>: 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) {
***@***.***"]=>
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
<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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD32URS7OgzQOyjteOsE4LNE8k_Yt94Sks5so1-GgaJpZM4PUxJs>
.
|
|
I have found the real problem.
As soon as the catchall check, is enabled every check to <anything>@
easycheck.fr takes 30 seconds instead of 6 seconds normally:
- 6 seconds are wasted between the connect and the HELO
- 24 seconds are wasted after the QUIT command (I don't know why: the QUIT
works fine if I don't check the catchall).
Cordialement,
Fabio Chelly
2017-10-04 14:04 GMT+02:00 Fabio Chelly <[email protected]>:
… Hi,
On my log, you can see that I get the wrong response to each command ; I
get a 250 to my RCPT TO (instead of 550) and the 550 is the response to QUIT
send>>>: RCPT ***@***.***>
<<<recv: 250 2.1.0 Ok
send>>>: QUIT
<<<recv: 550 5.1.1 ***@***.***>: Recipient address
rejected: User unknown
Here is the modification I made to the expect() function to by-pass the
wait after connecting:
protected function expect($codes, $timeout = null, $empty_response_allowed = false) {
$is220 = $codes == self::SMTP_CONNECT_SUCCESS;
...
if ($is220 && substr($line, 0, 4) == '220-') {
$this->debug('By-passing 220');
}
else {
while (preg_match("/^[0-9]+-/", $line)) {
$line = $this->recv($timeout);
$text .= $line;
}
}
...
}
Cordialement,
Fabio Chelly
2017-10-04 12:35 GMT+02:00 zytzagoo ***@***.***>:
> 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 ***@***.***>
> [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 ***@***.***>
> [2017-10-04T10:20:51.870558+0000] <<<recv: 550 5.1.1 ***@***.***>: Recipient address rejected: bourdette.com
>
> [2017-10-04T10:20:51.870693+0000] Unexpected response to RCPT TO: 550 5.1.1 ***@***.***>: 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) {
> ***@***.***"]=>
> 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
> <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.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#23 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AD32URS7OgzQOyjteOsE4LNE8k_Yt94Sks5so1-GgaJpZM4PUxJs>
> .
>
|
|
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 [email protected] from my shitty residential broadband at home, here's a log: The above (probably non-existing) address turning out to be "valid" is due to |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: