Temat: smtp a localhost

Jarosław Rafa:

Piotr Likus:

Znaczy się, że nie masz pełnej kopii zapasowej??
Jeśli nie jest to instalacja elektrowni jądrowej to chyba jednak można mieć środowisko testowe/zapasowe?

W jakim sensie kopii zapasowej? Oczywiście mam backup całego serwera, ale nie wiem, czy o to ci chodziło...

Tak, oczywiście, chodziło właśnie o backup.

Temat: smtp a localhost

Jarosław Rafa:

Michał Sołtan:
Jeśli chcemy wysłać wiadomość email bez użycia dodatkowych funkcji php, np. mail() lub biblioteki IMAP, można to zrobić stosując protokół SMTP.
Zastosowanie funkcji fsockopen('host','port'), port 25 a host do uzgodnienia, łączy nas z serwerem pocztowym. Dalej należy wysłać na "połączony z nami" serwer odpowiednie instrukcje, funkcja write, z protokołu SMTP.

Tak tak... jeszcze po drodze implementujac cale szyfrowanie TLS, bo wszak problem ktory opisywala Edyta polega dokladnie na tym, ze serwer SMTP Gmaila takowego szyfrowania WYMAGA.

Jeśli chodzi o systemy operacyjne na jakich można uzyskać połączenie z serwem
to Windows niestety nie wypada najlepiej. Windows może nie obsługiwać szyfrowanych protokołów. Generalnie jednak skrypty php do obsługi SMTP będą działać wszędzie.

Pod warunkiem ze maja zaimplementowana obsluge TLS. mail() na pewno sobie z tym nie daje rady, nie wiem jak te bardziej zaawansowane.
Zwracam uwage ze TLS to nie to samo co SMTP via SSL (np. przez stunnel), ktory to przypadek dla aplikacji korzystajacej z SMTP jest praktycznie niewidoczny. TLS jest rozszerzeniem specyfikacji (E)SMTP - jezeli serwer anonsuje w komunikacie poczatkowym, ze obsluguje TLS, klient po HELO/EHLO powinien nastepnie wydac polecenie STARTTLS, wynegocjowac parametry szyfrowania i przejsc na transmisje szyfrowana. Wszystko w tej samej sesji SMTP!Jarosław Rafa edytował(a) ten post dnia 09.10.08 o godzinie 17:09

Może trochę nieskładnie ale jednak pisałem o tym, że nie trzeba używać funkcji mail(). Wystarczy klasa php do obsługi smtp. Można taką znaleźć tutaj:
http://www.dcsc.utfsm.cl/redes/webhosting/class.smtp.p...
Natomiast w przypadku połączeń tls wymagany jest mały trick.
Po nawiązaniu połączenia i wysłaniu komendy Hello trzeba "ręcznie" wysłać do serwera smtp komendę STARTTLS następnie przełączyć strumień na szyfrowanie tls komendą:
stream_socket_enable_crypto($mail->smtp_conn,true,STREAM_CRYPTO_METHOD_TLS_CLIENT)
Jeśli php obsługuje tls a można to sprawdzić komendą phpinfo() - parametr "Registered Stream Socket Transports" to będzie działać bez żadnych problemów.
Metoda sam sprawdziłem z wykorzystaniem wspomnianej wcześniej biblioteki i serwera smtp.gmail.com.
Cały skrypt, który trzeba napisać dodatkowo ogranicza się do kilkunastu linijek.

Temat: smtp a localhost

Po 63 postach w wątku wreszcie konkretna odpowiedź na początkowe pytanie ;)

Temat: smtp a localhost

Może trochę nieskładnie ale jednak pisałem o tym, że nie trzeba używać funkcji mail(). Wystarczy klasa php do obsługi smtp.

Właśnie, po co wyważać otwarte drzwi.
ja proponuję:
http://framework.zend.com/manual/en/zend.mail.html

Jeżeli ktoś się upiera przy lokalnym smtp to niech się zaopatrzy w serwerek np. http://www.mailenable.com/ dla windy, pod linuxa chyba nikomu nie trzeba wymieniać konkretnych dostępnych MTA.

Ale! Jak nie masz odpowiednich rekordów MX w DNS-ach to poczta wypluta z localhosta w 90% będzie traktowana jako spam!Paweł Wolański edytował(a) ten post dnia 16.10.08 o godzinie 23:38

Temat: smtp a localhost

framework.zend.com/manual/en/zend.mail.html Świetna klasa.

Temat: smtp a localhost

Paweł Wolański:

Ale! Jak nie masz odpowiednich rekordów MX w DNS-ach to poczta wypluta z localhosta w 90% będzie traktowana jako spam!

Niestety jest to NIEWŁAŚCIWE podejście twórców wielu systemów antyspamowych.
Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ pocztę kierowaną do danej domeny. Nie ma żadnej normy, która by zobowiązywała do tego, aby maszyna WYSYŁAJĄCA pocztę była MX-em dla danej domeny. W wielu dużych serwisach są osobne serwery do odbierania i wysyłania poczty. Co więcej, tzw. złota reguła konfiguracji klienta pocztowego - której nikt nigdy oficjalnie nie odwołał, chociaż w praktyce wielu dostawców Internetu wymusza jej łamanie - mówi "do wysyłania poczty używaj najbliższego Tobie serwera SMTP, nieważne gdzie masz konto".
Jedyne, czego moim zdaniem można sensownie wymagac od hosta wysyłającego pocztę, to to żeby jego adres IP miał poprawny wpis w revDNS-ie (tzn, żeby ten wpis w ogóle istniał i zeby rozwijał się z powrotem na to IP). Wymaganie powiązania w DNS-ie konkretnego hosta wysyłającego pocztę z konkretna domeną uważam za nieporozumienie. Natomiast powinno się wymagać, aby adres którym host wysyłający przedstawia się w HELO/EHLO, był zgodny z jego rzeczywistym adresem domenowym, bo tego wymaga odpowiednie RFC.

Temat: smtp a localhost

Niestety jest to NIEWŁAŚCIWE podejście twórców wielu systemów antyspamowych.
Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ pocztę kierowaną do danej domeny. Nie ma żadnej normy, która by zobowiązywała do tego, aby maszyna WYSYŁAJĄCA pocztę była MX-em dla danej domeny.

Od takich rzeczy sa np. wpisy SPF w TXT.

Temat: smtp a localhost

Idea SPF jest tak samo zla, gdyz podobnie jak sprawdzanie MX-ow wiaze wysylanie poczty z okreslonej domeny nadawcy z okreslonymi adresami IP, co jest zupelnie bezpodstawne, gdyz taki zwiazek istnieje wylacznie dla odbioru poczty. Jedynym uzytecznym rodzajem rekordu SPF jest wpis "-all" deklarujacy, ze z danej domeny w ogole nie powinna wychodzic zadna poczta - wtedy odbiorca moze poczte z takiej domeny spokojnie ciac. We wszelkich innych zastosowaniach SPF jest do kitu, gdyz poczta majaca w naglowku nadawce z dowolnej domeny teoretycznie (i praktycznie) ma prawo wyjsc z zupelnie dowolnego hosta - chociazby gdy ktos korzysta z forwardowania maila z jednego konta na inne. SPF rozwala forwardowanie i jest to jedna z wielu jego wad. A jako metoda ochrony przed spamem spisuje sie gorzej niz slabo, chociazby dlatego ze znakomita wiekszosc spamow wysylanych jest z domen ktore nie publikuja rekordow SPF.
Bylem, jestem i bede ze wszystkich sil przeciwko SPF. Jest to zupelnie pomylone podejscie do problemu filtrowania spamu.Jarosław Rafa edytował(a) ten post dnia 18.10.08 o godzinie 18:33

Temat: smtp a localhost

Jarosław Rafa:

Paweł Wolański:

Ale! Jak nie masz odpowiednich rekordów MX w DNS-ach to poczta wypluta z localhosta w 90% będzie traktowana jako spam!

Niestety jest to NIEWŁAŚCIWE podejście twórców wielu systemów antyspamowych.
Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ pocztę kierowaną do danej domeny. Nie ma żadnej normy, która by zobowiązywała do tego, aby maszyna (ciach)

Może to i racja, ale generalnie każdy SMTP postawiony na localhost (czyli na nie rejestrowanym w serwerze nazw IP) jest potencjalnym spamerem. Jak to wykrywać, to już tylko zależy od zdolności producentów oprogramowania anty-spam.
Nie narzekałbym, gdyby każdy localhost był blokowany jako SMTP.

Temat: smtp a localhost

Niestety jest to NIEWŁAŚCIWE podejście twórców wielu systemów antyspamowych.
Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ pocztę kierowaną do danej domeny. Nie ma żadnej normy, która by zobowiązywała do tego, aby maszyna WYSYŁAJĄCA
[ciach]

No nie do końca się zgodzę, każdy MTA powinien posiadać rekordy MX więc podejście wydaje mi się jak najbardziej słuszne.

Co jeżeli mój SMTP ma tylko czasowy dostęp do sieci?
Bez MX-ów poczta do Ciebie nie dojdzie bez względu na to czy SMTP i relay jest na tej samej maszynie.

Filtry sprawdzają jedynie to, czy Twoja wiadomość ma gdzie wrócić.

Polecam:
http://www.immt.pwr.wroc.pl/export_hp/tool/node100.htmlPaweł Wolański edytował(a) ten post dnia 20.10.08 o godzinie 16:22

Temat: smtp a localhost

No nie do końca się zgodzę, każdy MTA powinien posiadać rekordy MX więc podejście wydaje mi się jak najbardziej słuszne.

Kazdy MTA *musi* miec rekord A, *moze* posiadac MX (jesli robi za relay). Dozwolone sa rekordy MX, A lub CNAME, ktorych cele mozna "zmapowac" do MX lub A.

Polecam lekture RFC 2821, sekcja 3.6 "domains" oraz 5 "Address Resolution and Mail Handling". http://rfc.net/rfc2821.html

Temat: smtp a localhost

Łukasz S.:
Kazdy MTA *musi* miec rekord A, *moze* posiadac MX (jesli robi za relay). Dozwolone sa rekordy MX, A lub CNAME, ktorych cele mozna "zmapowac" do MX lub A.

Polecam lekture RFC 2821, sekcja 3.6 "domains" oraz 5 "Address Resolution and Mail Handling". http://rfc.net/rfc2821.html

Łukaszu. Nie zaprotestuję :) Dlatego nie napisałem musi a powinien.

Temat: smtp a localhost

Paweł Wolański:

No nie do końca się zgodzę, każdy MTA powinien posiadać rekordy MX więc podejście wydaje mi się jak najbardziej słuszne.

Co jeżeli mój SMTP ma tylko czasowy dostęp do sieci?
Bez MX-ów poczta do Ciebie nie dojdzie bez względu na to czy SMTP i relay jest na tej samej maszynie.

Nie każdy MTA, tylko każda domena jeżeli już. I też niekoniecznie MX, bo zwykła nazwa hosta z rekordu A też może wystąpić po prawej stronie "@" w adresie mailowym. Przykład, moje konta na dwóch róznych serwerach:

raj@ap.krakow.pl - domena ap.krakow.pl ma MX-a, łatwo sprawdzic
raj@inf.ap.krakow.pl - a inf.ap.krakow.pl ma tylko rekord A

Obydwa adresy są prawidłowe i działają.

Filtry sprawdzają jedynie to, czy Twoja wiadomość ma gdzie wrócić.

Ale ja pisałem nie o sprawdzaniu w ogóle istnienia domeny z adresu nadawcy, tylko o porównywaniu tego z adresem IP komputera wysyłającego pocztę, co wg mnie jest nieuprawnione. Sprawdź sobie chociażby, z jakich hostów wychodzi poczta wysyłana z Gmaila - nie jest to wcale adres bedący MX-em dla domeny gmail.com.
Sprawdzanie samego istnienia domeny jest jak najbardziej OK. Co więcej, ja bardzo popieram SAV czyli sprawdzanie istnienia całego adresu nadawcy (a nie tylko samej domeny) poprzez tzw. sender callback, czyli wywołanie przez odbierający SMTP w trakcie odbierania maila MX-a lub A dla domeny nadawcy i zasymulowanie wysłania maila do tego nadawcy - jeżeli jest odpowiedź OK, to resetujemy połaczenie i przyjmujemy maila normalnie, jeżeli jest jakikolwiek odrzut (np. 550 User unknown), to też odrzucamy przychodzącego maila. Proste a naprawdę skuteczne.

Temat: smtp a localhost

Pominąłem rekord A (CNAME), bo jeżeli wysyłamy pocztę do konkretnego użytkownika w danej domenie jest rzeczą naturalną, że taki wpis w DNS jest wymagany. Już dawno nie widziałem adresu typu pawella@XXX.XXX.XXX.XXX

Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ
pocztę kierowaną do danej domeny.

ODEBRAĆ lub PRZEJĄĆ co pozwala maszynie wskazanej jako alternatywny MX przechować moją pocztę na czas kiedy nie wrócę do domu i nie podłącze ponownie mojego laptopa do sieci.

Co stanie się pocztą wysłaną na twój raj@inf.ap.krakow.pl kiedy masz padnięte łącze albo twój inf.ap.krakow.pl wyleciał w kosmos?

Chodziło mi tutaj o konkretną sytuację (tytuł wątku) ktoś piszę w domu ma domenę jeden komputer dlaczego nie może mieć na nim prawidłowo działającego MTA?

co do SAV, jeżeli wysyłam pocztę używając tylko jednego SMTP co często jest praktykowane, a jako nadawca mam ustawiony adres w domenie która wskazuje na mój laptop, który dzisiaj został w domu, czy to znaczy, że też wysyłam spam :(

Nie ma złotego środka na spam i niespam a znacznie wychodzimy poza temat wątku.

pozdrawiam :-)

Temat: smtp a localhost

Paweł Wolański:

Rekord MX w DNS-ie służy tylko do wskazania maszyny mającej ODBIERAĆ
pocztę kierowaną do danej domeny.

ODEBRAĆ lub PRZEJĄĆ co pozwala maszynie wskazanej jako alternatywny MX przechować moją pocztę na czas kiedy nie wrócę do domu i nie podłącze ponownie mojego laptopa do sieci.

Co stanie się pocztą wysłaną na twój raj@inf.ap.krakow.pl kiedy masz padnięte łącze albo twój inf.ap.krakow.pl wyleciał w kosmos?

A co powinien wysyłający MTA zrobic w takiej sytuacji? Ponawiac próbe wysyłki poczty co jakiś czas, a jeżeli w ciągu jakiegos tam czasu (defaultowo 5 dni) nie uda się wysłać, odesłac zwrotkę nadawcy...
To samo sie stanie przecież kiedy twój MX jest niedostępny... nie każda domena ma fafnaście alternatywnych MX-ów (a raczej jest to mniejszość).

co do SAV, jeżeli wysyłam pocztę używając tylko jednego SMTP co często jest praktykowane, a jako nadawca mam ustawiony adres w domenie która wskazuje na mój laptop, który dzisiaj został w domu, czy to znaczy, że też wysyłam spam :(

Pisałeś nieco wcześniej, że b. dawno już nie widziałeś takich adresów ;)
W standardowej realizacji SAV, skoro nie można połaczyć się z hostem nadawcy dostałbyś komunikat błedu typu 4xx, czyli Twój SMTP powinien powtarzac próbę wysyłki co jakiś czas. W momencie jak odbierający SMTP byłby w stanie połaczyć się z Twoim laptopem i zweryfikowac adres, wtedy przyjąłby maila.

Nie ma złotego środka na spam i niespam a znacznie wychodzimy poza temat wątku.

Więc nie będę już więcej o tym pisał :)

Temat: smtp a localhost

Jarosław Rafa:

A co powinien wysyłający MTA zrobic w takiej sytuacji? Ponawiac próbe wysyłki poczty co jakiś czas, a jeżeli w ciągu jakiegos tam czasu (defaultowo 5 dni) nie uda się wysłać, odesłac zwrotkę nadawcy...
To samo sie stanie przecież kiedy twój MX jest niedostępny... nie każda domena ma fafnaście alternatywnych MX-ów (a raczej jest to mniejszość).

I nie każdy admin pozostawia queuereturn = 5d :(
Bo większość serwerów firm hostingowych ponawia wysyłanie tylko przez kilka godzin.

Pozdrawiam.

Temat: smtp a localhost

Paweł Wolański:

I nie każdy admin pozostawia queuereturn = 5d :(
Bo większość serwerów firm hostingowych ponawia wysyłanie tylko przez kilka godzin.

Pokusiłbym się o stwierdzenie, że trzymanie poczty w kolejce krócej niż przez 1-2 dni jest karygodną nieodpowiedzialnością ze strony admina takiego hosta. Niestety, firmy hostingowe wprowadziły do Internetu wiele "nowomodnych" zwyczajów, które kiedyś wołałyby o pomstę do nieba, a teraz większość ludzi jest nieświadomych że poprawnie powinno się robić inaczej, więc traktuje to jako normę... Kolejny przykład działania prawa Kopernika - gorszy pieniądz wypiera lepszy :(