Sender address rejected

Web, mail, IRC, IM, hálózatok

Üdv!

Most én vagyok a szigorú, vagy tényleg van még ilyen amatőr levél küldés?

Apr 22 14:08:46 xxxx postfix/smtpd[5336]: NOQUEUE: reject: RCPT from mail.nyi.bme.hu[152.66.108.125]: 450 4.1.7 <www-data@mail.nyi.bme.hu>: Sender address rejected: undeliverable address: host mail.nyi.bme.hu[152.66.108.125] said: 550 5.1.1 <www-data@mail.nyi.bme.hu>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command); from=<www-data@mail.nyi.bme.hu> to=<xxxx.xxxxx@xxxxx.xx> proto=ESMTP helo=<nyi.bme.hu

Tilla

  • 2279 megtekintés

( maszili | 2011. 04. 22., p – 19:47 )

Ez sajnos tipikus, hogy a programozó php-mail függvényt használ és nem mond envelope sender-t. Így a rendszer az aktuális user-ből képzi a feladót és mivel a php programot éppen az apache értelmező hajtja végre így a feladó a www-data@HOSTNAME lesz pl. egy Debian rendszer esetén.

--
maszili

Ez a programozót minősíti.

- Fogalma nincs a levelezés körülbelüli működéséről de még a mail függvényt sem ismeri.
- Nyilván nem kezeli a visszapattanó leveleket ami miatt az a hamis képzete van, hogy jó a címlistája ami alapján a leveleket kiküldi.
- Ha nem kezeli a visszapattanókat akkor azt kockáztatja, hogy feljelentik a kéretlen levelek miatt.

Esetleg levélben felveheted a kapcsolatot a feladóval és felhívhatod a figyelmét a dologra.

--
maszili

Én random ilyesmi válaszokat kapok a fejvesztők nagy részétől:

"- Jajj, most miért kell valami bonyolult (phpmailer - a szerk.), működik így is."

"- Hát nekem ezt nem fizetik."

"- Nincs idő ilyesmire."

Folytassam? :) Ja a bónusz:

"- Nem vagyok rendszergazda, nem értek ilyenhez."

Nálam is van sok ilyen, no problem :). Én is szigorú vagyok. Igenis legyen normális hostnév, rendes feladó, beszéljen RFC-t, stb...
Ne aggódj, még az ms-nél sem tudnak mail szervert konfigolni. Nekem is rendszeresen hajítja vissza az onnan érkező leveleket, egyrészt mert hostname not found (smtp olyan nevet mond magáról, ami nem létezik, vagy .local), másrészt főleg a hotmail mx-eknél, az ipk fele blacklisten van.
--
Discover It - Have a lot of fun!

Kábé sokkal jobban, de ez most lényegtelen. :)
A lényeg, hogy ha a feladó ismeretlen üzeneteket elhajtjuk a francba, az jó, de néha okoz problémát. :) Szerintem egy greylisting és jól beállított spamfilter többet ér. Ha meg mégis bekúszik valami, akkor fel kell tanítani a filtert, hogy tudjon róla. Ez sem egyszerűbb, de sender addresst én már nem ellenőrzök nem is tudom már hány éve, mert semmit sem ér, csak a fontos dolgokat (is) hajítja el. :)

ez nalam is igy van, muszaj voltam kikapcsolni a felado ellenorzest. elviekben jo dolog lenn, de a nagyon sok rosszul konfiguralt smtp szerver ill. szar(ul beallitott) mail kliens miatt nem mukodik jol. szerintem alapvetoen jo dolog lenne ha minden level feladoja ellenorizheto lenne (mondjuk hogy letezik-e): a spamek nagy reszet mar itt el lehetne dobni.
igen, tudom. igy lehetne cimlistakat is gyartani stb. ez nem egy idealis vilag.

Viszont ha általánossá válna, lehet, sokkal többször használnának fel valóban létező és használt e-mail címet feladóként.
Így is láttam már nemlétező mailcím miatt visszapattant levelet, ami - természetesen - nem a spammerhez került vissza, hanem a cím valós gazdájához...

...most belenéztem a spam könyvtáramba és elképedtem... izé, olyan levelet minek küld valaki, ahol feladóként 20-30 cím szerepel, természetesen címzettként is ugyanezek... de feladónak ennyi különböző címet beírni...

Amúgy ez konkrétan freemail.c3.hu végű fiókba érkezett. Valamiért újabb lendületet kapott ezen címek spamelésre, noha cirka 10 éve nem használt címek ezek.

Na, igen, de mivel az SMTP úgy ahogyan van egy fos, ezért a feladó ellenőrzéssel magadat szopatod, ami nem túl élvezetes.

Ha X400 lenne mindenhol, nem lenne ilyen gond. Sőt, azzal sem lenne gond, hogy Gizike - a gőzeke - titkárnő, akárki, vagy valami fejes felhív, hogy két perce elküldtem egy mailt, a címzetthez meg nem ért oda. És a logokból kiderül, hogy valahol az egyik mailszerveren megtelt a diszk és azért... utána meg magyarázd el a félagyú usernek, hogy nem rajtad múlik. :/

A rendszergazdák élete -sajnos- nem csak játék és mese.

( tilla_canet | 2011. 04. 22., p – 22:46 )

Üdv!

Nem akarok parttalan vitákat indítani, de két dolgot nem árt megérteni.
Először is kéretik a leveleket rendesen "kitöltve" útjára indítani, legalább az olyan helyekről ahol megvan hozzá a "humán" erőforrás (sicc)!
(egy hottentotta helyről jövő hibás levél esetén nem is írtam volna...)

Másodjára a greylist nem oldja meg az ilyen hibákat, csak kevésbé engedi azokat a leveleket át, melyek spam-ként használják ezt a hibás levélküldést.

Ezidáig kb. 1-2 tucatszor kellett utána járnom az ilyen jellegű hibák (értsd: feladó azonosítási hibák) miatt meg nem érkezett leveleknek, de túlnyomó esetben közszolgálati/közületi/iskolai szerverek esetében fordulnak elő. Na vajon miért?

Egyébként valóban egyszerűbb (lenne) szemet hunyni ezek felett (értsd: kivenni az ellenőrzésből).

Tilla

Ez nem fals pozitív. Egyszerűen a levél nem felelt meg az előírt követelményeknek. Ilyet szerintem felesleges a spamszűrőn áttolni is.
Lehet, hogy neked az a módszer, hogy fogadjunk el minden levelet ami csak jön, aztán majd a spamszűrő eldönti, hogy spam vagy /dev/null, vagy megy az inboxba. Nekem nem :).
--
Discover It - Have a lot of fun!

fyi: a spamnek nem az a definicioja, hogy nem felel meg te kovetelmenyeidnek, hanem az, hogy a cimzett nem akarja. A fals pozitiv hiba meg azt jelenti, hogy az egyik userednek cimzett legitim level fennakadt a kovetelmenyeiden, ami ugyan lehet az o benasaga, de az meg a te sarad, ha baltaval operalsz...

[FUN] Így írtok TI! - Utolsó felvonás

Tehát azért tegyük alacsonyabbra a kerítést, mert vannak olyan birkák, akik nem bírják átugrani?
Én úgy vagyok vele, hogy nem terhelem a gépet azzal, hogy a spamszűrő minden mailt nézzen át.

Értem én, hogy nem az a spam, de nem felejtsük el, hogy a spameket leggyakrabban véletlenül vagy szándékosan hanyagul beállított mail szerverek, vagy pedig nem is mail szerverek, csak egyszerű scriptek generálják és szórják. Ezeket pedig remekül meg lehet fogni ezzel. Az egyébként rendesen beállított mail szervereken keresztül jövő mailekre (most az mindegy, hogy lyukas php, vagy usertől megszerzett jelszó), mint pl. a hotmail, azt meg az RBL fogja meg, mert egy idő után nyilván felkerül. A maradéknak pedig ami átjut, még mindig ott a spamszűrő, ami címkézheti spamnek.
--
Discover It - Have a lot of fun!

Apubogár, a mai vasakat egy spamfilter abszolúte nem terheli már meg annyira egy átlagos méretű helyen. Vagy ha nagyon parázol, akkor lehet csinálni akár dedikált spamfilter vasat amin áthajtod az összes levelet és elgyűri. Hacsak nem P3 vagy annál vacakabb x86-os kohótöltelékeket használsz. Ez az érvelés egy éles környezetben már bocs, de elfogadhatatlan.

Felesleges géphez viszonyítani, mert mondjuk percenként 1 levéllel egy p3 is simán elboldogul, ahol meg percenként 1000 levél jön, ott nem mindegy, hogy mind az 1000-ret elfogadod, és áttolod spamszűrőn, vagy ebből 200-at kapásból elhajítasz, és csak a maradék 800-at küldöd át. Kapacitást, vagy akár kiépítéstől függően egy komplett vasat is spórolhatsz, ha már dedikált spam filter.

Értem én, hogy megnőttek a teljesítmények, sokszor annyi mag van, mint pár évvel ezelőtt, de ettől még nem kell pazarolni az erőforrást.
--
Discover It - Have a lot of fun!

Lehet így is érvelni, de amikor a megbízó már másodszor áll ott a hátad mögött, hogy miért is nem kapta meg a fizető ügyfeleitől a leveleket, akkor nem biztos, hogy érdekelni fogja milyen jól is van beállítva az a szerver és mennyire csökkent ezáltal a spam-ek száma. Ha pedig ezáltal elesik egy valós megrendeléstől, akkor annak szintén nem fog túlságosan örülni.
Mi is megpróbálkoztunk ilyennel néhány éve, de a beállítások után folyamatosan a kivétellistákat kellett bővíteni, pedig emlékeim szerint feladó ellenőrzést nem is végeztünk. Szerintem egyáltalán nem éri meg, sem a ráfordított karbantartási idő, sem a presztizsveszteség, sem pedig az esetleges üzleti veszteség miatt.

Semmi értékes levél nem veszett még el emiatt eddig. Amit tudok, hogy rendszeresen bajos, az a hotmail, mikor ismerősön (privát) levelet akar küldeni, akkor van, hogy csak másodjára tudja elküldeni, illetve pár egyáb microsoft-os smtp, főleg ilyen hírlevelek, regisztrációk, esemény részvétel megerősítő mailoknál volt már, hogy visszadobta, mert a küldő domainje nem volt dns-ben feloldható.

Szerencsére nem kell sokat vele foglalkozni, jól működik.
--
Discover It - Have a lot of fun!

Üdv!

Azért inkább megmagyarázom az 1-2 tucat meg nem érkezett levél tulajdonosának, hogy hasson a levél küldőjére azzal, hogy a levelező szervere alul van konfigolva/beállítva, mint magyarázkodjak 2ezer ügyfélnek, hogy bocsi felkerültünk egy "uceprotect" listára, és emiatt nem kapnak levelet.

Tavaly nem kis küzdelmet folytattam, mire lekerültünk, és akkor nagyon komoly rendszabályozást vezettünk be. A zügyfelek ugyanis vakon(!) kattingatnak!

Az eredeti(!) nyitó kérdés nem is ez volt, hanem hogy még mindig vannak ilyen "helyek", ahol komoly, informatikai háttér mellett elképzelhető az ilyen hibás levelezési koncepció!

És még egy, egy korábbi hozzászóláshoz: az ellenőrzést úgy hívják VERIFY.

Tilla

Egy cégvezető, vagy egy alkalmazott nem fog ezzel törődni, Őt az érdekli, hogy nem érkeznek meg a levelei, nem pedig az, hogy hogy van bekonfigurálva a levelezőszerver és ez teljesen érthető is.

Nekem a beidézett naplóból és a hozzászólásokból is úgy tűnt, hogy nem Te relayezel, hanem egy felhasználódnak küldött a fenti szerveren keresztül valaki egy levelet (az most lényegtelen, hogy ki és mit). Azzal, hogy Te elfogadod ezt a levelet függetlenül attól, hogy érvényes-e a feladó, vagy sem nem fogsz felkerülni egy listára sem.

Az eredeti(!) nyitó kérdés nem is ez volt, hanem hogy még mindig vannak ilyen "helyek", ahol komoly, informatikai háttér mellett elképzelhető az ilyen hibás levelezési koncepció!

Igen vannak. És lesznek is. Nagyon sokan. Ez van, ezzel együtt kell élni és ennek ellenére biztosítani, hogy a felhasználók megkapják a leveleiket. Továbbra is szerintem.

És még egy, egy korábbi hozzászóláshoz: az ellenőrzést úgy hívják VERIFY.

Ezt most sajnos nem értem, hogy került ide.

Üdv: Zoli

Egy cégvezető, vagy egy alkalmazott nem fog ezzel törődni, Őt az érdekli, hogy nem érkeznek meg a levelei, nem pedig az, hogy hogy van bekonfigurálva a levelezőszerver és ez teljesen érthető is.

Itt alapvetően nem levelek tömegeiről van szó! Másrészt mint látható volt, azért óvatos duhaj vagyok én is, mert nem 55x -el, hanem 45x -el lett elhajtva a levél! Így indokolt(!) esetben van lehetőség a levél kivételre tételére.
(Magán véleményem, hogy az indok nem elegendő: azaz a cél nem szentesetheti az eszközt. Attól hogy az Ügyfél számára fontos levél "akad" meg, nem kell minden szabályt felrúgni/figyelmen kívül hagyni.)

... Azzal, hogy Te elfogadod ezt a levelet függetlenül attól, hogy érvényes-e a feladó, vagy sem nem fogsz felkerülni egy listára sem.

Való igaz, az ok-okozati összefüggés nem egyértelmű. Azt kell látni hogy sok-sok éves levélszerver üzemeltetés folyamatos lavírozás a "kecske is meg a káposzta is" esete között. Az hogy ennyire "bekeményítettem" csak az utolsó csepp volt a pohárban.. :)

Igen vannak. És lesznek is. Nagyon sokan. Ez van, ezzel együtt kell élni és ennek ellenére biztosítani, hogy a felhasználók megkapják a leveleiket. Továbbra is szerintem.

Mint említettem nekem is ez a célom, emiatt bővülget a kivétel lista. Ha majd nagyobb lesz a tényleg(!) szükséges kivételek listája mint amekkorának kellene lennie, akkor lehet revidiálom a koncepciómat. Addig viszont minimum megkövetelem a levelezés alapvető(!) szabályait.

De egy szösszenetet had tegyek hozzá: Itt nem is annyira azon van a hangsúly, hogy kell-e ilyen ellenőrzés, hanem inkább azon, hogy nem holmi dzsunka szerveren futó kis/nagy céges/magán levelezőn hibás a beállítás/hozzáállás, hanem mint említettem [ön]kormányzat/közület/közszféra/iskola stb. Itt pedig illene meglennie a megfelelő szakmai háttérnek. Tudom: naiv vagyok!)

Ezt most sajnos nem értem, hogy került ide.

Azt hiszem már én se... :)
Valami SMTP pattogásról volt szó...

Tilla

Itt alapvetően nem levelek tömegeiről van szó!

honnan tudod?

hanem 45x -el lett elhajtva a levél! Így indokolt(!) esetben van lehetőség a levél kivételre tételére.

honnan tudod, hogy most eppen adodik egy "indokolt eset"?

Attól hogy az Ügyfél számára fontos levél "akad" meg, nem kell minden szabályt felrúgni/figyelmen kívül hagyni.)

A nem letezo www-data@domain cim es a "minden szabaly" felrugasa kozott en azert erzek ez egy aprocska csusztatast...

Mint említettem nekem is ez a célom, emiatt bővülget a kivétel lista.

Szamomra egy olyan spamszuro, amin folyamatosan kivetellistat kell karbantartani, na meg elotte turni a logokat, az rossz megoldas....

Addig viszont minimum megkövetelem a levelezés alapvető(!) szabályait.

Noha ez esszeruen hangzik, de aki toletek akar megrendelni pl. egy ugyetlenul konfigolt (web+)smtp szerveren at, az legfeljebb atmegy a konkurenciahoz. Abban latom a problemat, hogy rossz definiciot alkalmazol a spamre (=nem felel meg a szabalyaidnak).

nem holmi dzsunka szerveren futó kis/nagy céges/magán levelezőn hibás a beállítás/hozzáállás, hanem mint említettem [ön]kormányzat/közület/közszféra/iskola stb.

Akkor mar te is megertheted, hogy rossz vegen fogod meg a spam problemat...

[FUN] Így írtok TI! - Utolsó felvonás

Azt hiszem alapvető különbség van közöttünk a kérdésben, ami nem baj.

De, kérlek ne keverd a dolgokat: nem a spam -ekről van szó! Itt csak és kizárólag before queue ellenőrzésről van szó!

A spam küldő zombik nagy része pont azt használ(hat)ja ki, hogy a fogadó oldalon a legalapvetőbb ellenőrzésen is át tud csúszni. Az én felfogásom az, hogy az a levél, ami betartja a levelezés szabályait, az már csak és kizárólag a fogadó szubjektív ítélete, szűrése alapján tekinthető spam-nek.

Tilla

mit szolsz a kovetkezo felllashoz? Webhosting egy zsak virtualhost-tal, amelyek kozul az egyiken van egy levelkuldo alkalmazas, de bug-os. Egy spammer megtalalja a rest a falon, es elkezd rajta keresztul par millio spamet kitolni. Ezek a levelek garantaltan be fogjak tartani a levelezes szabalyait, es megis objektiven spamnek tekintheto. Pl. a magyar nyelvu spamek donto resze is szabalyos modon (a protokoll szabalyait betartva) lett elkuldve (es szepen atmennek a te ellenorzeseden, a greylistingen, amit akarsz)....

[FUN] Így írtok TI! - Utolsó felvonás

Akkor jön az a szekció, hogy "lyukas php, vagy usertől megszerzett jelszó":
http://hup.hu/node/102204#comment-1269079
Ezek ellen nyilván semmit nem ér a megkövetelt normális feladó, domain, helo hostnév, RFC-nek megfelelő beszéd. Ezt majd az RBL fogja kiszűrni egy idő után.

De mint mondtam, itt nyilván azt kell észrevenni, hogy ezektől függetlenül azért van rendesen jópár összekókányolt mx, vagy épp nem is mx, csak egy script, amik ellen remekül működik.
--
Discover It - Have a lot of fun!

Ezt majd az RBL fogja kiszűrni egy idő után.

Ez sem jo, mert akkor meg a tobbi, egyebkent legitim levelet fogod eldobni.

De mint mondtam, itt nyilván azt kell észrevenni, hogy ezektől függetlenül azért van rendesen jópár összekókányolt mx, vagy épp nem is mx, csak egy script, amik ellen remekül működik.

hat, ha te mondod.... a juzereid meg ugyse tudjak meg, ha elszorod a leveleiket...

[FUN] Így írtok TI! - Utolsó felvonás

Értem, hogy te spamszűrőt fejlesztesz, így más a felfogásod...

De azért egy gép, ami elkezd spameket okádani magából, ott nem 1-2, meg nem 10-20 levél fog kijönni, hanem mondjuk 30000 óránként, ami közt jóeséllyel van 10 normális levél, az is szanaszét a queue-ban, és az sem biztos, hogy emberi időn belül sor kerül rá. Szerintem teljesen érthető, hogy el fogok hajítani minden arról az ipről érkező levelet...
--
Discover It - Have a lot of fun!

( vl v | 2011. 04. 22., p – 23:22 )

Egyfelől jogos, hogy oldja meg a kedves küldő, hogy létező (ha más nem, egy discard@) mailcím legyen a feladó rovatban.

Másrészt viszont nem értem: Te tényleg SMTP _közben_ próbálod SMTP-n keresztül ellenőrizni, hogy megy-e a MAIL FROM/RCPT TO a megadott küldő címére? Mit lépnél, ha ezen próbálkozásodra a túloldal pont ugyanezt próbálná csinálni? Szép végtelen ciklusba kerülne a két szerver...