ugrás a tartalomhoz

PHP E-mail gond

tumba · 2008. Jún. 20. (P), 19.16
Béreltünk egy WEB tárhelyet (PHP-MySQL). A feltelepített honlapunknak van egy regisztrációs menüje, ahol a site megtekintője néhány adatát megadva regisztrálhatja magát.
Ez tökéletesen működik. Regisztrációt követően a felhasználó által megadott e-mail-címre egy megerősítő e-mail-t üldünk.

ÉS ITT KEZDŐDIK A PROBLÉMA!

Az e-mail-ek nem kerülnek elküldésre!

Először a PHP mail() függvényt használta a honlap, de a WEB tárhely szolgáltató szerint az ő server-ük elküldte, és a mi internet szolgáltatónk (T-ONLINE,mx-t-online.hu,SMTP authentikáció) servere visszadobta.
Erre a PHPMailer()-rel próbálkoztunk, ahol meg adtuk a szükséges adatok. Ebben az esetben, ha a felhasználó internet szolgáltatója pl. DATANET-es a regisztráció nem érkezik meg, T-ONLINE-os igen.
A site-unk ATW-és serveren tökéletesen müködik a sima mail() függénnyel.

Mi lehet a gond, illetve mi lehet a megoldás
‹ Honlapon könyvtárból legújabb fájl megjelenítése PHP unit tesztelés ›
 ■
1

Másik tárhely vagy veszekedés...

janoszen · 2008. Jún. 21. (Szo), 12.07
Vettetek egy tárhelyet anélkül, hogy kicsit utánakérdeztetek volna, hogy mi fán terem és hogy megfelel-e az igényeiteknek? Ez szomorú és sajnos sokszor tapasztalom, és nem csak ezt, hanem sokkal durvább dolgokat, mert tárhely == tárhely, különbség nincs közöttük az általános felfogás szerint.

a) megoldás: vesztek egy másik tárhelyet, amelyik jobban megfelel, jobban értenek a rendszergazdái az SMTP konfigurációhoz, stb. mert a tárhelynek vagy saját magának kellene SMTPznie (ami azért is kívánatos, mert a mail reverse DNS-e megfelel a forwardnak) vagy egy SMTP szerverrel kell megállapodnia, hogy fogadja az ő autentikáció nélküli leveleit. (Ezt szorgalmazom, mivel ha egy ilyen triviális problémát nem sikerül megoldaniuk, akkor valószínűleg a technológia többi terén sincsenek a helyzet magaslatán.)

b) megoldás: elkezditek rugdosni az illetékes rendszergazdát, amíg be nem konfigurálja a webszervert úgy, hogy lokális SMTP-vel lehessen levelet küldeni.

c) megoldás: megpróbáltok olyan PHP programot írni (pl *mailerrel), ami tud autentikált SMTP-t és bepróbálkoztok a valamelyik szolgáltatónál. Na ez az a megoldás, amit a jelek szerint próbáltatok csinálni és nem javaslok, mert ezzel rengeteg szívás lehet és kevéssé triviális hibát keresni, hogy hol akad el, főleg hogy a T* ügyfélszolgálat nem feltétlenül a legjobb segítség ebben.

Összegezve: a webtárhelynek kurrens technológia szerint úgy illik működnie, hogy ha levelet szeretnél küldeni, akkor a tárhely szerverére küldöd ki és ő továbbítja a leveledet, ezt kellene valahogy elérni.
3

a) megoldáshoz

tumba · 2008. Jún. 21. (Szo), 12.43
Az első e-mail cím tesztnél a kimenő levelek Outlook-ból sem mentek el. A tárhely szolgáltatónk szerint a dinamikus IP címünk előzőleg spam listára kerülhetet és azért nem megy el. Ez elképzelhető? Erre levette a spam szűrést. Nem lehet, hogy esetleg az ő serverük van fent egy spam listán.
4

Outlook != szerver

janoszen · 2008. Jún. 21. (Szo), 18.21
Némi fogalomzavar van az e-mail körül. Szóval lássuk.

1. SMTP: Simple Mail Transfer protokol. Ez a levelezés alapvetően beszélt nyelve. A szerverek egymás között, illetve amikor Te küldesz levelet, akkor a levelezőprogramod (mindegy, hogy PHP vagy Outlook) is ezt a nyelvet beszéli. Természetesen a spam miatt most már csak akkor küldhetsz egy SMTP szerveren keresztül levelet, ha a) a levél címzettje azon a szerveren lakik vagy b) azonosítottad magad mint a szerver ügyfele. Ez esetben a levelet az MTA (Mail Transfer Agent, azaz aki az SMTP-t beszéli) továbbítja az illetékes levélszervernek (MX).

2. A spam szűrés jegyében a legtöbb szolgáltató a 25-ös porton letiltja a forgalmat, a saját mailszerveréhez kivéve. A T-*-nál a webes felületükön ezt engedélyezni tudod.

3. Az, hogy a PHP alól menjen a levelezés, egyértelműen a szolgáltató feladata és ő meg is tudja nézni a rendszerlogjában, hogy milyen hibával dobta el a levelet a távoli szerver. Szerintem, az hogy ők elküldték de máshol nem érkezett meg, leginkább falduma, ennél mondhatna részletesebbet.

4. Lehetséges, hogy a szolgáltató szervere DNSBL spamlistán van. Google-n rákeresel a megfelelő kulcsszavakra és találsz ellenőrzőt, amelybe beírva a szolgáltató szerverének címét, megtudhatod az igazat. Amennyiben ez az eset áll fent, javasolt a szolgáltató azonnali hanyagolása, ugyanis valószínűleg 1-2 kellemetlenebb egyént is hostol, ha nem ő maga spamel.

5. Ha szolgáltatót szeretnétek váltani, akkor a rászánt zseton függvényében akár tudok is javasolni, de szerintem, ebbe max magánban menjünk bele, mert különben ömlik be ide a sok 500 forintos tárhely reklám.
5

DNSBL spamlista

PredMan · 2008. Jún. 23. (H), 10.16
én is beleütköztem ebbe a problémába, de nem találtam olyan oldalt, ahol a szolgáltatóra rá tudtam volna keresni, hogy spamlistán van-e. Tudnál adni egy webcímet, ahol rá lehet erre keresni?

köszi
6

Kulcsszó

janoszen · 2008. Jún. 23. (H), 11.04
Ihun: http://www.checkbl.org/hu/ (Googleben a második találat volt a DNSBL kulcsszóra. :) ) A kimenő SMTP szerver IP címét kell beírni a rubrikába.
2

e-mail cím?

Szekeres Gergő · 2008. Jún. 21. (Szo), 12.10
az e-mail szolgáltatóknál van a "gond". Nem tudom miylen címről küldöd a leveleket, de lehet ellenőrzik, hogy valóban létezik-e az adott feladó, hogy kiszűrjék a spameket. Nyilván, ha t-onlinera megérkezik, akkor nem a szerverrel és a phpval van a gond..