Most az Enternet mail adminja lama, vagy en tudom rosszul az SMTP hibakodokat?!

Flame

Udv,

Egy altalam karbantartott szerveren van egy user akinek Enternetes cimre vannak tovabbdobva a mailjei. Enternet mailszervere rendszeresen ad ilyen valaszokat: 


Jul  3 06:51:30 jabba postfix/smtp[8409]: 85856823DB: to=<***censored***@enternet.hu>, relay=smtp2.enternet.hu[62.112.192.22]:25, delay=32028, delays=32026/0.09/1.2/
0.75, dsn=4.0.0, status=deferred (host smtp2.enternet.hu[62.112.192.22] said: 451-193.202.63.149 is not allowed to send mail from leaddeposit.com. 451 A 193.
202.63.149 cimrol nem engedelyezett a(z) leaddeposit.com hasznalata. (in reply to RCPT TO command))

Tudtommal a 4-es kezdetu SMTP hibakodok temporary jelleguek, azaz a postfix egy ido mulva ujra es ujra megprobalja tovabbitani a levelet, amit az enternet "jol konfiguralt" mailszervere persze ujra es ujra visszadob, amig le nem jar nalam a mail.
User jelezte a problemat az enternetnek kb 3 hete, kapott hibajegyet hogy majd ertesitik ha megoldodott. Persze a hibajelenseg azota is valtozatlan, ugy tunik tojnak a fejere.

Kerdeseim a kovetkezok:

1. Ennyire csoro az Enternet hogy keptelen egy hozzaerto rendszergazdat megfizetni, vagy en tudok valamit rosszul az SMTP hibakodokkal kapcsolatban?
2. A user jogosult-e jovairast kerni a havidijbol amig nem szolgaltatnak 100%-osan?

A problemat vegul ugy hidaltam at hogy kertem tole masik e-mail cimet ahova tovabbithatom a leveleit, de akkor is b@ssza a csorom a dolog.

  • 6204 megtekintés

( tso | 2007. 07. 03., k – 10:22 )

első körben a leaddeposit.com dns rekordjait kellene megnézni aztán fikázni mást, persze ez mindig könnyebb..

...
leaddeposit.com. 3600 IN TXT "v=spf1 -all"
...

"This is the simplest possible SPF record: it means your domain leaddeposit.com never sends mail."

1. a fenti rész értelmében azt hiszem a kérdés érvényét vesztette.
2. a fenti rész értelmében nem mivel a szolgáltatás müködik megfelelően.

This is the simplest possible SPF record: it means your domain leaddeposit.com never sends mail.

Es ez a dns rekord varhatoan megvaltozik mielott lejar a mail a queue-ban? Nem az a hasfajasom hogy visszadobja hanem hogy olyan hibakoddal ami kb annyit jelent hogy "most nem tudom fogadni, kuldd ujra kesobb"

Ha módositanak a dnsen akkor változik ha nem akkor nem, plusz függ a queue lifetimetól is sz'al DUNNO :)

Temp ill. permanens hibákat admin válogatja, hogy hogyan használja, mindegyiknek van előnye és hátránya is adott esetben. Inkább az a kérdés szerintem hogy miért akarsz olyan levelet továbbküldeni amelyik domainen nincs is levelezés, valamint mx rekord sem...

Esetleg tudsz adni egy RFC szamot ahol le van az irva hogy nem kell elvenni egy levelet ha a from: mezo vagy a mail from: parancsnal megadott cim nem letezo vagy mx nelkuli domainre mutat? Mert amikor legutobb rfc-t olvastam ezugyben, a cimzett domain reszet eloszor mx rekorddal kellett megprobalni feloldani, ha az nincs akkor hostkent kell kezelni. Nem lenne tul logikus ha ez a feladora maskepp lenne. Sot egyaltalan nem emlekszem olyasmire az smtp szabvanyban hogy a feladoval torodni kellene. Es igaz, jo par eve implementaltam utoljara SMTP protokollt, de akkor meg emlekeim szerint nem volt semmilyen megkotes akar a mail from: parancs akar a from: header tartalmara, azon kivul hogy szintaktikailag valid legyen.
Azt meg hogy egy onalloskodo nagytudasu mail admin egyreszt nagy ivben tesz a szabvanyokra, valamint kerdeses hatekonysagu modszereket valaszt a spam elleni kuzdelemre (greylist persze nincs az istenverte szervere'n) inkabb nem minositenem ujra. Legkozelebb ha valaki erre a domainre ker forwardot, akkor ad masik mailcimet amire kuldhetem, vagy ajanlom majd neki hogy valtson szolgaltatot.
Ja es meg egy adalek: miota mas domainre tovabbitom a srac leveleit, nem no a deferred levelek szama a queue-ban. Erdekes, nem?

Nem értem a nyűgöd. Van ezek szerint egy domain, amelynek tulajdonosa nem akarja, hogy te spammelj vele. Ezt az enternet elfogadja és az ilyen feladóval érkező leveleket elutasítja.
Mi a gond?
Miért lenne bárki köteles átvenni bármilyen domainről (amelyik nem létezik, vagy amelynek tulajdonosa ilyen-olyan úton saját jól felfogott érdekében korlátozni szeretné az átvételt) átvenni a leveleket?

A másik domain szervere nyilván nem használ SPF-et, vagy nem így.

RFC ide v oda, az, hogy kinek küld, hova, hogyan, az ehhez a dologhoz szerintem túlzottan nem kötődik.
Az spf világosan tartalmazza, hogy nem használják a domaint levélküldésre, igy minek is kéne azt továbbítani?
Az hogy erre 451-es hibát ad vissza az enternet mail szervere az pedig a megteheti kategória, mivel - itt az általad említett RFC-kre visszatérve - azt sem tartalmazza semmi hogy ilyen esetben 5xx-el kéne hogy elutasítsa a levelet. Azzal hogy kérdéses hatékonyságú azzal azért harcba szállnék, az általad említett greylist se 100%-os megoldás sem a szűrés szempontjából, sem az újraküldés szempontjából, azzal talán több nyűg van, mint egy SPF implementációval, hiszen véletlen nem kerül bele egy ilyen rekord a dns-be, ellenben sokszor előfordul, hogy a greylist-re tett szerverek cseszik újraküldeni a maileket, akár még a backup mx-re is. Az, hogy a te szervered az ilyen típusú levelekkel micsinál az ugyanígy a te döntésed... SPF-et lehet nem ellenőrizni, ellenőrizni, ahogy az enternet teszi, vagy spamassasinnal vagy akármivel ami szimatikusabb, egész egyszerűen ők igy oldották meg szerintem ebbe a részébe felesleges belekötni.
Ha egy olyan domainről érkezne levél egy usernek aki pl válaszolna rá de nem valid a domainpart vagy mint pl ebben az esetben tulajdonképp nem is kaphatna onnan levelet + nincs is olyan hoszt amire a válaszát aztán továbbítani lehetne akkor meg az lenne a probléma, azaz minek is kéne levelet kapnod valahonnan (valid vagy nem valid domainről akár) ha úgysem lehet rá küldeni?
Az pedig hogy nálad a queue-ban a deferred levelek száma nem növekszik az lehet számodra megnyugvás, de gyakorlatilag feleslegesen fogadtad el és küldted tovább azt. kb mint a strucc amikor homokba dugja a fejét kategória.

Ja, ha csak ennyi, miért nem írsz a postmaster@enternet.hu -ra? Biztos megindokolják majd, hogy miért 400-as hibát állítottak be és nem vágják vissza azonnal a leveled

Ennel drasztikusabb megoldast valasztottam, szoltam a usernek hogy vagy ad masik e-mail cimet vagy megszuntetem a mailjet. Ugyis ajandek lo...
Mellesleg a user amikor lassan 1 honapja eloszor szoltam neki, beszelt a szolgaltatoval, kapott hibajegyet e ennyiben maradtak. (azaz ha ha koritest kigyomlaljuk, nagy ivben tojnak a fejere a hibajegyevel egyutt.)

(de ha jól értem azért te annak sem örülnél)

Konkretan azt nagy ivben kakkintanam le, max szolnek a usernek hogy nehany levele nem ment at, ha egyaltalan eszrevennem. Ami zavar az az, hogy latom a statisztikakban hogy deferred level van, aminek azert illik utananezni hogy mi a fene tortent, nem arrol van-e szo hogy egy domain aminek secondary-zek megdoglott es szolni kene a tulajnak hogy nezze mar meg mi van vele mert nalam varnak a levelei.

Ha 500-assal visszavagja az mar nem az en problemam, nem az en queue-m orizgeti amig le nem jar. Onnan mar a user es a szolgaltato meccselje le hogy miert nem vesznek at minden neki szolo levelet, amikor o nem kert semmi ilyesmit a szolgaltatojatol.

BTW. Ezek a levelek mail szerverektol jonnek, a csoda mass mailerek 99%-ban elvereznek a greylistingen. Azaz ezt a levelet egy mailszerver mar atvette es tovabbitotta (a greylisting miatt 2x is) az enyemnek. De tovabbra is varom azt az rfc-t ami alapjan a nem valos feladotol erkezo levelek smtp idoben visszautasithatok akar vegleges (5xx) akar temporary (4xx) hibakoddal.

De tovabbra is varom azt az rfc-t ami alapjan a nem valos feladotol erkezo levelek smtp idoben visszautasithatok akar vegleges (5xx) akar temporary (4xx) hibakoddal.

Pl. RFC 2821
If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later).

If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later).

Koszi. Ugyan innen:

Normally, failures produce 550 or 553 replies.

Ha egy domain nem kuldhet leveleket es emiatt nem fogadunk el tole semmit, az nekem nagyon vegleges allaspontnak tunik. Ha meg van olyan mailboxa ami elfogadna errol a cimrol leveleket akkor 250-nel kellene reagalnia es az rcpt to: -nal lenne lehetosege elutasitani.
Szoval ez rohadtul permanent error es a szabvany szerint is 550-nel vagy 533-mal kellene elutasitania, nem 4xx-szel. De vegulis mindegy, enternetes cimre tobbe nem kuldunk semmit.

( furge | 2007. 07. 04., sze – 09:38 )

az internet csomagoknál a levelezés az csak plusz szolgáltatás. azt lehet használni és nem használni, felhasználó dönti el, hogy jó-e neki az az email cím. ha bármilyen hiba van vagy ha nem úgy működik ahogy kéne egyes irányokban az a szolgáltató döntése, hogy a felhasználó igényeihez igazítja a levelezést vagy marad a standard beállításainál.

( samu.ferenc | 2011. 09. 20., k – 12:01 )

Tudom, hogy régi post, de hasonló hibám van.

Az ügyfelünknek van egy webszervere, rajta tárhely és levelezés.
A fent említett hiba jelentkezik abban az esetben, ha a levelet nem a saját webszerverén keresztül küldi, hanem az ADSL szolgáltatója által biztosított SMTP-n keresztül. Az ADSL szolgáltató elveszi a levelet, mivel be tud authentikálni.

Hogy miért nem küldi a saját szerverén keresztül? Dinamikus IP és alapból tiltva a 25-ös port, ...
Van valami opció arra, hogy az ADSL szolgáltató SMTP-jét használja és meg is kapják a leveleket az Enternetes címzettek?
Ha a szolgáltató SMTP-je nem játszik, akkor gondolom marad a saját szerver valamelyik másik porton (SSL, TLS, ...)

T-onlány a szolgáltató, v. Digi, v UPC? :)

Tonylány feloldja telefonos kérésre, UPC ad hozzáférést feloldható DIGI nem szereti ha leveleznek ezért nem oldja fel a port szűrést.

egyébként meg ha jól értem adslen üzemelteti a levelezőszerverét?

vagy én értelmezem rosszul?

Balooo

------------------------

Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)

A szerver egy VPS kint a neten, a kliens ADSL-en (T-Online). A kliens az internet kapcsolatát biztosító szolgáltató SMTP-jét állította be (ha valamelyik kliens elkezd szemetelni "SPAM" akkor ne az ő szervere kerüljön blacklist-re).
Ha jól értem az Enternet pedig (tulajdonképpen jogosan) szűri az olyan leveleket, ahol a feladó nem a saját domain-jébe tartozó címről küldi a levelet.

A kérdés inkább arra vonatkozik, hogy ez egyedi megoldás az Enternetnél vagy más is alkalmazza?! Nem mindig jön elő ez a hiba.

Bocsi az IP lemaradt
"ahol a feladó nem a saját domain-jébe tartozó IP címről küldi a levelet."

Arra gondolok ami a topik nyitó hibaüzenetében is szerepel
"193.202.63.149 cimrol nem engedelyezett a(z) leaddeposit.com hasznalata."
Gondolom egy DNS ellenőrzés dobja ki az eltérést, magyarul a "leaddeposit.com" MX rekordja és a levél küldő szerver IP-je (ebben az esetben a T-Online smtp-je) nem azonos

Rosszul gondolod. domain TXT rekordjában el lehet helyezni SPF információkat, amivel azt lehet megmondani, hogy milyen domain névről küldődik normál esetben az email, valamint hogyha nem innét jön mit csináljon vele (ne fogadja el, fogadja el de azért ferdén nézzen rá, semmit ne csináljon, stb.)

( st3v3 v | 2011. 09. 20., k – 16:26 )

tonlánynál belépsz thome-ba és feloldod magadnak :D