m3ntor

Witam ponownie, Poradziłem sobie z tym problemem, wujek google mi pomógł (chociaż zajęło mi to mnóstwo czasu :/), po przeedytowaniu pliku main.cf jako config postfixa, maile zaczęły dochodzić jak należy. @up używam swiftmailera, też niby z funkcji mail() ale wstępne testy dały 100% docieralności wiadomości. Co do phpmailera to próbowałem go używać na źle skonfigurowanym postfixie i także były problemy z wysyłką, ale same możliwości phpmailera są w porządku, przetestowałem je, ale sam swiftmailer spełnia wymagania.

Witam wszystkich! Mam problem, męczę się z tym od dłuższego czasu i w sumie nie wiem o co chodzi... Czy ktoś z Was ma może doświadczenie w wysyłce maili via skrypt? Ja myślałem, że zwykłe mail() załatwia sprawę i nie ma problemu... Bardzo się myliłem... Przerobiłem mail() - słabo, dużo wiadomości nie dochodzi. Swiftmailer - lepiej, ale też bez szału, teraz męczę phpmailera z użyciem serwerów smtp (poczta.o2.pl i smtp.gmail.com). I teraz tak: wysyłając cokolwiek na gmaila - dochodzi, bez problemu. Ale próbuję wysłać coś testowego na o2 lub poczta.pl i jest lipa ogólnie. Wrzucam logi Dec 1 00:32:31 vz14922 postfix/pickup[25256]: BC7321782B4A: uid=33 from=<www-data> Dec 1 00:32:31 vz14922 postfix/cleanup[25281]: BC7321782B4A: message-id=<cc70b0a50f5c96cc4512591726c0b7ef@m3ntor.eu> Dec 1 00:32:31 vz14922 postfix/qmgr[5744]: BC7321782B4A: from=<www-data@vz14922>, size=652, nrcpt=1 (queue active) Dec 1 00:32:32 vz14922 postfix/smtp[25283]: BC7321782B4A: to=<xxx.xxx@poczta.pl>, relay=mail.poczta.pl[194.181.93.175]:25, delay=0.48, delays=0.01/0/0.18/0.29, dsn=5.0.0, status=bounced (host mail.poczta.pl[194.181.93.175] said: 550-Verification failed for <www-data@vz14922> 550-Unrouteable address 550 Sender verify failed (in reply to RCPT TO command)) Dec 1 00:32:32 vz14922 postfix/cleanup[25281]: 3F0AE1782B4B: message-id=<20141130233232.3F0AE1782B4B@vz14922> Dec 1 00:32:32 vz14922 postfix/qmgr[5744]: 3F0AE1782B4B: from=<>, size=2630, nrcpt=1 (queue active) Dec 1 00:32:32 vz14922 postfix/bounce[25284]: BC7321782B4A: sender non-delivery notification: 3F0AE1782B4B Dec 1 00:32:32 vz14922 postfix/qmgr[5744]: BC7321782B4A: removed Dec 1 00:32:32 vz14922 postfix/smtp[25283]: 3F0AE1782B4B: to=<www-data@vz14922>, relay=none, delay=0.01, delays=0/0/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=vz14922 type=A: Host not found) Dec 1 00:32:32 vz14922 postfix/qmgr[5744]: 3F0AE1782B4B: removed Dec 1 00:34:57 vz14922 postfix/pickup[25256]: 3ECCF1782B4A: uid=33 from=<www-data> Dec 1 00:34:57 vz14922 postfix/cleanup[25294]: 3ECCF1782B4A: message-id=<9c99d98c9f171cb426d058a801fda120@m3ntor.eu> Dec 1 00:34:57 vz14922 postfix/qmgr[5744]: 3ECCF1782B4A: from=<www-data@vz14922>, size=652, nrcpt=1 (queue active) Dec 1 00:34:57 vz14922 postfix/smtp[25296]: 3ECCF1782B4A: to=<xxx.xxx@gmail.com>, relay=gmail-smtp-in.l.google.com[173.194.65.26]:25, delay=0.33, delays=0.01/0/0.13/0.18, dsn=2.0.0, status=sent (250 2.0.0 OK 1417390394 hj1si28649151wib.65 - gsmtp) Dec 1 00:34:57 vz14922 postfix/qmgr[5744]: 3ECCF1782B4A: removed Swoje dane wyxxxowałem. Używam jak widać postfixa (zamiast sendmaila), z tym też się pierniczyłem sporo czasu, bo skrypt mi mulił po zapuszczeniu mail() a nie zawsze cokolwiek udało mu się wypluć. Postfix jest dużo szybszy, ale jak wspomniałem, na gmaila mi wszystko ładnie przychodzi, na inne serwery już nie chce iść. Nadmienię, że nie ma znaczenia czy w phpmailerze użyję danych z gmaila czy o2.pl - na GMaila e-mail dojdzie, na o2.pl, poczta.pl - niekoniecznie. Kod, którego używam jest bardzo prosty, zresztą skoro na gmaila dochodzą wiadomości, to znaczy, że wina nie leży po stronie tego co wydziergałem, a gdzieś coś leży po stronie poczta.pl... o2.pl...? Czy ktoś zna jakąkolwiek bibliotekę, cokolwiek, co będzie dawało sto procent pewności, że e-mail wysłany z www dojdzie bez przeszkód? Skrypt zawsze wypluwa mi wynik pozytywny operacji wysyłania maila. Korzystam z VPSa na biznes-host. Phpinfo: http://m3ntor.eu/phpinfo.php Ponadto na home.pl skrypt też działa w podobny sposób, wypluwając albo i nie wypluwając maila (mam dostęp do dwóch kont - na jednym w ogóle nic nie wypluwa i zwraca error, że mail() wyłączone, na drugim z kolei działa podobnie jak na moim VPS). Support home.pl twierdzi, że aby wysłać maila z www, na pewno nie uda się go wysłać jak nie wpiszemy jako nadawcę, adresu e-mail hostowanego z home.pl (????). Z góry dzięki za każdą wskazówkę, polecenie jakiejś biblioteki, cokolwiek.

@elcct Sprawdziłem to na przykładzie prostego pliku php z phpinfo (view.php?view=test) i plik się nie wykonał, domyślam się, że pliki spoza /var/www/ nie są czytane przez parser php, ale mogę się mylić. Zarówno przy próbie wrzucenia go z formularza (plik jpg z ukrytym kodem php, phpinfo dokładnie) jak i ręcznego wrzucenia do katalogu. Nie ma możliwości, żeby ktoś wrzucił plik z jakimkolwiek rozszerzeniem, bo skrypt usuwa nazwę i rozszerzenia, zostawiając jedynie losowo wygenerowany numer, więc o view=test.php nie ma mowy. Czy może jest coś o czym nie wiem? @macsch W kodzie, który zaproponowałeś nie rozumiem tylko tej linijki: echo file_get_contents('../../2WyVYRzriftxyiHhzkcO/'.$numer); Jak to różni się od kodu użytego przeze mnie?

Zrobiłem to jeszcze inaczej, niż proponowaliście, a mianowicie (skrypt znajduje się w var/www/skrypt/ Plik view.php. <?php @header('Content-type: image/jpg'); $numer = mysql_escape_string($_GET['view']); $plik = @fopen('../../2WyVYRzriftxyiHhzkcO/'.$numer.'', 'rb'); $obrazek = @fread($plik, filesize('../../2WyVYRzriftxyiHhzkcO/'.$numer.'')); fclose($plik); echo $obrazek; ?> Następnie obrazek można wyświetlić adresem view.php?view=numer_obrazka. Żeby jeszcze utrudnić sprawę, ustawiam phpem tym plikom chmod 0600. Czy to jest stuprocentowo bezpieczna metoda?

Wnioskuję po tym co napisałeś, że mój sposób zabezpieczenia jest dobry? A innymi słowy, jeżeli zabronię bezpośredniego dostępu do obrazków w katalogu a będę je wyświetlał jedynie z poziomu www np.: if (($_GET['view']) && ($_GET['view'] != 0)){ $numer = mysql_escape_string($_GET['view']); echo '<img src="adres/$numer">'; } Pytanie czy jeżeli zabronię bezpośredniego dostępu do obrazków, to czy będzie się dało je udostępniać na innych stronach czy forach?

Poszukuję wiedzy od bardziej doświadczonych kolegów, na temat tego, czy stosowane przeze mnie zabezpieczenia skryptu uploadu obrazków będą skuteczne przed atakami typu code injection i innymi. Mamy htmlowski standardowy formularz z opcją wyboru pliku do uploadu. Następnie PHP leci następującymi kodami (poza sprawdzaniem czy plik został wybrany i rozmiar maksymalny pliku): IF($_FILES['plik']['type'] == 'image/png' or $_FILES['plik']['type'] == 'image/jpeg' or $_FILES['plik']['type'] == 'image/gif'){ $x = getimagesize($_FILES['plik']['tmp_name']); IF(!is_array($x) or $x[0] < 2){ $blad++ ; echo 'Nie kombinuj, proszę.'; } } else { $blad++; echo 'Tylko obrazki.'; } Sprawdzanie rozszerzenia oraz sprawdzanie czy zawartość to obrazek czy np. plik test.php z podmienionym rozszerzeniem na test.jpg. Jeżeli jest coś nie tak, wywala zmienną $blad++;. I teraz jeżeli nie ma $blad to: if (!$blad){ move_uploaded_file($_FILES['plik']['tmp_name'],$uploaded); $ext2=getimagesize($uploaded); switch (strtolower($ext2[2])) { case '2': $img2 = imagecreatefromjpeg ($uploaded); break; case '1' : $img2 = imagecreatefromgif ($uploaded); break; case '3' : $img2 = imagecreatefrompng ($uploaded); break; default : $stop = true; break; } list($OriginalWidth, $OriginalHeight) = GetImageSize($uploaded); $ResampledImage2 = ImageCreateTrueColor($OriginalWidth, $OriginalHeight); ImageCopyResampled($ResampledImage2, $img2, 0, 0, 0, 0, $OriginalWidth, $OriginalHeight, $OriginalWidth, $OriginalHeight); imagejpeg($ResampledImage2, "/var/www/IH/obrazki/".$numer."", 100); $ext=getimagesize($uploaded); switch (strtolower($ext[2])) { case '2': $img = imagecreatefromjpeg ($uploaded); break; case '1' : $img = imagecreatefromgif ($uploaded); break; case '3' : $img = imagecreatefrompng ($uploaded); break; default : $stop = true; break; } $Width = 300; $Height = 300; list($OriginalWidth, $OriginalHeight) = GetImageSize($uploaded); if ($OriginalWidth > $Width || $OriginalHeight > $Height) { $ResampleRatio = $OriginalWidth / $OriginalHeight; if ($Width / $Height > $ResampleRatio) $Width = $Height * $ResampleRatio; else $Height = $Width / $ResampleRatio; } else { $Width = $OriginalWidth; $Height = $OriginalHeight; } $ResampledImage = ImageCreateTrueColor($Width, $Height); ImageCopyResampled($ResampledImage, $img, 0, 0, 0, 0, $Width, $Height, $OriginalWidth, $OriginalHeight); imagejpeg($ResampledImage, "/var/www/IH/obrazki/".$numer."_thumb", 80); W skrócie. Przesuwam zauploadowany plik do odpowiedniego katalogu, nadaję mu nazwę z funkcji TIMESTAMP+kilkucyfrowy losowy numer, zapisując bez rozszerzenia, chwilę później GD tworzy miniaturkę _thumb, a następnie znowu za pomocą GD zapisuję ten sam obraz w miejsce tego pliku, który przed chwilą przesunąłem funkcją move_uploaded_file. Innymi słowy - na serwerze w katalogu z obrazkami są dwa nowe pliki, obydwa "przerobione" przez GD. Wg tego artykułu, zuploadowanych w ten sposób plików nie da się otworzyć przez include() (wywala błąd serwera) http://php.webtutor.pl/pl/2011/04/11/code-injection-czyli-prosty-wirus-php-w-obrazku-jpeg/, zaś zanim wprowadziłem zabezpieczenie z GD2 pliki bezproblemowo przechodziły na serwer i dało się je otworzyć z funkcji include(). Wiem, że pewnie wyważam otwarte drzwi, ale zależy mi, żeby skrypt był szczelny. Jakieś rady?

Śledzenie trasy do m3ntor.eu [178.255.45.108] z maksymalną liczbą 30 przeskoków: 1 <1 ms <1 ms <1 ms . [192.168.1.1] 2 18 ms 17 ms 18 ms Wroclaw-bras1.inetia.pl [195.114.190.159] 3 22 ms 23 ms 24 ms 83.238.251.194 4 31 ms 31 ms 34 ms JawoH001RT09-WarsH002RT22.inetia.pl [83.238.251.46] 5 29 ms 28 ms 29 ms WarsH002RT22-WarsB010RT06.inetia.pl [83.238.250.176] 6 28 ms 27 ms 27 ms do-netia.atman.pl [194.153.134.237] 7 32 ms 31 ms 31 ms artnet.thinx.pl [212.91.0.159] 8 31 ms 31 ms 32 ms rtr-gda3.artnet.pl [91.200.32.59] 9 * * * Upłynął limit czasu żądania. 10 * * * Upłynął limit czasu żądania. 11 * * * Upłynął limit czasu żądania. 12 * * * Upłynął limit czasu żądania. 13 * * * Upłynął limit czasu żądania. 14 * * * Upłynął limit czasu żądania. 15 * * * Upłynął limit czasu żądania. 16 * * * Upłynął limit czasu żądania. 17 * * * Upłynął limit czasu żądania. 18 * * * Upłynął limit czasu żądania. 19 * * * Upłynął limit czasu żądania. 20 * * * Upłynął limit czasu żądania. 21 * * * Upłynął limit czasu żądania. 22 * * * Upłynął limit czasu żądania. 23 * * * Upłynął limit czasu żądania. 24 * * * Upłynął limit czasu żądania. 25 * * * Upłynął limit czasu żądania. 26 * * * Upłynął limit czasu żądania. 27 * * * Upłynął limit czasu żądania. 28 * * * Upłynął limit czasu żądania. 29 * * * Upłynął limit czasu żądania. 30 * * * Upłynął limit czasu żądania. Śledzenie zakończone. Śledzenie trasy do vipower.pl [178.255.45.125] z maksymalną liczbą 30 przeskoków: 1 <1 ms 11 ms <1 ms . [192.168.1.1] 2 17 ms 17 ms 21 ms Wroclaw-bras1.inetia.pl [195.114.190.159] 3 23 ms 24 ms 22 ms 83.238.251.194 4 29 ms 31 ms 28 ms JawoH001RT09-WarsH002RT22.inetia.pl [83.238.251.46] 5 29 ms 28 ms 29 ms WarsH002RT22-WarsB010RT06.inetia.pl [83.238.250.176] 6 27 ms 27 ms 27 ms do-netia.atman.pl [194.153.134.237] 7 32 ms 32 ms 32 ms artnet.thinx.pl [212.91.0.159] 8 32 ms 32 ms 31 ms rtr-gda3.artnet.pl [91.200.32.59] 9 * * * Upłynął limit czasu żądania. 10 * * * Upłynął limit czasu żądania. 11 * * * Upłynął limit czasu żądania. 12 rtr-gda3.artnet.pl [91.200.32.59] raporty: Host docelowy jest nieosiągalny . Śledzenie zakończone. Badanie m3ntor.eu [178.255.45.108] z 32 bajtami danych: Upłynął limit czasu żądania. Upłynął limit czasu żądania. Upłynął limit czasu żądania. Upłynął limit czasu żądania. Statystyka badania ping dla 178.255.45.108: Pakiety: Wysłane = 4, Odebrane = 0, Utracone = 4 (100% straty), Badanie vipower.pl [178.255.45.125] z 32 bajtami danych: Upłynął limit czasu żądania. Upłynął limit czasu żądania. Upłynął limit czasu żądania. Odpowiedź z 91.200.32.59: Host docelowy jest nieosiągalny. Statystyka badania ping dla 178.255.45.125: Pakiety: Wysłane = 4, Odebrane = 1, Utracone = 3 (75% straty),

No, po 1,5h coś się ruszyło. Żądanie wysyłane przez przeglądarkę jest spełniane, ale standardowo, co akurat mnie nie dziwi, serwer się dalej dławi i pewnie już tak zostanie do następnego padu.

Aż się specjalnie zarejestrowałem, żeby się wyżalić. Generalnie problemy z dostępnością Vipower, zarówno jeżeli chodzi o mój pakiet wirtualnego hostingu jak i samą stronę Vipower.pl występują od dłuższego czasu, przynajmniej od tygodnia (zwłaszcza w godzinach nocnych), ale to co się dzieje teraz to jest totalna padaka, a jeżeli brak dostępu potrwa dłużej to nazwę to już kompletnym dnem na które Vipower opadło. Wcześniej było tak, że serwer odpowiadał na żądanie przeglądarki tak powiedzmy dopiero po kilku(nastu) sekundach, czasami w ogóle, ale ogólnie - jakoś się toczyło. Dzisiaj od 12:32 zaliczył totalny pad, włącznie z główną stroną Vipower. Zresztą o ile dobrze pamiętam, to nie pierwszy raz opadnie na dno, gdyż serwer zaliczył ze dwa miesiące temu taki sam totalny pad, aż dostałem darmowe przedłużenie ważności mojego pakietu na bodajże kwartał (!). Jak tym razem pad będzie taki sam, to nie ma bata, robię totalny backup baz danych i szukam nowego hostingu. @up Samo Vipower.pl działa. Sytuacja podobna jak w przypadku webd z którego się wyniosłem około 2 lata temu m.in. właśnie za podobne akcje. Mój VH nie śmigał, a tymczasem webd.pl było ZAWSZE dostępne. A pomyśleć, że jak się przeniosłem na Vipower to byłem przez bardzo długi czas zachwycony jakością usług w takiej cenie.