Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Mail delivery failed - jak się tego pozbyć?
Forum PHP.pl > Inne > Komputery i oprogramowanie
Walian
Wie ktoś jak się pozbyć tego automatycznego spamu na skrzynce?
Nie potrzebuję informowania, że nie doszło "tysionc pińcet" wiadomości bo "coś tam".
Tym bardziej, że wysyłamy masowo wiadomości do wielu odbiorców, po kilku godzinach tych maili jest kilkanaście tysięcy...
Mamy serwer dedykowany w OVH. Domyślam się, że tu chodzi o konfigurację exim ale nie wiem jak to ustawić.
webdice
Problem nie jest związany z PHP. Przenoszę.
Hekko
Najprościej to ustaw filtr w anty-spamie smile.gif
Walian
Niestety to nie do końca rozwiąże sprawę.
W Direct Admin-ie jest taka opcja w ustawieniach filtru antyspamowego poczty:
Kod
Action for filter matches:     * Drop Email       * Send to spambox

Na razie mamy ustawioną opcję drugą - na wszelki wypadek, gdyby okazało się, że ktoś do nas wysłał jakąś wiadomość, ale nie doszła na skrzynkę odbiorczą bo zawierała słowa, które zostały potraktowane przez filtr. Wtedy możemy sobie zajrzeć w spam i odczytać.

Jeśli w tym momencie przyblokuję te wiadomości "Mail delivery failed" i podobne - chyba nietrudno zgadnąć co się stanie...
Dlatego nie chcę leczyć - chcę zapobiec - całkowicie wyłączyć wysyłanie tych zwrotnych wiadomości smile.gif
thek
Ale ten błąd i zwrotki są jak najbardziej pomocne by zlokalizować błąd.
Przykłady tego co zawierają owe "zwrotki":
1. This message has been rejected because it has a potentially executable attachment 1.eml
This form of attachment has been used by recent viruses or other malware. If you meant to send this file then please package it up as a zip file and resend it
2. No Such User Here
3. SMTP error from remote mail server after RCPT TO:<user@domena.pl>:
host domena.pl [xxx.xxx.xxx.xxx]: 550-Verification failed for <user@domena.pl>
550-No Such User Here
550 Sender verify failed
4. SMTP error from remote mail server after RCPT TO:<user@domena.pl>:
host domena.pl [xxx.xxx.xxx.xxx]: 550 "Unknown User"
5. Unrouteable address.

Popatrz na błedy a znajdziecie winowajcę. Zapewne są złe ustawienia skryptu wysyłającego lub coś w ten deseń i maile zamiast iść do użytkowników, idą w pustkę, trafiacie na limit wysyłki maili serwera (dostaniecie wtedy info jaki on jest, co pozwoli dostosować skrypt!) lub macie użytkowników duchy lub że trafiliście na spamlistę i Wasze maile są blokowane. Te informacje w zwrotkach są bardzo pomocne przy lokalizacji przyczyny i pomogą choćby stwierdzić, czy błąd jest po stronie Waszego skryptu, konfiguracji serwera czy może serwera klienta.
Walian
Słuchaj ja wiem o tym wszystkim, ale sęk w tym, że mamy bazę 300 tyś adresów. Większość z nich nie istnieje, ma za silne filtry, przepełnioną skrzynkę itp. Sęk w tym, że nie mam czasu na odfiltrowanie tych adresów z tabeli bo musiałbym napisać na to jakiś automat odczytujący te wiadomości ze skrzynki i "porządkujący" tabelkę z adresami. A że mam inne sprawy (bardziej priorytetowe) do zrobienia w pracy to po prostu tego nie robię, chcę jedynie sprawić, żeby serwer pocztowy się odczepił z łaski swojej. Jak będe te maile potrzebował to je przywrócę. Była już kiedyś sytuacja, że wszedłem w skrzynkę odbiorczą, ujrzałem informację, że jest ponad 80 tyś nieprzeczytanych wiadomości - przecie nie będe tego odczytywał pojedyńczo i poprawiał w bazie...

Dodam, że mamy na razie 300 tyś adresów. Wkrótce będzie tego w cholerę więcej...
thek
A to nie lepiej zastosowac filtry wiadomości z przekierowaniem do odpowiednich katalogów? Ustawiasz regułę i koniec smile.gif Wiadomości masz, a i porządek także. Filtr nie będzie zawierał wiele reguł przecież, a porządek od razu się zrobi. Jeśli jeszcze się zaprzęgnie jakiś skrypt, który wyławiać będzie ze zwrotek adresy skopane, to od razu i wysyłka przyspieszy, bo wyeliminujecie martwe. W teorii wszystko co teraz masz, można bez problemu automatyzować. Ustawiasz reguły z przekierowaniem na katalog, potem skryptem odczytujesz choćby poprzez IMAP z niego wiadomości i parsujesz w poszukiwaniu błędnego adresu oraz oznaczasz od razu w bazie jako deady. Można nawet tak, że inkrementuje temu adresowi licznik i wciąż wysyła, ale jeśli licznik przekroczy pewną wartość, to dopiero od tego momentu go wyeliminuje z wysyłki.

Moim zdaniem to lepsze rozwiązanie niż próba uwalania całego ruchu. Ale to moje osobiste zdanie i nie musisz go podzielać.
Walian
Cytat
A to nie lepiej zastosowac filtry wiadomości z przekierowaniem do odpowiednich katalogów?

Pewnie, że lepiej, ale nie wiem jak to zrobić. W DA nie znalazłem takich opcji.

Cytat
Jeśli jeszcze się zaprzęgnie jakiś skrypt, który wyławiać będzie ze zwrotek adresy skopane, to od razu i wysyłka przyspieszy, bo wyeliminujecie martwe.

Jasne nie mam na to czasu, obecnie tworzę wspólnie z drugim programistą spory serwis i to jest naszym głównym zadaniem.

Cytat
potem skryptem odczytujesz choćby poprzez IMAP

Nie da rady - te funkcje nie są u nas dostępne. Doinstalować nic nie można do PHP bo "yum" prawie nic nie znajduje, może to przez sposób w jaki zostało zainstalowane PHP, albo są skopane repozytoria. W ogóle w systemie brakuje większości bibliotek i aplikacji, żeby to wszystko skonfigurować porządnie to trzeba by było wywalić całe PHP, zainstalować najnowszą wersję + dodatkowe moduły, wgrać biblioteki i programy itd... A nie będę się w to wszystko bawił bo - raz, że nie mam czasu, dwa - za duże ryzyko, że coś się posypie, a serwer nie może przestać działać nawet na chwilę tak więc wolę tego nie ruszać. Co innego gdybyśmy mieli dwie maszyny i można by najważniejsze serwisy przerzucić lub skonfigurować drugą maszynę i potem się na nią przenieść... Poza tym nie wiemy, jak by się zachował jeden z naszych serwisów na nowszej wersji PHP i innych ustawieniach bo jest oparty na dziadowskim skrypcie i to w dodatku poprzerabianym na różne sposoby.

Cytat
Moim zdaniem to lepsze rozwiązanie niż próba uwalania całego ruchu. Ale to moje osobiste zdanie i nie musisz go podzielać.

Ależ masz 100% racji, ale jak widzisz w naszym przypadku nie jest to wszystko takie proste. Zrobienie jednej rzeczy pociąga za sobą konieczność zrobienia kolejnych. A te wysyłanie wiadomości jest tylko "przy okazji" albo mówiąc inaczej: "raz na ruski rok".
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.