Bug #76663 [Com]: fwrite(): send of X bytes failed with errno=32 Broken pipe

Edit report at https://bugs.php.net/bug.php?id=76663&edit=1 ID: 76663 Comment by: spam2 at rhsoft dot net Reported by: standus at post dot cz Summary: fwrite(): send of X bytes failed with errno=32 Broken pipe Status: Not a bug Type: Bug Package: *General Issues Operating System: CentOS, linux, windows PHP Version: 7.0.31 Block user comment: N Private report: N New Comment: I know that you only try to verify it and I did that 20 years ago too but you can't do it in 2018 - cope with the fact when you have 50 of our users in your list you are blocked for two hours and you can't know unless you are extremely careful, our MX hosts hundredts of domains and doing it in batch would block you within seconds because that's not how a reasonable MTA acts from the view of a mail operator you behave like a Spammer and you are threatened as such which explains the errors you see there is no single way you can verify RELIEABLE that an email exists, even not with bounce management based on maillogs because these days crap providers like office365 even accept the whole message, respond with 2xx and later send a backscatter to the often forged innocent sender that the account does not exist just forget what you are trying to do - it is not possible and in doubt it creates more harm than good Previous Comments: ------------------------------------------------------------------------ [2018-07-25 19:10:53] standus at post dot cz I understand what you talk about, but I am not sending emails I am just verify existence of email address. Its different think. No other way exists to verify email address than ask smtp server. ------------------------------------------------------------------------ [2018-07-25 18:54:29] spam2 at rhsoft dot net you need to understand that there is no problem with fwrite it is just the messenger you can't treat others mailservers like you do - frankly you can't even use unconditional sender-verify that way unless you want get blacklisted stop to argue - what you are doing is utterly bullshit and you get what you asked for - for normal usage after a successful fopen that never does happen and when it happens it points out a serious problem you want to know about would you mind to tell the ip of your machine so that it can be added to blacklists? ------------------------------------------------------------------------ [2018-07-25 18:19:05] standus at post dot cz I already tried try catch but its the same, not solved. It will still produce Notice. ------------------------------------------------------------------------ [2018-07-25 18:14:52] standus at post dot cz I dont need answer for architecture or solution, I reported problem with fwrite function. ------------------------------------------------------------------------ [2018-07-25 17:57:51] requinix@php.net >in Documentation is not anything about "Notice message" when it will fail. There is >only return false on fail. ??? fwrite works with PHP streams, which can be files or sockets or other resources. It is not possible to document every possible way that this function could present an error. E_NOTICE happens because it is a socket, and the write operation on the socket had a problem. I do not know if it is possible to get the errno from a failed fwrite on a socket. Regardless, you should *not* use @ because having those error messages is *good* because they tell you of a real problem. The code should be checking the return value from fwrite - not just for an error but in case the write operation did not transmit all the data expected, which could cause the remote server to abort the connection, which could be the source of your problem. >Its impossible catch it ? You can "catch" notices and other error messages with set_error_handler(). >Nobody knows solution because it does not exists ! Just because nobody knows the solution does not mean there is no solution at all. Except there is a solution: the code you are using is old and flawed, but you should not be using this method to verify email addresses at all so it does not matter. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76663 -- Edit this bug report at https://bugs.php.net/bug.php?id=76663&edit=1