Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection timeout is not working #41

Open
lashnag opened this issue Aug 13, 2018 · 1 comment
Open

Connection timeout is not working #41

lashnag opened this issue Aug 13, 2018 · 1 comment

Comments

@lashnag
Copy link

lashnag commented Aug 13, 2018

use SMTPValidateEmail\Validator as SmtpEmailValidator;

$validator = new SmtpEmailValidator('sdmk@prkmail.net', 'no-reply@platron.ru');
$validator->setConnectTimeout(1);
$smtpResults = $validator->validate();

It is waiting 3 minute

Bacause of timeout command_timeouts
If you send timeout using setTimeout - you need to use that setting

@zytzagoo
Copy link
Owner

zytzagoo commented Aug 20, 2018

I cannot replicate this on my end.
When trying those addresses using this code:

<?php

require 'vendor/autoload.php';

use SMTPValidateEmail\Validator as SmtpEmailValidator;

$validator = new SmtpEmailValidator('sdmk@prkmail.net', 'no-reply@platron.ru');
$validator->setConnectTimeout(1);
$smtpResults = $validator->validate();

var_dump($validator->getLog());

I get this output back:

array(13) {
  [0]=>
  string(176) "[2018-08-20T20:34:44.082715+0000] MX records (prkmail.net): Array
(
    [mx02.nicmail.ru] => 5
    [mx01.nicmail.ru] => 10
    [mx03.nicmail.ru] => 20
    [prkmail.net] => 0
)
"
  [1]=>
  string(66) "[2018-08-20T20:34:44.082915+0000] Connecting to mx02.nicmail.ru:25"
  [2]=>
  string(113) "[2018-08-20T20:34:45.086681+0000] Connect failed: Operation timed out, error number: 60, host: mx02.nicmail.ru:25"
  [3]=>
  string(131) "[2018-08-20T20:34:45.087535+0000] Unable to connect. Exception caught: Cannot open a connection to remote host (mx02.nicmail.ru:25)"
  [4]=>
  string(66) "[2018-08-20T20:34:45.087646+0000] Connecting to mx01.nicmail.ru:25"
  [5]=>
  string(113) "[2018-08-20T20:34:46.094921+0000] Connect failed: Operation timed out, error number: 60, host: mx01.nicmail.ru:25"
  [6]=>
  string(131) "[2018-08-20T20:34:46.095091+0000] Unable to connect. Exception caught: Cannot open a connection to remote host (mx01.nicmail.ru:25)"
  [7]=>
  string(66) "[2018-08-20T20:34:46.095169+0000] Connecting to mx03.nicmail.ru:25"
  [8]=>
  string(113) "[2018-08-20T20:34:47.098451+0000] Connect failed: Operation timed out, error number: 60, host: mx03.nicmail.ru:25"
  [9]=>
  string(131) "[2018-08-20T20:34:47.098684+0000] Unable to connect. Exception caught: Cannot open a connection to remote host (mx03.nicmail.ru:25)"
  [10]=>
  string(62) "[2018-08-20T20:34:47.098888+0000] Connecting to prkmail.net:25"
  [11]=>
  string(179) "[2018-08-20T20:34:47.100904+0000] Connect failed: php_network_getaddresses: getaddrinfo failed: nodename nor servname provided, or not known, error number: 0, host: prkmail.net:25"
  [12]=>
  string(127) "[2018-08-20T20:34:47.101035+0000] Unable to connect. Exception caught: Cannot open a connection to remote host (prkmail.net:25)"
}

To me, with data from the debug timestamps, this looks like connection attempts failed/timed-out after 1 sec, as requested/specified. So, it appears that connection timeout is working as intended, no?

Command-specific timeouts have nothing to do with the connection timeout. They are set as per the (old) RFCs -- feel free to change them yourself if you wish (and/or if you think they are the cause of your delays...).

A far more likely cause is that the server is throttling you on purpose (due to what the server thinks is unacceptable behaviour).

If I understand you correctly regarding:

Bacause of timeout command_timeouts
If you send timeout using setTimeout - you need to use that setting

This might mean you are suggesting an enhancement/change/fix in the sense that you feel that setConnectTimeout(1) should automatically set all timeouts to 1 -- if that is the case, feel free to fork and/or create a PR in which that happens (should be rather simple). Ideally, keep that change behind a flag or similar guard (so that default behaviour remains the same as it was, for backwards compatibility).

Whether it'll get merged, I don't know -- but that does not matter if it ends up working for your use-case anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants