a citromail bena spamszurese, es a te meg nem kapott leveleid

Spam, Adathalászat

A citromail egy szokatlan antispam feature-t hasznal, ami az Internet tekintelyesbizonyos reszeirol elutasitja a leveleket. Csak az a baj, hogy ezek nem spam levelek, amelyeket pedig a @citromail.hu cimzettek esetleg elolvastak volna...

http://sj.acts.hu/index.php/2011/07/19/citromail-levelezesi-problema-av…

  • 25948 megtekintés

( Jason v | 2011. 07. 19., k – 12:36 )

eléggé röhejes...
csak azért nem fogok MX-et is csinalni az A melle, ha a vilag !citromail+franchise része elfogadja a leveleimet...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

ha a @domain.hu-nak nincs MX-e, akkor mondhatod, hogy gaz (bar nem egeszen, mert ha nincs MX rekord a domainben {pontosabban a domainre}, akkor a .hu regcheck nem nezi a postmaster@ letezeteset), de a @bela-vagyok.domain.hu-nak nem kell, hogy MX-e legyen, eleg egy korrekt A-rekord (opcionalisan konzisztens PTR-rel)...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Normál esetben ha nincs MX, akkor nem keresi a postmaster@ címet, ha a webes felületet használod. Ezt anno tájékoztató levélben le is írta az ISZT. Azóta meg nem szóltak, hogy ezt az opciót törölték volna. Lehet érdemes lenne szólni nekik, hogy ez gond az API esetében. Az XML interface csinálta?

Aki meg citromailt használ, az megérdemli... Bár mondjuk "másik" oldalról nekünk is keserítették már meg az életünket a "remek" antispam rendszerükkel, mikor teljesen RFC-nek megfelelő leveleket se vettek át, mondván, hogy spam...

( zamboriz v | 2011. 07. 19., k – 20:16 )

> ami az Internet tekintelyesbizonyos reszeirol elutasitja a leveleket.

Gondolom a visszautasított levelek olyan kicsi százaléka nem-spam, mint valami "rendes" spam szűrőnek a hibaszázaléka.

Szolgáltatásnak nem kötelező "teljes"-nek lennie; nekem ezzel nincs bajom.
[ Ide egy jó kis taxis példát írtam, de aztán kitöröltem. Ajándék :-) ]

> ezt ugyan megnezhetem, de kene meg a citromail statisztikaja is.

Arra számítasz, hogy az általad hozzáférhető logok _jelentősen_ eltérnek a citromail-étől? Mindegy, akkor is megnézhetnéd. Kezdek kíváncsi lenni. :-)

> Szerinted elkuldik, ha irok nekik?

Szerintem: nem. Módosítatlanul azért nem kapod meg a logokat, mert vannak benne olyan adatok, amiket nem adhatnak ki. Tehát előfeldolgozni kéne a logokat, de az meg plussz meló. Annyit meg nem ígérsz érte, hogy megérje nekik. :-)

( Rt711 v | 2011. 07. 19., k – 20:43 )

Szerintem jó húzás volt a részükről. Google erőforrásait meg a citromailhez hasonlítani -azért ezt te sem gondoltad komolyan :)

-
Debian Squeeze

( Mcsiv v | 2011. 07. 20., sze – 08:40 )

Az a szomorú, hogy nagy mail guru létedre úgy látom, egyszer nem olvastad át a levelezéssel kapcsolatos RFC-ket.
Az original RFC szerint minden, levelezésbe bevont mail szervernek rendelkeznie kell MD, MF rekorddal.
Az RFC 821 (Simple Mail Transfer Protocol) 1982-ben jött ki, majd 1986-ban az MD/MF rekordokat kivonták a forgalomból és felváltotta őket az MX. Az A record-ra való fallback (mert igen, ez egy fallback) ugyanezzel a lendülettel jött be, azért, mert a DNS véglegesítése úgy kb. 90-ben történt meg (így az A record-ra történő fallback historiális okok miatt maradt meg). Ettől függetlenül, hogy az A recordra való fallback megmaradt, az MX rekord hiánya még RFC ellenes. Ha egy SMTP szerver nem fogad tőled leveleket az MX rekord hiányára vonatkozóan, annak bizony egy oka van, hogy te magad szarul állítottad be a szervered.

ne vitatkozz vele, mert o a guru, aki lyobban tudja, mert o elolvasta az rfc821-et, csak kar, hogy 1982 ota nem update-elt... :-)

Btw. kivancsi vagyok, hogy lehet egy ilyen cimhez MX rekordot rendelni...

update: a codalatosz citromailt tesztelve ezt kaptam:


$ telnet server30.citromail.hu 25
Trying 91.83.45.30...
Connected to server30.citromail.hu.
Escape character is '^]'.
220 server30 mfiltro ESMTP server ready
HELO aaa.fu
250 server30 hello [x.x.x.x], pleased to meet you
MAIL FROM: <apache@[x.x.x.x]>
550 5.1.0 <apache@[x.x.x.x]> domain literals not allowed
QUIT
221 2.0.0 server30 mfiltro closing connection
Connection closed by foreign host.

Nesze neked RFC...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Nem értem, mi bajod van vele. Ha nem tetszik valami, akkor mondd meg (trey te is).
1. zavarnak az elpocsékolt megák, bocs, amikor én kezdtem, 20M küröl jártak a winyók
2. zfs-t használok
3. mi a fenének egy 200 vhostot kiszolgáló szervernek 200 MX meg 200 alias, mikor a postmaster ua? Pláne, ha már nem is kell, mert a domainesek is rájöttek, hogy baromság?!?
Ha valaki nem ért ezekkel egyet, lelke rá, ezek az én saját, privát, külön bejáratú veleményeim.

a beérkező spamek 15%-át fogja meg, nem csoda hogy sjspammer úr ennyire kapálózik ellene

false positive természetszerűleg nincs, néhány senkinek se hiányó rosszul konfigolt hírlevél pattan le (ahol sj-tipusú adminok vannak), meg van egy szolgáltatás ami a két szerveréből az egyiken invalid MAIL FROM-mal küld, majd észreveszik

Tehát van egy csomó false positive, csak éppen nem érdekel, mert megteheted, hogy ne érdekeljen. Sok helyen nem tehetik meg, hogy ne érdekelje őket a false positive, ezért ez nem jó szűrés. Nagyon sok olyan spam szűrési mód van, amely egymagában kiválóan ki tudná dobni a spam-ek felét, csak közben túl sok lenne a false positive, és ez a szűrés is ilyen.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mert alkalmazkodtam a helyzethez és nem volt nagy munka, miért ne tettem volna ezt meg? Dacból?

Ettől függetlenül a citromail oldalán továbbra is sok marad a false positive, de mivel a citromail egy a sok ingyenes levelezőrendszer közül, ezért valószínűleg nem érdekli őket, amíg nem okoz túl nagy fluktuációt. Téged se érdekel a false positive, mert nem okoz közvetlen vagy közvetett anyagi veszteséget, különben foglalkoznál a problémával.

Ugyanezt egy cég nem teheti meg, ha fontos az ügyfelek levele, mert minél több hibás szűrést alkalmaz, annál több normál levél esik ki, amelyek között van potenciális és valódi ügyfélvesztés. Cégeknél fel kell tenni a kérdést, hogy mi okoz nagyobb veszteséget: naponta kitörölni 20-50 spamet, vagy havonta elveszteni egy meglévő vagy egy leendő ügyfelet?

Vannak cégek, ahol az első a kisebb veszteség, vannak cégek, ahol a második a kisebb veszteség. És persze van, aki érti a két dolog között a különbséget, van, aki nem.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

En is magyaraztam ennek a kis tehetsegesnek, de csak nem erti, hogy ez miert problema. De rajottem, miert: azert, mert o ket forrasbol kap leveleket. Az egyik a mailer daemon (ezek lennenek a jo levelek), a masik meg a zombik, amelytol ha el is utasit par levelet az MX ellenorzessel, nem faj senkinek...

Deutsch: Ki a fasz az a Thomas Melia?

egyértelmű hogy miért nem bírod megemészteni azt a dolgot, hogy egy levelezni szándékozó domain-nek legyen MX rekordja. Ennek az egyetlen egy oka, hogy azt bizonyítanád be az elismerésével, hogy tényleg te basztad el már a legelején. Ne hivatkozz az A fallback-re, hogy az azért van. Nem, az pont a hasonszőrű gyökerek miatt van;]

Három dolgot kell megemészteni:
- a világ nem mindig úgy működik, ahogy a törvények, a szabályok, a szabványok vagy az előírások szólnak
- nem feltétlen jó dolog egyedül betartani a szabályokat
- üzleti szempontból nem feltétlenül jó dolog olyan dolgok alapján megszűrni az ügyfeleket, amelyről nem ők tehetnek

Hozzá kell tenni, hogy az RFC 5321 egészen pontosan megmondja, hogy miképp kell kezelni az MX rekordot, idéznék belőle:
The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as
if it were the initial name. If a non-existent domain error is
returned, this situation MUST be reported as an error. If a
temporary error is returned, the message MUST be queued and retried
later (see Section 4.5.4.1). If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host. If MX records are
present, but none of them are usable, or the implicit MX is unusable,
this situation MUST be reported as an error.

Lehet, hogy rosszul értem, de szerény véleményem szerint teljesen RFC compliant az, hogy az SMTP szerverek nagy többsége az A rekordban szereplő IP felé küldené a levelet, ha nincs MX rekord. Persze mondhatni, hogy hibás konfiguráció -- ezzel egyetértek, mert kellene MX rekord, de ha nincs (mert nem lehet megoldani bármilyen oknál fogva), attól még teljesen RFC compliant, és nem egy 20 éves RFC-ről van szó...

Ha ezeket sikerült megemészteni, már nem is annyira érdekes a dolog. Részemről megoldottam az MX rekord létét, ettől fogva engem a probléma nem érdekel különösebben, de a citromail felhasználói továbbra se kapnak meg olyan leveleket, amelyek amúgy legális levelek. Mivel a spam szűrések többsége sérti az összes SMTP-vel kapcsolatos RFC-t, azért teljesen mindegy, hogy egy spam szűrés RFC compliant-e vagy sem. Egy dolog nem mindengy: mennyi a false negative és a false positive a szűrésnél, ezeket kell minimalizálni és minél fontosabb a levelezés, annál inkább fontos az, hogy a false positive erősen közelítsen a nullához, akkor is, ha ez a false negative rovására megy. Egyébként a spam szűrésnek nem lenne feladata, hogy kezelhető konfigurációs és technikai problémák okán dobjon el levelet, hanem az, hogy elsődlegesen a levél tartalma alapján szűrje ki a nem kért leveleket.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

nem tudsz olyan okot mondani, ami miatt nem lehet megoldani az MX rekordot.
Emésszétek meg, hogy az MX rekord hiánya a nem normális, nem pedig az, hogy valaki ezt ellenőrzi.
Rengetegen ellenőrzik ezt, így egy smtp expert, mint sj, azt állítja hogy ez faszság, ez csak az ő véleménye és nem reprezentatív a véleménye RFC szempontból. Hála égnek a világ nagyobbik fele jól működik (citromail, externet, index és még sorolhatnám).

Ha nem lennének betartva az RFC alapszabályai, a hülye A fallback se működne amire hivatkoztok, vagyis az RFC pontrol pontra be van tartva. Addig, míg lesznek olyanok, akik lazán kezelik az ilyen kérdést, lesznek problémák, hogy valami nem működik (pl.: hogy az smtp expert levelei nem mennek el).

csak osszefoglalaskeppen megegyszer, hogy ne vethesd a szememre, hogy nem mondtam (de jo volna, ha most venned a faradsagot, es probalnad megerteni): a _domainnek_ _van_ MX rekordja.

Rengetegen ellenőrzik ezt, így egy smtp expert, mint sj, azt állítja hogy ez faszság, ez csak az ő véleménye és nem reprezentatív a véleménye RFC szempontból. Hála égnek a világ nagyobbik fele jól működik (citromail, externet, index és még sorolhatnám).

fail. A gmail nem tokol ezzel, a yahoo nem tokol ezzel, a hotmail nem tokol ezzel, a freemail nem tokol ezzel, a t-online nem tokol ezzel, .... Ez a citromailes bagazs, meg az externet (nem is szolva kapucsinorol, megalol) szerinted hasonlo sulycsoportban vannak, mint akiket en emlitettem? Nevetseges. Vagy meg inkabb szanalmas. Szoval verheted magad, hogy az A-fallback gonosz/whatever, de ez a te ugyed, meg aze a par benae, akiket felhoztal peldakent, akik RFC-serto modon probalnak megszabadulni a spamtol, nem torodve azzal, hogy ezzel szuksegszeruen otromba fals pozitiv hibakat vetenek.

Mondom, ez nem problema, amig magaddal vagy a mailer daemonnal levelezel (mint pl. kapucsino), vagy egy csumpi ingyenes email szolgaltatast csinalsz (mint a citromail), de amikor uzleti felhasznaloid is vannak, akik nem orulnek, ha (es akkor most emesszed ezt szepen) egy benabela _AKARMIERT_ eldobja a nekik szant legitim leveleiket, akkor jo, ha nem RFC-serto modon szurod a spamet. Mert lehet meg sok mas modon is, amelyek nem okoznak ilyen durva FP-hibakat...

Deutsch: Ki a fasz az a Thomas Melia?

az a baj, hogy a srac emos, es amiota a cure nevu banda mar visszavonult, mar csak sp maradt, aki szobajohet nala. Csakhogy! sp ott rugta el nala a pottyost, hogy amikor a szunetben betoppant sp oltozojebe, akkor ott talalta F. Tomit. Namost hogy a feltekenyseget hogyan eli meg, annak itt lehetunk tanui a hupon...

Viktor az eletrol es a halalrol

meg mielott nagyon belemelegednel a kioktatasba, elmondom, mert meg kopasz vagy az alig 1 eves regisztracioddal, es keveset lattal, hogy ideje van a szep szonak, ideje van az erelyesebb szonak, ideje van a nevelesnek, es most ideje volt egy kis ekezesnek is. Amiatt meg ne fajjon a fejed, mert nem dolgod azt megitelni, hogy en mibol es hogyan jottem ki...

Viktor az eletrol es a halalrol

Bevallom, egy kicsit bajban vagyok veled. Szoval az a bajom veled, hogy te is az a 'pain in the ass' fazon vagy, aki, mint egy a cipotalpra tapadt kutyaszar, edesiti meg az ember napjait. Ez magyarra leforditva annyit tesz, hogy a szexualis eleted abban merul ki, hogy folyton a sarkamban lihegsz, es probalsz belem kotni a temahoz a legkevesbe sem kapcsolodo beszolasaiddal.

Namost ezek utan, ha erdeklodsz, hogy merre van a lejjebb, akkor furan erzem magam, es bevallom, nem ertem a kerdest. Talan egy mazochista emos vagy, akinek ugy kell a napi leekezes, mint a BDSM-es klubtagoknak egy jo seggelintezes, es azert provokalsz folyton, hogy vegre megkapd, vagy mit tudom en. De azt biztosan tudom ezek utan, hogy a te iteletalkotasod hazug. Eppen ezert kb. ennyi hitelt is adok neki, es kb. ennyit is er a szememben a szanalmas es alszent kifakadasod...

Viktor az eletrol es a halalrol

Igen, hibás, mert egy kiegészítést nézel, a rá való hivatkozásokat nem (Olvasd el, mely pontokban hivatkoznak az általad említett 4.1.3 Address Literals-ra).
A levélküldésnél a possible szó az lehetséges, nem előírt. Ki lehet emelni az RFC-ből dolgokat (mint ahogy fennt az A record fallback-et is), csak nincs értelme

Hogy en elolvastam-e (vagy sem), az egy dolog. De neked tenyleg illett volna, ha ezt akarod a fejemhez vagni. Nos, az rfc5321 5. fejezete szerint:

"The lookup first attempts to locate an MX record associated with the name. [...] If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host."

Szoval az valoban igaz, hogy eloszor az MX rekordot kerdezi le, de aztan (ha nem talal ilyet, akkor) folytatja az A rekorddal, meghozza az RFC szerint. Tehat ha nincs MX, de van A, akkor az megfelel a szabvanynak.

De igazad van, ez az rfc 2008-as, a citromail meg 2004-ben indult. Azonban az rfc2821 (amelyik 2001-tol hatalyos) detto ugyanigy irja le az MX vs. A rekordok viszonyat ill. hasznalatukat. Az MD/MF/.... rekordok, meg az rfc821 ide citalasa, gondolom en, csak joke volt, mert 2011-ben egyik sem relevans...

Mondom, meg ha sertenem is az RFC-t (de nem), akkor sem all meg a citromail ervelese, miszerint az MX rekord alapjan eldontheto (mert ok eldontik), hogy az smtp kliens egy otthoni gep vagy sem, ti. ok ezert alkalmazzak ezt az ellenorzest, nem pedig azert, mert ok akarnanak nekem levelet kuldeni.

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Ha már ennyire felhoztad az új és általad említett RFC-t, az első 20 sorban le van írva, hogy ez egy kiegészítés, vagyis nem bírálja felül az előtte lévő RFC-ket. Az általad említett metódus továbbra is fallback, az eredeti, az új RFC szerint is hivatkozott leírásban pedig a mail szervereket továbbra is MX rekorddal jelöljük (még akkor is, ha valójában nem akarunk levelet fogadni rajta, ezt pedig a NULL MX rekord fejezi ki).
Az általad említett végső pont pedig az, hogy egy SMTP kliensnek egyébként nincs hatályos joga (RFC szerint) közvetlen levelet kézbesíteni egy SMTP szervernek (delivery protocol alapján ez levél feladásnak minősül, melyet előbb a lokális (lds-nek) kell feladnia a kliensnek, majd az a megfelelő routing szabályok alapján kézbesíti a levelet a végcéljához.)
Ráadásul nem kliens/szerver hibaüzenet volt ez, hanem hogy a feladó domain-nek nincs valid mx rekord bejegyzése (vagyis az eredeti RFC alapján nem minősűl smtp szervernek), az utólagos RFC-k alapján pedig fallback-elhet, ha szeretne, de ők úgy tűnik nem akarnak (ami érthető, hogy nem fogadunk szarul beállított domainről leveleket).

Pont az ilyen szarul beállított levelezőszerverek és domainek miatt van annyi spam, amennyi.

Ezzel persze nem azt mondom, hogy az én levelező szervereim tökéletesen és strict módban veszik az RFC-t, csupán azt, hogy ha végre van valaki, aki komolyan veszi a dolgot, annak örülni kéne, pont az előző mondatom miatt.

ez egy kiegészítés, vagyis nem bírálja felül az előtte lévő RFC-ket.

Ja, valoban furcsa pl. ez a mondat: "It consolidates, updates and clarifies, but does not add new or change existing functionality of the following". Kerdes az, hogy a 2 ujabb RFC 5. pontban szereplo leirasa funkcionalitast modosit (vagy ujat hoz be), avagy inkabb pontosit?

Az általad említett végső pont pedig az, hogy egy SMTP kliensnek egyébként nincs hatályos joga

FYI: smtp kliens az, aki egy smtp szerver szolgaltatasait veszi igenybe, tehat akar egy masik smtp szerver is lehet, mint pl. jelen esetben. Aztan kivancsi vagyok, hogy ha egy tavoli gep megszolit a 25-os porton, akkor megis mi alapjan mondod meg, hogy o kozvetlen levelkezbesitessel probalkozik ...

Pont az ilyen szarul beállított levelezőszerverek és domainek miatt van annyi spam, amennyi.

Az valoban igaz, hogy a rosszul beallitott dolgok miatt tobb a spam, de nezzuk meg, hogy ez a citromailes benazas vajon tenyleg csokkenti-e? Ha lattal mar spoof-olt levelet, aminek valodi, pl. @gmail-es, @freemail-es, stb. envelope-pal kuldte el a levelet, akkor te is belathatod, hogy ez az MX rekordhoz valo irracionalis ragaszkodas semennyivel nem csokkenti a spamek szamat, hiszen pl. a @gmail.com-nak van MX-e, vagy a spoof-olt domainnek szinten van MX rekordja (meg az enyemnek is). Fals pozitiv hibat viszont okoz. Ha nalad ez a 'komolyan veves', akkor reszvetem...

Szoval az allaspontom tovabbra is az, hogy nem RFC kompatibilis arra rafogni egy level elutasitasat, hogy a felado domainnevnek nincs MX rekordja, ha van A. Arrol nem is beszelve, hogy a citromail kifogasa sem RFC-sertesrol szol (mert nem is szolhat arrol), hanem valami homalyos antispam torekvesrol, ami inkabb ugyetlen, mintsem hatekony...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

"FYI: smtp kliens az, aki egy smtp szerver szolgaltatasait veszi igenybe, tehat akar egy masik smtp szerver is lehet, mint pl. jelen esetben. Aztan kivancsi vagyok, hogy ha egy tavoli gep megszolit a 25-os porton, akkor megis mi alapjan mondod meg, hogy o kozvetlen levelkezbesitessel probalkozik ..."
Ezzel egyetértünk, ezért van az RFC-ben a reverse és a fent említett mx check.

"Ha lattal mar spoof-olt levelet, aminek valodi, pl. @gmail-es, @freemail-es, stb. envelope-pal kuldte el a levelet, akkor te is belathatod,"
Viszont a spambotok 90%-a meg xyzqwe012.asd -rol küld levelet (legalábbis hozzám tucatszám érkezik be ilyen)

"Fals pozitiv hibat viszont okoz. Ha nalad ez a 'komolyan veves', akkor reszvetem..."
Nem okozna, ráadásul mivel rfc-hez kötött, éppenséggel még csak nem is fals. Feltéve, ha képes lennél úgy beállítani, ahogy kell (az A rekord továbbra is fallback, pont az ilyen szarul belőtt szerverek miatt van)

Egyébként az elgondolás jó, én is belőttem az MX checket. Aztán aki képtelen mail szervert üzemeltetni és azon lovagol, hogy valaki elutasítja a hibás beállításból származó fallbacket, az bizony pusztuljon meg

Ezzel egyetértünk, ezért van az RFC-ben a reverse és a fent említett mx check.

OK, ha van hozza 'reverse' (talan a PTR rekordra gondoltal?) es MX rekord (es miert ne lehetne ilyen az otthoni kabeles gepemnek), az tenyleg segit rajtad?

Viszont a spambotok 90%-a meg xyzqwe012.asd -rol küld levelet (legalábbis hozzám tucatszám érkezik be ilyen)

akkor erezd magad szerencsesnek...

Nem okozna, ráadásul mivel rfc-hez kötött

tudom, hogy nem valtozik meg a velemenyed, de hadd tartsak mar ki en is amellett, hogy az RFC ilyet nem kenyszerit rad, es ha egy domainben egy hostnak csak egy A rekordja van, az az RFC szerint siman fogadhat(na) leveleket.

Aztán aki képtelen mail szervert üzemeltetni [...] az bizony pusztuljon meg

Ismeros? "nem azt mondom, hogy az én levelező szervereim tökéletesen és strict módban veszik az RFC-t". :-)

Mondom, engem aztan az is hidegen hagy, ha kihuzod a gepedbol az eth kabelt, csak arra figyelj, nehogy a vernyomasod tulzottan felmenjen. Elotte azert ird meg, hogy melyik domainbe ne kuldjek ilyen levelet.... LOL

Nepszava: az elso celpont a mediatorveny celkeresztjeben

... az mar csak plane, hogy ha regelek egy domaint, majd belerakom rekordnak a zombinet osszes gepet, akkor onnantol van valid MX bejegyzes, oszt szevasz. és mire lelovik a .ru-s vagy .cn-es domainnevet, addigra el is ment hatszazezermillio spam email.

jól sejtem, hogy ez így működne?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

megteheted, de nem egeszem errol van szo.

Legyen a zombi gep IP-cime 1.2.3.4, amihez a szolgaltatoja a cable-1.2.3.4.dyn.comcast.net PTR-t rendelte (es nyilvan letezik a dyn.comcast.net nevu domainben a cable-1.2.3.4 domainnev is).

Legyen a zombi domained neve jzombi.net, amelyre beallitasz egy MX rekordot, es a fenti gephez hozzarendeled a comcast1234.jzombi.net nevu A rekordot. Ha a citromailt is meg akarod szorni, akkor van nehany opciod:

a) a mail from utan azt ird, hogy akarmi @ jzombi.net

b) vagy azt, hogy akarmi @ comcast1234.jzombi.net, de ekkor csinalj egy MX rekordot is a comcast1234.jzombi.net-nek

c) vagy spoof-olod a letezodomain-mx-rekorddal.net domaint, pl. akarmi @ letezodomain-mx-rekorddal.net

Az a)-t azert szoktak hasznalni, a b)-t nem tartom tomegesen elterjedtnek (ami erositi a citromail poziciojat), annal inkabb a c)-t (ami viszont kb. haszontalanna teszi ezt a vedelmet).

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Ha hirtelen minden RFC-t betartanának a hálózati eszközök, akkor hirtelen eltűnne az egész most ismert internet...

Hozzátenném, hogy szerény véleményem szerint komoly probléma önkényesen ezt-azt keményen és zsigerből betartatni, miközben ezer más RFC megsértésével nem törődni, közben pedig olyan magyarázatot adni a keményen betartott szabályra, amely nem állja meg a helyét.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezen gondolkodj el egy kicsit, mert attól nem csökkenne érdemben a spam mennyisége, ha elkezdenénk RFC szerint működni... a spam küldő botneteket pillanatok alatt átállítanák RFC kompatibilis módra, ellenben a világ többi része -- akik használnák az email-t, mint üzenetküldő szolgáltatást -- hetekig-hónapokig-évekig nem tudnának egymással levelezni, amíg kiderülne, hogy hol van "szűk keresztmetszet" a két MUA között.

Egyébként kíváncsi lennék arra, hogy ha magad elé tennél egy Zorp-ot full RFC compliance konfiggal, akkor meddig bírnád... mert szerintem percek múlva tépnéd a hajad, annyi minden nem menne, amit megszoktál... egyszer próbáld ki, megéri. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Az RFC-nek így is megfelel minden, ha nem felelne meg, egyébként sem működnének ezek a dolgok. Itt a problémák abból adódnak, hogy az elején azért, mert a DNS nem volt elterjedve, engedélyezésre kerültek olyan dolgok, mint az address literals, az A record fallback, a reverse hostok nem ellenörzése.
Pont ezen, alapértelmezettként nem engedélyezett kiegészítések miatt van az most, ami.
Ez pont ugyanaz, mint az éppen küszöbön álló ipv6 esete, mikor egy része átlépte a küszöböt, másik része megbotlott benne de már úton van, a harmadik fele meg le sem szarja. Ugyan ez volt annó az smtp esetében, így bejöttek ezek a szarságok a lemaradtak részére hogy ők is tudják használni, azóta meg toldják szegény istenverte rfc-t még egy halom szarsággal, hogy AZOK AZ EMBEREK, AKIK KÉPTELENEK EGY MX REKORDOT BEÁLLÍTANI, tudjanak levelezni.

Az RFC-nek így is megfelel minden, ha nem felelne meg, egyébként sem működnének ezek a dolgok.

Ez egy súlyos tévedés, nagyon sok dolog nem felel meg az RFC halmaznak, mégis működik valahogy az egész spagetti internet.

Itt a problémák abból adódnak, hogy az elején azért, mert a DNS nem volt elterjedve, engedélyezésre kerültek olyan dolgok, mint az address literals, az A record fallback, a reverse hostok nem ellenörzése. Pont ezen, alapértelmezettként nem engedélyezett kiegészítések miatt van az most, ami.

Teljesen mindegy, hogy mi volt a történelmi előzménye, valamilyen oknál fogva elterjedt a "hibás" működés és a világ igen nagy része vígan használja így a szoftvereket, legyen az MTA vagy MUA. A legtöbb MUA mindenféle hülyeséget csinál, amit aztán az MTA többsége többé-kevésbé tolerál, illetve a legtöbb alapbeállításokkal MTA szintén csinál hülyeséget, amit aztán a többi MTA kell korrigáljon. Ez egy ilyen világ. Ha ebben a világban megkövetelnél 100% RFC compliance működést, akkor a spamek pár napos megtorpanás után jönnének, ahogy eddig, az emberek meg áttérnének a Facebook/Google/Microsoft trió valamelyik üzenetküldő megoldására. Persze mellékesen lenne egy kisebb-nagyobb gazdasági válságocska, meg ilyesmi, de ennyit megér az, hogy rend van az SMTP protokoll körül, nem?

Ugyan ez volt annó az smtp esetében, így bejöttek ezek a szarságok a lemaradtak részére hogy ők is tudják használni, azóta meg toldják szegény istenverte rfc-t még egy halom szarsággal, hogy AZOK AZ EMBEREK, AKIK KÉPTELENEK EGY MX REKORDOT BEÁLLÍTANI, tudjanak levelezni.

Csak nem Te vagy a citromail rendszergazdája? Ennyire nem kell a szíveden viseld ezt a dolgot. :)

A kérdés az, hogy van-e spamszűrés szempontjából értelme ennek az MX ellenőrzésnek. Kell keresni egy HUP tagot, akinek napi párezer levél mellé beesik pártízezer spam, majd megnézni, hogy ezek a spam-ek hány százaléka bukik meg ezen az ellenőrzésen, illetve a legális levelek hány százaléka nem érkezik be.

Volt már pár eset, amikor rákérdeztem egy-egy cégnél a rendszergazdánál, hogy mire fel az a komoly szűrés, amelyet alkalmaznak, s a rendszergarázdák többsége bőszen védte az elképzelését -- citáltak mindenféle RFC-t és szokásjogot, aztán rákérdeztem az ügyvezető igazgatónál is erre a dologra, aki nem is tudott arról, hogy milyen agresszív szűrést használnak, és hogy nem érkezik be a pénzt hozó megrendelés és csodálatos módon másnaptól ezeknél a cégeknél fogadták a leveleket.

Ennél érdekesebb helyzet az, amikor a cég rendszergarázdája szinte terrorizálta a cég vezetőjét is, és kialakult az az érdekes helyzet, hogy a megrendeléseket nem a megrendelés kukac cégnév.hu címre kérte a cég, hanem a cégnév.megrendelés kukac freemail.hu címre, mert oda mindenkitől megjött.

Szóval lehet ragaszkodni a végsőkig a szabványokhoz és szabályokhoz, de nem biztos, hogy attól működni is fog a dolog... főleg, ha elterjedt egy "hibás" - de működő - használat, mert ugye lehet hibás a szabvány és/vagy a szabály is...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

rákérdeztem egy-egy cégnél a rendszergazdánál, hogy mire fel az a komoly szűrés, amelyet alkalmaznak, s a rendszergarázdák többsége bőszen védte az elképzelését -- citáltak mindenféle RFC-t és szokásjogot

:-)

amikor a cég rendszergarázdája szinte terrorizálta a cég vezetőjét is, és kialakult az az érdekes helyzet, hogy a megrendeléseket nem a megrendelés kukac cégnév.hu címre kérte a cég, hanem a cégnév.megrendelés kukac freemail.hu címre, mert oda mindenkitől megjött.

igen, egyesek nem ertik meg, hogy egy fp hiba sokkal rosszabb, mint 10 beeso spam...

főleg, ha elterjedt egy "hibás" - de működő - használat

de megha hibas lenne, azonban az ervenyes az rfc-k szerint nem az...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

rfc szerint mukodni jo dolog, mert ez garantalja, hogy kulonbozo rendszerek kepesek legyenek egyuttmukodni. A gond csak akkor van, ha egyesek nem kepesek ertelmezni egy rfc-t, ill. kovetni azt, ha egy ujabb rfc 'obsoletes' egy korabbit. Tudod, ez az egy orult az autopalyan szemben a forgalommal kezdetu vicc esete. Mcsiv pont ennyire meg van gyozodve az igazarol, es kb. pont ennyire is van igaza...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Ez így van, az rfc jó dolog, a végéről van véleménykülönbségünk.
"Tudod, ez az egy orult az autopalyan szemben a forgalommal kezdetu vicc esete."
Ez SMTP esetében inkább úgy néz ki, hogy megengedik a magyaroknak, hogy a pálya bal oldalán menjenek, mert angliában is lehet.
Lehet egyetérteni, illetve nem, de most arról próbálsz meggyőzni, hogy jó ilyen címekről levelezni, mert egyszer megengedték azért, mert nem volt más:

user@dsl540259.pool.t-online.hu
user@84.2.89.200

Egy levelezni szándékozó domain-nek legyen MX rekordja és ne az egyébként totál felesleges fallback-ek tartsák fennt a működését.

Ha meg nem akar levelet fogadni az adott domainre, arra is van lehetőség (de akkor meg ne küldjön levelet se)

maradjunk abban, hogy ez a te allaspontod, amit meghagyok neked. Az Internet nagyobbik resze (pl. gmail, yahoo, de meg a freemail is, akiknek a citromail imho legfeljebb egy pohar vizet hozhat) kepes RFC szerint mukodni (=megelegedni az A-rekorddal, ha nincs MX). Szoval a helyzet valojaban eppen forditott a te autopalyas hasonlatodban.

de most arról próbálsz meggyőzni, hogy jó ilyen címekről levelezni, mert egyszer megengedték azért, mert nem volt más:

Nem egeszen. En arrol probaltalak meggyozni, de mar nem teszem, hogy nem kegybol engedtek meg, hanem a szabvanyok ezt 2001 ota lehetove teszik (az rfc821-et valoban regen olvastam, de mint irtam, mara az obsoleted, ha erted, hogy ez szo mit jelent...).

Egy levelezni szándékozó domain-nek legyen MX rekordja és ne az egyébként totál felesleges fallback-ek tartsák fennt a működését.

szived joga ilyet beallitani, csak legy szives, ne akard masoknak eloirni, hogy a te rfc sertesedhez igazodjanak. Mondom, ha komoly gazdasagi erdekuk fuzodik hozza, mert pl. te vagy a Nagy Ugyfel terrorizalo rendszergazdaja (kossz, Franko ;-)), akkor - okosabb enged alapon - lehet, hogy beallitjak a tuloldalon.

Ha meg nem akar levelet fogadni az adott domainre,

Az a legszebb az egeszben, hogy az az x gep amugy az egy szem A-rekordjaval _fogadja_ is a leveleket, es le merem fogadni, hogy ezek a bena gepek (a tieddel egyutt, csiiiz!) el is tudnak oda kuldeni...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

"kepes RFC szerint mukodni (=megelegedni az A-rekorddal, ha nincs MX)"
Igen, képesek használni a mára feleslegessé vált A rekord fallback-et (mert pont ezért van MX, csak van pár idióta aki képtelen beállítani és inkább veszekedik róla, hogy hülyeség:))

"Nem egeszen. En arrol probaltalak meggyozni, de mar nem teszem, hogy nem kegybol engedtek meg, hanem a szabvanyok ezt 2001 ota lehetove teszik (az rfc821-et valoban regen olvastam, de mint irtam, mara az obsoleted, ha erted, hogy ez szo mit jelent...)."
De, kegyből engedték meg, látom még mindig csak nézegetted az ide vonatkozó RFC-ket. Gyönyörű szépen le van benne vezetve, hogy mit miért tettek. Az a szerinted obsoleted RFC-t használod mind a mai napig, az azóta érkezett RFC-k kiegészítések és javarészt másról is szolnak.

"szived joga ilyet beallitani, csak legy szives, ne akard masoknak eloirni, hogy a te rfc sertesedhez igazodjanak."

Vagyis szerinted én sértek azzal RFC-t, hogy beállítom a világ összes pontján használt MX rekordot, ami ráadásul a mail szervereknek lett kitalálva? Uhh, elnézést kérek érte, vajon az összes smtp szerver véletlenűl próbálja meg az MX rekordokat keresni előbb, aztán ha balfasz volt a rendszergazda, A rekordra fallback-el:)

"Az a legszebb az egeszben, hogy az az x gep amugy az egy szem A-rekordjaval _fogadja_ is a leveleket, es le merem fogadni, hogy ezek a bena gepek (a tieddel egyutt, csiiiz!) el is tudnak oda kuldeni..."

csiiiz! Valoszinuleg en vagyok a hulye es nem te, mert te nem allitasz be MX rekordot:)
Erdekes jelenseg egyebkent, hogy a nagy domain regisztratorok alapból (pl.: godaddy), a nagy cegek (google.com, microsoft.com), de még a hup is képes volt arra hogy MX rekordot állítson.

Summa: Biztos én vagyok a hülye azért, mert nem tudsz MX rekordot beállítani egy domainre és arra hagyatkozol, hogy fallbackeljen az smtp szerver. Az általad emlegetett friss RFC-k is fallback-ként említik ezt, ha már felhoztad az angolt is, gondolom biztos tisztában vagy a jelentésével:) Végülis mindenkinek jogában áll hülyének lenni, de akkor meg ne sírjon hogy nem tud levelet küldeni valamilyen irányba:)

Vagyis szerinted én sértek azzal RFC-t, hogy beállítom a világ összes pontján használt MX rekordot

Nem. Akkor sertesz rfc-t, ha te kenyszerited a _kuldo_ oldalt, hogy legyen MX rekordja. Nem tudom, erted-e a kulonbseget...

Biztos én vagyok a hülye azért, mert nem tudsz MX rekordot beállítani egy domainre

csak ezert ne legy hulye, mert (leirtam pedig mar) a _domainre_ van MX. Azonban masert lehetsz(/vagy?) hulye (ha mar igy jellemezted magad, en nem fogok ellenkezni veled :-)), de 20-adjara mar hadd ne irjam le, nekem nem er ennyit a dolog (ezt is leirtam). Ami pedig a sirast illeti: a jelek szerint te nem tudsz a dolog felett napirendre terni. Ej-ej, vadasz, te megint nem vadaszni jottel...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

"Nem. Akkor sertesz rfc-t, ha te kenyszerited a _kuldo_ oldalt, hogy legyen MX rekordja. Nem tudom, erted-e a kulonbseget..."
Nem, mert tudod létezik egy olyan, hogy bounce mail, vagyis joggal várható el a küldő domaintől és szervertől, hogy tud fogadni leveleket nem csak ész nélkül szórja őket a nagy világba:)

A hülyeségem meg felvállalom, mivel leálltam dilettánsokkal állok le vitázni:)

( wyx v | 2011. 07. 20., sze – 11:13 )

Véleményem szerint nem baj az, hogy nem minden "A" rekord engedélyezett a levélküldésnél.
Léteznek olyan helyek, ahol az "A" rekordok automatikusan létrejönnek tonnaszám, ezek nem bizta, hogy jó, ha leveleznek is.
Aki meg akar levelezni, az jegyeztessen be magának MX-et, ennyi fáradtságot vegyen...

( zwei | 2011. 07. 20., sze – 12:20 )

szerintem módosították a konfigot, mert egy ideje kimennek a leveleink a citromailra.
Gondolom szinte senki nem tudott nekik levelet küldeni, nem hiszem, hogy túl sok mail szerver fqdn-jéhez létezne külön MX rekord. (Ha jól látom, pl. a google.com MX rekordjaiban levő szerverekhez sincs külön MX rekord.)

szerk: ok, nem biztos, hogy a google.com MX rekordjában szereplő szerverek küldik ki a leveleket, viszont a logokból találomra kiválasztott mail-ew0-f53.google.com -nak sincs MX rekordja.

ok, de a citromail a leveleinket konkrétan azért vágta vissza, mert a mail szerver fqdn-jéhez keresett mx rekordot. Nincs már meg ide vágó log, de anno elég sokat gondolkoztam azon, hogy mi a francért csinálnak ilyet.

Amit a "mail from"-ról írsz, az teljesen igaz, viszont az évek óta normálisan van konfigurálva a szerverünkön. (és kb. minden normális szolgáltató visszadobná, ha nem így lenne.)

Mivel mx-eket nem piszkáltam, és most ránéztem, és megy, gondolom valamit ők módosítottak.

Hazi feladat: keresd ki azokat a hosszaszolasaimat, amelyekben szerinted szemelyeskedtem, aztan olvasd el elotte, hogy mit irtal...

Mondom, nem akarlak feltetlen meggyozni sem errol, sem arrol. Probalj meg lehiggadni, es tultenni magad az ugyon, mert szemmel lathatoan felizgattad magad egy kisse...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

Tévedsz, nem izgattam fel magam, csak nem értem az értetlen embereket.
Most is éppen megpróbálod megmagyarázni azt, hogy én kezdtem a személyeskedést (Olvasd el a két kommentet: míg az enyém egy erősen cinikus ábrázolás volt, a tiéd már személyeskedő)
Tudom, nehéz megkülönböztetni a kettőt, de azért nah... Minden esetre okoztál egy két kellemes percet:)

Hogy mi hova valo, azt majd en eldontom. Valami nyugi bogyo tenyleg rad ferne, mert egy kisse tulreagalod, hogy nem ertek egyet az smtp rfc-ket kommentalo velemenyeddel (ami egyebkent sem all meg)...

Szoval egy kicsit igazan vissza vehetnel az arcocskadbol... LOL... Vernyomas OK? Nem vennem a zuzamra, ha valami bajod lenne a vegen... te kis rfc guru... LOL

Nepszava: az elso celpont a mediatorveny celkeresztjeben

:DDDDD
Nyugi, hála égnek minden rendben van velem:)
Én legalább nem vagyok hülye abban amit csinálok. Viszont ezzel a személyeskedő stílussal pont azt írtad alá, amit kellett, ezt utólagosan is köszönöm:) (az arcocskád is ebben mutatkozott meg).
Ha te azt, hogy kioktattalak pont abban, amit te ezen leírásod szerint zseniálisan művelsz, személyeskedésnek veszel, ez csak a te szegénységi bizonyítványod.
De hogy reagáljak is valamit a butaságaidra:
"hogy nem ertek egyet az smtp rfc-ket kommentalo velemenyeddel (ami egyebkent sem all meg)..."
Még szerencse hogy nem is kell egyetértened, az RFC leírja azt, amit le kell írnia (pont ezért RFC), az hogy nem olvastad és a tévhiteidre alapozol, legyen a te bajod, hála égnek az RFC-k pont nem az emberek objektív gondolkodásmódjára készülnek, hanem pont ellenkezőleg, hogy ne lehessen máshogy érteni:)
"te kis rfc guru..."
Köszi, ez megtisztelő, tény hogy azon protokolok RFC-jét én legalább elolvastam, amikkel kapcsolatba kerültem:)

hogy hiaba gyozkodtuk egymast az egy dolog, de kicsit visszas a te szadbol a szemelyeskedes miatti siras azok utan, amit ezzel a felkegyelmu kapucsino n+1. fikanickkel osszeparadezol. Gondoltam, csak amolyan fyi jelleggel megemlitem a hasonlo a hasonlohoz vonzodik torvenyszeruseget...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

nekem meg mindig nem megy ki:

Jul 20 23:28:56 localhost postfix/smtp[5389]: 21D0CF8157: to=, relay=server27.citromail.hu[91.83.45.27]:25, delay=2, delays=0.04/0/1.9/0.09, dsn=5.1.0, status=bounced (host server27.citromail.hu[91.83.45.27] said: 550 5.1.0 sender rejected. can't find a valid MX for sender domain / Sajnaljuk! Nem beazonosithato valodi MX a kuldo domain-hez! (in reply to MAIL FROM command))

vagy nem egy meccset nezunk?

t

( kirsa74 | 2011. 07. 21., cs – 09:37 )

Az sj-féle spammerek (gy.k.: akik MX rekord nélküli mail címről akarnak leveleket küldeni) kivédéséhez az exim-be ezt az ACL-t kell beilleszteni:

acl_smtp_mail = acl_check_from

acl_check_from:

deny message = Your mail address' domain does not have an MX record
condition = ${if eq{}{${lookup dnsdb{mx=$sender_address_domain}{$value}fail}} {false}}

accept

EDIT: máris kiszűrtem ezzel egy hibásan bekonfigurált klienst

EDIT: és már pattannak is le a spammerek

H=(localhost) [117.0.35.179] rejected MAIL : Your mail address' domain does not have an MX record

tulajdonképp tényleg egész jó tudásbázis ez a hup, csak mindig az ellenkezőjét kell csinálni annak amit a Közösség tagjai javasolnak

még mindig nem vetted észre, hogy nem a citromail szervere a szar, hanem a tied?:)
Jaaa, használjunk fallback-et, elvégre úgy is a hülye rendszergazdák miatt lett bevezetve:)

------------
Szerk: feladom, legyen neked igazad, ne használj MX-et, végülis nem a mail szerverek jelölésére találták ki, meg egyébként is baromság az egész RFC, meg ahogy fennt is írtad, az MX sérti az RFC-t, minek is kellhetne MX egy mail szervernek?

de most hogy jön ide a belsó hálózat könyörgöm? Belső hálózat illetve a DNS hiánya matt, hosts file szempontjából jött az A fallback. Aztán az address literal szintén. Ezzel a szerencsétlen beszólásoddal csak engem igazoltál, hogy ő a hülye, mert nem úgy használja a rendszert (MX rekord hiánya), ahogy kell.

De ennyi sok szerencsétlen balféket mostmár, most érzem elsőnek azt, hogy igazából hülye emberekkel állok le beszélni, illetve mostmár vitázni: olvassátok el azt a szerencsétlen rfc-t, aztán örömködjetek hogy hülyék vagytok. Amint elolvastátok, szoljatok, utánna örömmel leülök bármelyikkel beszélgetni, de addig míg csak baromságokat vagytok képesek szajkózni, ne.

Az a baj, hogy amit mondok, az nem az én véleményem, hanem az RFC-ben van benne, csak képtelenek vagytok feldolgozni ezt a tényt. És egyébként de, az smtp egészen strict módon veszi figyelembe az RFC-t, csupán a szerencsétlen balfék rendszergazdák képtelenek beállítani a szerverüket/domaineket, aztán sírnak, hogy nem bírnak levelet küldeni/fogadni.

Szerk a végére: Átváltok read only módba, rájöttem hogy pár idióta, alapvetően dilettáns és önjelölt informatikussal akik képtelenek utána nézni azoknak a dolgoknak amivel foglalkoznak, nem fogok leállni vitázni.
RFC értelmezés ügyében meg akkor várom őket hasonló észosztásra, mikor leprogramoznak ők is pár TCP/IP stacket, esetleg egy web szervert RFC utánam (de legalábbis utána olvasnak)

RFC értelmezés ügyében meg akkor várom őket hasonló észosztásra, mikor leprogramoznak ők is pár TCP/IP stacket, esetleg egy web szervert RFC utánam (de legalábbis utána olvasnak)

Nem fognak, sot a helyi gyakorlat szellemeben az epelmejuseged is meg fogjak kerdojelezni, nem csak a szakmai hozzaertesed. :)

---
pontscho / fresh!mindworkz

szivem, a legtobb (=rfc-ket koveto) MTA (veled ellentetben) gyonyoruen (=rfc-kompatibilisen) lekezeli a helyzetet. Problemat ez csak neked okoz. Hogy konnyu szivvel lehulyezel masokat (annak ellenere, hogy ostoban ragaszkodsz az MX rekordhoz), meg bele latsz az rfc-irok fejebe, az meg csak a te szintedrol ad extra infot

Nepszava: az elso celpont a mediatorveny celkeresztjeben

( zolo | 2011. 07. 21., cs – 12:31 )

Lehet en is egy barom vagyok, de en nem gondolom, hogy elkene fogadni olyan levelet, aminek a host nevehez nem tartozik MX rekord.
Hasznaljanak olyan hostot a levelkuldok, aminek van MX-e, ellenkezo esetben ne akarjanak levelet kuldeni.

Ennyi erővel általánosítsunk, és mindenki mindenhová vegyen fel SRV rekordokat az SMTP/DNS/POP/IMAP/HTTP/stb. szerverére, annak ellenére, hogy mindegyik ugyanoda mutat.
Mi a logika abban, hogy a bela.example.com-nak van egy bela.example.com. IN MX 10 bela.example.com.-ja, amikor ezt le lehet írni úgy is, hogy bela.example.com. IN A 1.1.1.1?
Kevesebb DNS lookup, egyszerűbben átlátható.

ha nincs MX rekordod, pont hogy tobb dns lookup van (mert az MTA elobb az MX rekordokat kerdezi le, majd megnezi a sulyozast). Ha nem talal MX rekordot, fallback-el es nezi A-t, ami mar nem szabalyszeru, csak lehetoseg van ra

Elvileg nem, mert ha a DNS szerver csomagmérete nem éri el a maximális méretet, az MX-el együtt visszajön az MX nevek mellé tartozó A record is, így:
U 127.0.0.1:42790 -> 127.0.0.1:53
.............indamail.hu.....
U 127.0.0.1:53 -> 127.0.0.1:42790
.............indamail.hu....................mail28.................mail29.................mail30.................mail27...............ns.inventra.......
........ns.index...p..........[S-..+..........[S-..B..........[S-..Y..........[S-.

Igaz, hex nélkűl nem látványos,de a végén azok az [s- részek az ip-k

Nálatok is van ellenőrzés. Ha a subdomainhez nincsen A rekord, nem fogadja el, ugyanúgy Sender address rejected: Domain has no MXes üzenetet kap az ember.
MX rekord mondjuk nem feltétel, de akár lehetne is.

Van ahol sender lookupot is csinálnak, aztán az okos php kóderek hírlevele a www-data@hostnév.hu -val se megy ki. (Mondjuk az vicces, amikor mindkét oldalról megy ezerrel a greylisting ilyenkor :) )

( siposa v | 2011. 07. 21., cs – 15:44 )


[felado@mail ~]$ telnet server28.citromail.hu 25
Trying 91.83.45.28...
Connected to server28.citromail.hu (91.83.45.28).
Escape character is '^]'.
220 server28 mfiltro ESMTP server ready
helo tuzfal-2.felado.hu
250 server28 hello [1.2.3.4], pleased to meet you
mail from: felado@felado.hu
250 2.1.0 <felado@felado.hu> sender ok
rcpt to:fogado.tesz1@citromail.hu
250 2.1.5 Recipient ok
data
354 enter mail, end with "." on a line by itself
Subject: 1

a
s
b
.
250 2.0.0 A23xxxxxxxxxxxxxxxx mail accepted for delivery
quit
------
[felado@mail ~]$ dig felado.hu mx
...
;; ANSWER SECTION:
felado.hu.                8381    IN      MX      10 mail.felado.hu.

[felado@mail ~]$ dig mail.felado.hu mx
;
; nincs
;

[felado@mail ~]$ dig tuzfal-2.felado.hu mx
;
; nincs
;

há' jó ez... 


$ telnet server27.citromail.hu 25
Trying 91.83.45.27...
Connected to server27.citromail.hu.
Escape character is '^]'.
220 server27 mfiltro ESMTP server ready
HELO javaforum.hu
250 server27 hello [193.142.214.109], pleased to meet you
Mail from: auth.gabor @ javakocsma.hu
250 2.1.0 <auth.gabor @ javakocsma.hu> sender ok
Rcpt to: test @ citromail.hu
250 2.1.5 Recipient ok
quit
221 2.0.0 server27 mfiltro closing connection
Connection closed by foreign host.
$ host -t mx javakocsma.hu
javakocsma.hu mail is handled by 10 mail1.javakocsma.hu.
$ host -t a mail1.javakocsma.hu
Host mail1.javakocsma.hu not found: 3(NXDOMAIN)

Ellenpróba? Magyarázat? :)

Ps: Egy óra múlva visszaírom a helyes mx bejegyzést.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Továbbra sem a küldő hostneve számít, hanem a from-nál lévő sender (esetedben az auth.gabor@javakocsma.hu)
~$ host -t mx javakocsma.hu
javakocsma.hu MX 10 mail1.javakocsma.hu

Küldő host lehet akár egy en.egy.domain.vagyok.aminek.nincs.a.rekordja.hu is.

Arról ment a vita, hogy a javakocsma.hu -nak szükséges-e MX rekord, sj szerint nem, mert a sok szarul beállított levelező szerver úgy is fallback-el A-ra ha nincs MX rekord. Citromail ellenőrzi a küldő domain nevét (a javakocsma.hu -t), hogy létezik-e hozzá MX rekord (vagyis hogy helyesen konfigurált SMTP szerver, mely képes levelet fogadni, vélhetően a bounce illetve a spammervagyok flag-ek kiváltása okán.)
Vagyis auth.gabor@javakocsma.hu megy, mert van MX rekordja és vélhetőleg tud leveleket fogadni vs
auth.gabor@mail1.javakocsma.hu ami nem megy, mert nincs MX rekordja és egy bounce levelet sem lehet küldeni neki (leszámítva, hogy fallback miatt jó esélyel kimegy neki a levél).

Ezt írtam körbe szegénynek, hogy RFC szerint, ha egy adott domain szeretne leveleket fogadni, akkor MX rekorddal kell ellátni (mégha az önmagára is mutat).

A küldés más kategória, ott nem kell MX rekord mert nem ők fogadnak levelet (vagyis fogadhatnak, ha a javaforum.hu MX rekordjai között felvannak sorolva, de ez már más tészta teljesen).

Álljon meg a menet... :)

Arról beszélünk, hogy van egy megszorítás, amely szerint kell legyen MX rekord a "mail from" sort tekintve, mert ez jó és RFC compliant ésatöbbi egyéb érv - és persze az indoklásban is kétszer aláhúzzák, hogy azért kell ez, mert így RFC compiant. Közben pedig elfogadnak olyan levelet, ahol ugyan van MX rekord, de annak nincs A rekordja, vagyis nem lehet válaszolni a kapott levélre, a mailer daemon ott fog forgolódni a kezében a válaszlevéllel, mert nem tudja hova tenni. Ez egy tipikus spam küldő üzemmód, fire and forget... szóval el kellene dönteni, hogy spam-et szűrünk vagy spam-elfogadóhelyet üzemeltetünk...

A probléma nem az, hogy kikényszerítenek pár RFC compliant dolgot, hanem az, hogy közben ezer másikat sértenek meg, s rúgnak fel pár megcsontosodott szokásjogot...

Arról ment a vita, hogy a javakocsma.hu -nak szükséges-e MX rekord, sj szerint nem, mert a sok szarul beállított levelező szerver úgy is fallback-el A-ra ha nincs MX rekord.

Ez így igaz. Egyelőre csak a citromail/vipmail/éstársai esetén botlottam bele abba, hogy nekik kell MX rekord... van pár levelezőlistám, éves szinten százezres nagyságrendben kerül ki levél a szerveremről és egyik destination MTA se vette zokon, hogy nincs MX rekordja a lists.javaforum.hu domain-nek (most már van), kivéve a citromail, vipmail &co.

Szóval lehetne több napig értekezni arról, hogy mi RFC compliant és mi nem, ha az RFC compliant működésre szarnak a nagyvilágban.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ööö... izé... tehát összefoglalva: létező MX, nem létező A rekorddal jó, bár használhatatlan; de: létező A rekord nem létező MX rekorddal rossz, bár használható? Abban egyetértünk, hogy ideális esetben van MX rekord, amelynek létezik A rekordja, de a világ sajnos soha nem ideális.

A kérdés továbbra is az, hogy milyen eredményeket várunk egy olyan ellenőrzéstől, amely a legacy alapon működő MTA-t nem engedi be, de hibás DNS láncolatot beenged, noha a Return-Path nem képes levelet fogadni?

Ugyanakkor érdemes hozzátenni, hogy spam-et minimális mértékben szűr: 


Jul 21 20:04:40 mail postfix/smtpd[5404]: connect from 186-26-222-177.dyn.movilnet.com.ve[ 186.26.222.177 ]
Jul 21 20:04:40 mail postfix/smtpd[5404]: < 186-26-222-177.dyn.movilnet.com.ve[ 186.26.222.177 ]: MAIL FROM: < 0-ka @ uk.ibm.com > BODY=7BIT

(zárójelben jegyzem meg, hogy ez nem statisztikai mintavétel, csak az utolsó bejegyzés a mail logban, de például csak ma az uk.ibm.com tucatszor szerepelt a mail from sorban.)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

majdnem jol latod:

- van MX rekord -> jo
- van MX es A rekord is -> jo
- csak A rekord van -> jo, bar nem citromail kompatibilis
- nincs sem A, sem MX rekord -> (spammer vagy, mert spoof-olsz, de) hasznalhato, _ha_ a fogado oldal nem vegez ellenorzest a MAIL FROM-ra

milyen eredményeket várunk egy olyan ellenőrzéstől, amely a legacy alapon működő MTA-t nem engedi be

Kb. olyat, mint a feketelistaktol. Megfognak az RBL-listak egy csomo spamet? Meg hat! Okoznak otromba fals pozitiv hibakat? Az biztos! Kb. ilyet erhetsz el ezzel az RFC-inkompatibilis ellenorzessel...

Ugyanakkor érdemes hozzátenni, hogy spam-et minimális mértékben szűr:

Irtam is fentebb, hogy a spammereknek 'jo' szokasuk spoof-olni, amit csak lehet...

Nepszava: az elso celpont a mediatorveny celkeresztjeben

"Kb. olyat, mint a feketelistaktol. Megfognak az RBL-listak egy csomo spamet? Meg hat! Okoznak otromba fals pozitiv hibakat? Az biztos! Kb. ilyet erhetsz el ezzel az RFC-inkompatibilis ellenorzessel..."
Az a baj, hogy ez még mindig csak szerinted rfc inkompatibilis:)
Érdekes módon, mind a google, mind a yahoo, mind a lófasz képes betartani azt az RFC inkompatibilis szabványt, amit te, mint topiknyitó nem:)
Aztán megmagyarázod hogy igazából nem te, hanem mindenki hülye, még az rfc is, mert ő meg önmagával nem kompatibilis.

tény hogy nem sok mindent szűr, de viszont még mindig jobb mintha semmit se csekkolnánk.

Esetleg ellenőrizhetnének valami mást (is), aminek haszna is van? :)

Értem én, hogy ezzel a módszerrel CPU-t lehet megspórolni, mert nem kell a levél tartalmát feldolgozni, de emellé lesz egy csomó false pozitív szűrés is, ami nagyon nem jó. Persze ez elmegy egy citromail/vipmail/whatever kategóriájú ingyenes levelezőrendszernél, de eléggé érdekes dolog lenne ezt kiterjeszteni a teljes internetre, mert jópár legacy MTA és MUA esne ki a levelezésből, köztük neves cégek is, mert nem tudnának órák alatt változtatni a konfiguráción, vagy esetleg nem is tudnának változtatni architektúrális okból.

Ez a rendszer ahogy nézem, eddig csak olyanokot fogott meg mint sj,

Engem is megfogott, ugyanis egy ideje a lists.javaforum.hu domain alatt futó levelezőlisták fennakadtak a citromail rendszerén, mint potenciális spam, holott 2008 közepétől így üzemelnek a levlistáim és azóta még egy MTA se dobta vissza azért a levelet, mert nem létezett a lists.javaforum.hu domain MX bejegyzése, csak A rekordja volt. Így némileg úgy érzem, hogy a citromail megoldása kissé túl paranoid, s bár spam-et nem fog meg, sikeresen akadályoz más szervereket abban, hogy levelet küldhessenek, így teljesen haszontalan.

mert szerinte nem rfc kompatibilis az smtp szerverekhez mx rekordot használni.

Ez nem egészen igaz, gondolom Te is érzed.

Annyi az egész, hogy nem kötelező az MX rekord egy email cím domain nevéhez... ez tény, nincs értelme ezen vitázni. Egyszerűen MX rekord nélküli feladóhoz is működik a levelezés, próbálhatsz keresni a nagyvilágban olyan forgalmasabb MTA-t, amelyik ezt nem fogadja el, vagy nem tud levelet küldeni ilyen címekre, de nem fogsz nagyon találni. Nem egészséges, nem ideális helyzet, de ez van, a világ jelenleg így működik. S azzal együtt, hogy kreáltam MX rekordot a lists.javaforum.hu domain-hez, azt tanácsoltam az adott listatagnak, hogy inkább keressen másik szolgáltatót, ha szeretne kevesebb spam-et és több legal levelet kapni. Megfogadta.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

+sok...

Esetleg ellenőrizhetnének valami mást (is), aminek haszna is van? :)

mondjuk azt, hogy ervenyes-e a sender domain :-), ill. hogy egyaltalan letezik-e (A es/vagy MX, csak szepen, ahogy az RFC is eloirja...), vagy hogy tuleli-e kliens a egy par masodperces kesleltetest, mielott megkapja 220-as bannert, szelektiv greylisting, nem is beszelve a postscreen-rol, ami brutalis modon hajtja el a zombikat a verbe - FP hiba nelkul! (Ezek mind szinten olcso megoldasok, amelyek smtp szinten csokkentik a spam problemat). Ugye ez lenne a citromail motivacioja is: kiszurni az otthoni dsl/cable/... gepeket, csak hat az elobbi megoldasok ugy aranylanak a citromail solution-hoz, mint a sebeszkes a henteskeshez. Valoban, az utobbival is lehet muteni, csak hat siras lesz a vege...

azt tanácsoltam az adott listatagnak, hogy inkább keressen másik szolgáltatót, ha szeretne kevesebb spam-et és több legal levelet kapni. Megfogadta.

kongrat! :-)

Nepszava: az elso celpont a mediatorveny celkeresztjeben

"mondjuk azt, hogy ervenyes-e a sender domain :-), ill. hogy egyaltalan letezik-e (A es/vagy MX, csak szepen, ahogy az RFC is el"
pont ezt teszi, de még mindig nem a hálózati alapon küldő hostnév MX rekordját (fmx-5.freemail.hu asszem), hanem a freemail.hu -t. Ezen szerintem is és rfc szerint is jogos a check (ha nem nézzük, hogy a fallback lehetséges eset, de a fallback nem azért van, hogy használjuk, hanem mert előfordulhat nagy ritkán, hogy használni kell)

( Darkcomet | 2011. 07. 21., cs – 17:36 )

Én meg napok óta t-emailes haveroknak nem tudok levelet küldeni telefonról, mert mind a telenor, mind a gmail smtp-vel elküldött leveleket spamnek minősíti a szolgáltatójuk.

Szerk: Most nézem gépről, az UPC hálózatból sem mennek át nekik a leveleim.

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

Csak a viták elkerülése végett. Ha nem használok ékezetet, mobiltelefonról írok.

( hzsolt94 v | 2011. 07. 30., szo – 20:42 )

Szerk: Mcsiv-nek ment volna, mellément.

Te tényleg hülye vagy.

A host képes fogadni leveleket, méghozzá RFC szerint is! Azt hogy ezt fallback módszerrel teszi az egy dolog, de neki szíve joga fallbacket használni mert neki meg van engedve, mindegy hogy miért.

Ha te ennek ellenére nem fogadod a levelét, amikor biztosított a válaszlevél lehetősége (!!!) akkor azzal te követsz el RFC sértést!

De nem ismétlem el mások helyett, neked is szíved joga hülyének lenni. Nem sokáig alkalmaználak rendszergazdának ilyen hozzáállással.

Édes drága hzsolt94!

A host képes fogadni leveleket, igen, RFC szerint is, mert ez a dolga.

Az RFC kifejti, hogy MINDEN szervernek kötelező az MX rekord használata, nincs kivétel leírva (vagyis de, küldésre nem kötelező az MX rekord, de mivel sender domain-ről volt szó és nem a küldő hostról, neki a postmaster levelezés miatt kötelező).
Az A rekord fallback okait már fentebb boncolgattuk, vagyis ha egy szerver eldobja azt a küldő domaint, aminek nincs MX rekordja (mert RFC szerint mindnek kell lennie), az az egyéni dolga és nem RFC sértés.
Az hogy ha nincs MX rekordod és működik az A fallback van, az nem helyes működés, pont ezért fallback. Gondolkodj drága barátom, mit is jelenthet a fallback kifejezés?

Hála égnek nem is kell rendszergazdaként alkalmaznod, nem is mennék ilyen dilettánshoz, aki egy két elolvasott mondat után képes visszaböfögni pár elemet, aminek igazából semmi alapja sincs. A fallback szó az valami misztikus kijelentés.

Visszatérve erre, valószínűleg a citromail, bix, index, origo, a hotmail, a microsoft.com rendszergazdái is mind mind hülye barmok szerinted, mert elmerik dobni a normális rekordokkal nem rendelkező domaineket.

Most akkor ha minden szervernek kötelező akkor minek írja a fallback-et?
Hogyha pedig én szigorúan veszem hogy az MX kötelező, akkor sértem azt a részt hogy a fallback alkalmazandó.

Az nem kérdés, hogyha nekem van saját levelező szerverem akkor az MX-et be kell (illik) állítanom. De másoktól miért is kellene megkövetelnem ezt?
Sőt, milyen alapon "kötelezek" erre másokat akik nekem levelet akarnak írni?

Értem én hogy SPAM elleni kűzdelem meg minden, de én még nem láttam olyan spam-et amit a kispista@otthiniszerver feladóval küldtek. Olyat viszont rengeteget amit @léteződomain.hu-nak hamisítottak.

Inkább az SPF rekordok beállítgatásával és ellenőrzésével kellene foglalkozni.

> Most akkor ha minden szervernek kötelező akkor minek írja a fallback-et?
> Hogyha pedig én szigorúan veszem hogy az MX kötelező, akkor sértem azt a részt hogy a fallback alkalmazandó.

neharagudj, mi a szakmád, illetve milyen munkakörben vagy jelenleg alkalmazva?

> Értem én hogy SPAM elleni kűzdelem meg minden, de én még nem láttam olyan spam-et amit a kispista@otthiniszerver feladóval küldtek.

tehát vízvezeték-szerelő?

"Inkább az SPF rekordok beállítgatásával és ellenőrzésével kellene foglalkozni."
Aztán aki SPF rekord nélkül bassza ki a levelet, ő a balfasz.

"Az nem kérdés, hogyha nekem van saját levelező szerverem akkor az MX-et be kell (illik) állítanom. De másoktól miért is kellene megkövetelnem ezt?"
Nem te követeled, az RFC követeli meg.

"Most akkor ha minden szervernek kötelező akkor minek írja a fallback-et?"
A fallback használata a 90 évekre tehető, mikor eltörölték a régi rekordokat (igen, akkor még nem MX volt, hanem más) a levelezésre.
Mivel az átmozdulás az egyik oldalról a másikra olyan lassú volt mint most az ipv6 fele mozgás, bekerült az "A record fallback" (pont ezért fallback a neve). Ezen okok miatt a kiszolgáló daemon-ok technikai oldalról átálltak MX-re, viszont hogy a régi rendszerrel kompatibilis maradjon, bejött az A fallback. Ugyan ezen okok miatt van az, hogy default beállítás az, hogy A recordra fallbackel ha nincs MX, de ez nem kötelező, sőt...

Vagyis az, hogy MX-et checkol valaki a sender domainen, az teljesen rendben van, mivel az RFC szabvány előírja az MX rekordok meglétét (mivel attol fogadó domain egy domain, hogy van MX rekordja). Az hogy az A fallback még működik, annak történelmi okai vannak.

A küldő hostnak nem kötelező MX, mert az csak kézbesítő szerepet játszik a folyamatban.

Ha egy domainnek nincs SPF rekordja akkor nincs mit tenni, ettől még az ő levele lehet érvényes.
Ha van, akkor viszont szigorúan kell venni, és csak onnan elfogadni levelet ahonnan ő is engedi.
Szóval állítsanak be minél többen SPF-et! Remélhetőleg egyszer kötelező is lesz...

Ha ezt az RFC így írja le, akkor korrekt az ilyen fajta szűrés. De ez azt jelenti hogy az A rekord fallback lényegében már "tilos".

igen, ok is ellenorzik az mx-et, de pl. a hotmail.com es a freemail.hu (ha van korrekt A rekordja a mail from domainnevnek, akkor) elfogadjak a topiknyitoban emlitett levelet. Csak azert merem allitani, mert konkretan kiprobaltam.

Szoval azert kellene egy kicsit ovatosabbra venni a fud-olast, mert a jelek szerint, a nagyobb szereplok (plusz akiket korabban irtam, pl. gmail es yahoo) - akik biztos hulyek - (pusztan) egy failed mx check alapjan NEM DOBJAK EL a levelet.

Akiket te hoztal (korabban is) peldakent, pl. index/citromail vagy az externet (uhhh, alig latok ki mogule, akkora piaci szereplo) aligha mervado jatekosok, legalabbis olyan modon nem, ahogyan azt te probalod meg beallitani, ti. az Internet nagyobbik resze.

A te csusztatasoddal ellentetben a valosag tehat az, hogy a citromail/index/externet/gabuccsino/... szurest csak egy marginalis csoport vegez.

Viktor az eletrol es a halalrol

felreertesz: a meret vagy a tamogatok aranya egyaltalan nem befolyasolja az igazsagot. Hanem arra akartam kihegyezni a dolgot, hogy - allitasoddal ellentetben - az Interneten "a nagyok" nem ugy szurnek, mint ez a par marginalis szereplo, szoval az utobbiak alapjan nem fair ugy beallitani a dolgot, hogy szinte mindenki ugy csinalja, mint az utobbiak.

Az en szolgaltatasom ide keverni haszontalan mellekszal, de ha erdekel, akkor elmondom, en (=postfix) sem dobom el a vitatott problema miatt a leveleket...

Viktor az eletrol es a halalrol

> felreertesz: a meret vagy a tamogatok aranya egyaltalan nem befolyasolja az igazsagot.

ezegyszer jól mondod sj mester (értsd: fogalmad sincs milyen mondatokat alkotsz), nem számít, hogy a gmail bugos, attól még nem lesz követkendő példa az MX rekord létének ignorálása

Elbeszéltek egymás mellett.

Azzal mindenki egyet ért hogy ha van mail szervered, akkor állítsd be az MX-et!

Arról vitáztok hogy a be nem állított MX-el rendelkező szerverektől el kell-e fogadni a levelet: És a válasz az hogy _sajnos_ igen mert amíg a fallback-et valamelyik RFC meg nem tiltja (valószínűleg ilyen nem lesz soha) addig bizony annak is működnie kellene.

Szóval ez a nem veszünk el MX nélküli (de A-val rendelkező) szervertől eléggé "Szarok a világra" hozzáállás. Olyan mint ha a határon az egyik vámos nem engedne ki kék útlevéllel, mert az új már piros... (pedig még sajnos a kék is érvényes)

Az A rekord fallback okait már fentebb boncolgattuk, vagyis ha egy szerver eldobja azt a küldő domaint, aminek nincs MX rekordja (mert RFC szerint mindnek kell lennie), az az egyéni dolga és nem RFC sértés. Az hogy ha nincs MX rekordod és működik az A fallback van, az nem helyes működés, pont ezért fallback. Gondolkodj drága barátom, mit is jelenthet a fallback kifejezés?

Nincs szó fallback-ről, legalábbis az RFC 5321 egészen pontosan megmondja, hogy miképp kell kezelni az MX rekordot, a kedvedért kiemeltem a releváns részletet:
The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as
if it were the initial name. If a non-existent domain error is
returned, this situation MUST be reported as an error. If a
temporary error is returned, the message MUST be queued and retried
later (see Section 4.5.4.1). If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host. If MX records are
present, but none of them are usable, or the implicit MX is unusable,
this situation MUST be reported as an error.

Két kérdés az RFC 5321 hivatkozott részével kapcsolatban:
- benne van-e, hogy MX rekord hiányában egészen pontosan mit kell tennie az SMTP szervernek?
- benne van-e, hogy MX rekord hiányában úgy kell-e tekintenie a host nevét, mint egy MX rekordot?

Kérlek válaszold meg értelmezésed szerint ezt a két eldöntendő kérdést.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ez a névfeloldás menete, amiben értelemszerűen ez is benne van. Azt olvasd már el, miért van benne! Jaa, hogy az előző kb 6 rfc-t nem olvastad? sebaj, akkor ragadj ki egy későbbiből még két mondatot.
De feladom mostmár, a topicot is eltüntetem magam elől, mert nem bírom ezt a "jajj, rákerestem a google-ben, és nem úgy van!" dolgot. Annyi idő alatt, mióta megy a sírás, 6x átolvashattátok volna az ide vonatkozó rfc -ket.

Bocsánatot kívánok, de azon lovagolsz, hogy az MX rekord kötelező, amikor nem az, és hivatkozol a 90-es évek közepére, pedig a fenti RFC 2-3 éves. Ráadásul azért az 5321-ből idézek, mert jelenleg ez az IT szakma összegzett véleménye az SMTP protokoll működéséről, és ez elavultá teszi az _összes_ előző SMTP-vel kapcsolatos RFC-t, tehát azokra felesleges hivatkozni - ezt gondolom elolvastad az 5321 fejlécében.

Az MX rekord nélküli rész pedig azért van benne, mert 'de facto' így alakult, ezért belevették a legújabb szabályrendszerbe, ettől kezdve viszont 'de jure' is legális dolog. Nem tudom észrevetted-e, de az RFC általában utólagosan foglal szabályrendszerbe egy már szokássá vált protokollt vagy protokoll változtatást, nem pedig megalkot egy nem létező protokollt, amelyet aztán elterjesztenek... pont ilyen az MX rekord hiánya is. Érdemes lenne megbarátkozni ezzel a helyzettel, amíg nem késő.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Tudom én nagyon jól, hogy miért... olyan vagy, mint a viccbeli öregasszony, aki betelefonál a rendőrségre:
- Azonnal jöjjenek ki! A szemben lévő ház kertjében egy fiatal pár naphosszat sérti a szemérmet! Meztelenül flangálnak!
A rendőrök helyszíni szemlét tartanak, majd azt mondja az egyikük:
- Asszonyom, az égvilágon semmit sem lehet látni!
- Hát persze, mert rosszul nézik! De húzza csak ide az asztalt az ablakhoz, tegyen rá egy széket, és ha föláll rá, oldalt azon a kis résen át mindent láthat.

jó lenne ha nem emlegetnéd a szakmát aminek a hullájára vizelsz épp, kajánul vigyorogva

két szemléletmód van itt, az enyém ez:

- mailszervernek legyen MX rekordja
- ha nincs, fogyatékos hupper konfigolta -> deny, legalább ebből is tanul (úgyse...)
- kevesebb spam -> works! (csak ezzel, csak ma 17 gép lett filtered)

titeket debianos powerlusereket (problem, openssl?) meg ezek a szempontok mozgatnak:

- á minek mx rekord, fasság, e'fogadok én mindent, dikk
- <3 <3 <3 szeretek minden szervert, minek holmi kötöttségeket betartatni másokkal, naésha nem ért hozzá az admin, nagy ügy..! <3 <3 <3
- ettől úgyse lesz kevesebb spam, mert úgyis megtanulják majd kivédeni bla-bla-bla, egyéb nonfiguratív irreális marhaságok hangoztatása ;-((((((
- nem merem átírni a drupálforrásban a kommentszámot

sajnos mai világunkban nem jár semmiféle közvetlen retorzióval az autista debuntusok által előszeretettel alkalmazott második szemlélet, nemúgy mint anno a fidonet-en, ahol ha 2 byte-al eltért a deviáns user a rendszertől, máris összevont szemöldökök tucatjai scrolloztak be a képbe.

Nem egészen érted a 2. szemléletmódot:

- mailszervernek legyen MX rekordja
- de ha nincs (sajnos!) akkor azt is el kell fogadni, mert van rá az RFC-ben fallback (és igen fallback, de attól még meg van engedve és kész!)
- spam szűrésnek nem jó, mert túl sok a fals pozitív hiba (Sajnos mindenki szabadon lehet hülye...)

A "helyes" eljárás az lenne, hogy ellenőrzöm a küldő domainnek van-e MX _vagy_ A rekordja.

(Esetleg ha a "béna huppert" akarod boldogítani a webmaster/postmaster@küldődomain kaphatna figyelmeztetést ha nincs MX)

Spamek ellen szerintem akkor is az SPF való: Ha a általában nem is, de a küldő hamisítása ellen védene.

Egyébként ha csak a viagra szóra szűrsz, már akkor kidobtad a spamek kétharmadát :D

> Nem egészen érted

de

> túl sok a fals pozitív hiba

erre vonatkozólag nyilvánvalóan csak én rendelkezek gyakorlati tapasztalattal (kényelmesen lesöpörve), általános iskolás hupperek nem

> A "helyes" eljárás az lenne

igen, az ún. Fogyatékos-metódusban

> (Esetleg ha a "béna huppert" akarod boldogítani a webmaster/postmaster@küldődomain kaphatna figyelmeztetést ha nincs MX)

neked ez a spam téma nagyon nem megy

> szerintem akkoriiiis

ok, majd következő uzsonnaszünetben megint ülj be a kompjúter elé és folytassuk

Ha téged az sem zavar hogy a Google, Freemail, T-online, Hotmail és a(z általam ismert) internet legnagyobbik része így tesz, akkor nem tudok több érvet felhozni.

Ha neked így megfelel, használd így. Kíváncsi leszek lesz-e ebből _neked_ problémád, vagy csak másoknak.

Én továbbra is mindenkinek azt javaslom hogy ne használjon citromailt. és valahogy érdekes módon meg szokták fogadni.

Aki meg szervert állít be annak azt hogy állítson be MX rekordot, de ne csak MX rekordos címről vegyen át levelet.

kevéssé érdekel az amerikai hírszerzés netes fedőcége, még kevésbé néhány láma freemail provider

> nem tudok több érvet felhozni

ennyivel eleve beszállni is kár volt

> Kíváncsi leszek lesz-e ebből _neked_ problémád

írtam: nincs

> Én továbbra is mindenkinek azt javaslom hogy ne használjon citromailt.

nyugodtan terjeszd a marhaságaid az osztályban

Most ezzel sokat lehet még vagdalkozni hogy hány éves vagyok. Szerintem tökmind1. Egyébként meg pont az átlag felhasználókat bukod el azzal ha nem kapja meg az ilyen-olyan félig-spam kutya/macska neveldés játékának leveleit.

A google-re meg elég húzós azt mondani hogy nem érdekel, mikor gyakorlatilag az egyik legdominánsabb szereplő a magyar neten.
Nem lehet mindig parancsolni, együtt kell működni azzal ami van. Akkor is ha szar... Ez a csakazértsem hozzáállás nem igazán vezet sehová.

De tekintve hogy ez közöttünk már elvi vita, és rég nem a levelezésről szól kár folytatni:

Szerintem az számít hogy kompatibilis legyen, biztosan együttműködjön mindennel,
szerinted pedig az, hogy csak alaposan felügyelt / karbantartott rendszerből érkezzen levél.

Ez elvi kérdés, és nem technikai.

Az pedig megint egy másik érdekes kérdés hogy hány olyan spam-et fogsz meg ezzel amit más szűrés nem fog meg.
Szerintem pl ha első próbálkozásra átmeneti hibát adsz vissza, és csak 2.-ra engeded be a levelet, akkor (majdnem) minden olyan spam-et megfogsz, amit az előbbi szűrésed megfogna, így ez a drasztikus szigorúság az MX rekordhoz szükségtelen lehetne.

Egy párszor még elmondhatom neked hogy én eddig is beállítottam MX-ez (azon az egy szál domainen amihez egyáltalán nyúlok) sőt SPF-et is.
Nem azt mondtam hogy ne állíts be MX-et, hanem azt hogy ne követeld meg ezt másoktól.

Én is ajánlom mindenkinek hogy állítson be MX rekordot, de nem követelem meg senkitől. :)

A citromailnek meg úgyis mindegy, nem (csaK) ettől lesz szar... Szóval nem kár érte.

A Te szemléletmódod tökéletes akkor, amikor semmi anyagi hátrány nem származik a false positive szűrésekből, de sajnos a világ nagyobb része ezt nem mondhatja el magáról, így a szemléletmódod fabatkát sem ér.

A retorziókkal meg az a helyzet, hogy az RFC-t éppenhogy ezzel a szűréssel sérted, de persze erős a hited, nem ingat meg meg pár olyan apróság, mint ami az RFC-ben leírva van... de kérlek, mutass már élő vagy bevezetés alatt lévő RFC-t, amelyben le van írva, hogy kell MX rekord. Mert ebben a témában egyelőre egyedül én idéztem RFC-ből egy egész blokkot, ami ellentmond az elméletednek, ezen túl csak azt olvastam, hogy az RFC szerint kötelező az MX, de egyik ilyen kijelentés mögött sem volt hivatkozás a pontos RFC szövegre.

Szóval amíg nem keresed meg hatályos RFC-ben, hogy kötelező az MX, addig az látszik, hogy a szemléletmódoddal csatlakoztál a világ azon részéhez, akiken - saját magad szerint - az RFC sértés miatt közvetlen retorziót kellene alkalmazni, vagyis egyelőre saját magad szeretnéd büntetni...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> semmi anyagi hátrány nem származik

nem igazán lep meg hogy te ezt is jobban tudod

> a világ nagyobb része

talán kiderülhetett már, hogy kevéssé izgatnak fel a kikapcsolt openssl-el netező debianos szakemberek tízezrei

> egyedül én idéztem RFC-ből egy egész blokkot

többször meg is lett már dicsérve a google search fu-d, sajnos azon a szinten meg is rekedtél

> csatlakoztál a világ azon részéhez

levágtam a remek kis értelmezésed, lényegében viszont annak örülök, hogy nem abban a felében vagyok amelyikben te

"nem igazán lep meg hogy te ezt is jobban tudod"

Ahm... kb. mennyi bevételed származik email-ben érkező megrendelések útján?

"talán kiderülhetett már, hogy kevéssé izgatnak fel a kikapcsolt openssl-el netező debianos szakemberek tízezrei"

Hidegen hagy, hogy milyen fóbiáid vannak az openssl és a debian metszetét tekintve, irreleváns az SMTP protokoll működésével kapcsolatban.

"többször meg is lett már dicsérve a google search fu-d, sajnos azon a szinten meg is rekedtél"

Tehát nem tudsz RFC részletet közölni arról, hogy kötelező az MX rekord?

"levágtam a remek kis értelmezésed, lényegében viszont annak örülök, hogy nem abban a felében vagyok amelyikben te"

Eléggé hülyén veszi ki magát, amikor a szakmai döntéseidet emóciók alapján hozod, de úgy néz ki, hogy nálad ez üzemszerű működésnek tekinthető...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Ahm... kb. mennyi bevételed származik email-ben érkező megrendelések útján?

ez kb annyira releváns számodra, mint hogy a linuxod mellé van-e szifiliszed vagy más betegséged

> Hidegen hagy, hogy milyen fóbiáid vannak az openssl és a debian metszetét tekintve

oups egy gyors, ideges terelési kísérlet a senkit nem érdeklő "többség" témájáról

> Tehát nem tudsz RFC részletet közölni arról, hogy kötelező az MX rekord?

mivel az előző 8 ilyen paste-t se tudtad elolvasni/értelmezni, így nyilván nem

> Eléggé hülyén veszi ki magát, amikor a szakmai döntéseidet emóciók alapján hozod

ez mondjuk picinyt merész kijelentés tőled, aki a rég bebukott manyup fud-ot tolja ahol csak lehet, mellesleg illusztrációként meg odaírja hogy "te mondd hogy rablótámadás, a te hangod mélyebb"

Szóval továbbra se tudsz RFC részletet mutatni, ami szakmailag alátámasztotta volna a döntésedet, helyette terelsz és személyeskedsz, ráadásul be is bizonyítod, hogy emóciók alapján hozol szakmai döntést. Sajnállak kicsit, hogy ennyire nem tudod különválasztani a szakmai dolgokat a magánéletedtől:

aki a rég bebukott manyup fud-ot tolja ahol csak lehet, mellesleg illusztrációként meg odaírja hogy "te mondd hogy rablótámadás, a te hangod mélyebb"

Ha én kijelentem, hogy oxigént lélegzek be, akkor Te mostantól rászoksz a tiszta nitrogénre? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Szövegértési problémáid vannak.

A vita nem arról szól, hogy legyen-e vagy ne legyen, hanem arról, hogy az RFC kötelezően előírja-e vagy sem. Egyelőre eddig csak olyan RFC-t sikerült találni, amely nem írja kötelezőnek az MX rekordot, sőt külön mondatban rendelkezik arról, hogy mit kell tenni MX rekord hiányában.

Az emóció ott jön képbe, hogy ezen tények ellenére fenntartod azon véleményedet, hogy az MX rekord kötelező, s mindezt pusztán azért teszed, mert két olyan ember idézett az RFC-ből, aki más politikai platformon áll, mint Te. Ráadásul eddig felvonultattad a teljes troll fegyvertáradat a sértegetéstől kezdve a személyeskedésen át a terelésig, ellenben egy árva szakmai érveket sem tudtál írni.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> Szövegértési problémáid vannak.
> Az emóció ott jön képbe, hogy ezen tények ellenére fenntartod azon véleményedet, hogy az MX rekord kötelező

a tekintetben hogy kinek vannak szövegértési problémái, hamarosan elég szarul fogod érezni magad, amint megpróbálod megkeresni hol írtam ezt

Mutass kérlek egy RFC bekezdést, ahol arról írnak, hogy az MX kötelező, én hoztam ellenpéldát, de lesöpörted érvek nélkül azzal, hogy az általam idézett bekezdés nem arról szól, ami célból oda írták, nyilván ezért van az 'Address Resolution and Mail Handling' szekcióban...

Szóval kérnék tőled egy RFC linket vagy ide másolt részletet, ahol az MX kötelező voltáról írnak.

Ps.: Nem értem, hogy fogalmazásban és retorikában miért ereszkedsz le 'kirsa74 és társai' szintjére, de ha ilyen stílusban érzed jól magad, az már önmagában sajnálatra méltó.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Kértem tőled egy darab hivatkozást, mi lenne, ha ködösítés és terelés helyett pontosan rámutatnál azon RFC azon pontjára, ahol leírták az MX rekord kötelező voltát. Nincs se fentebb, se lentebb kifejtve a dolog, RFC-ből pedig eddig csak én idéztem, amely idézet viszont nem igazolja az MX rekord kötelező voltát, sőt 'de jure' állapotba helyezi 'de facto' állapotból az MX rekord opcionális voltát.

Szóval?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Szoval az van, hogy nem 2 admin levelezik egymassal, es az egyik bena, a masik meg eldobja a levelet, hanem a valosag az (probalj meg egy kicsit nagyobb dimenziokban gondolkozni, mint az externet 2000 hosztolt email cime), hogy van 2 admin, es az egyik gepen levo uzleti felhasznalok levelet akarnak kuldeni a masik gepen levoknek. A benasagod pedig azert fals pozitiv hiba, mert az utobbiak amugy akarjak is ezeket a leveleket.

Ezert hat nem az az admin a bena, amelyikre onkenyesen rafogjuk, hanem az, amelyik a celt (=ne allj az uzleti levelezes utjaba) totalisan nem ertve _legitim_ leveleket dobal el. Ezert irtam, hogy senkinek nem faj az, ha pl. a gyiktestu kapucsino baratunk tetszoleges smtp ellenorzeseket vet be, mert vele max. a mailer daemon levelezik. De pl. a yahoo, gmail, hotmail, freemail, t-online, meg ugy az Internet nagyobb resze - veled ellentetben - kicsit jobban aggodik az esetleges fals pozitivok miatt, es ezert egy picit tobb figyelmet fordit arra, hogy a mukodese lehetoleg rfc-kompatibilis es alacsony fp-aranyu legyen...

Viktor az eletrol es a halalrol

Ha az uzleti felhasznalok olyan helyre mennek,

Ez elegge eretlen es felelotlen hozzaallas, de termeszetesen szived joga tetszoleges modon megoldani a spamszurest. Ahogyan a regi Kinaban az orvosok "fals pozitiv" hibait egy-egy lampaval jeleztek, ugy a te mail szervered (ha egyaltalan ilyen kozelebe engednek) szebben vilagit, mint egy karacsonyfa... :-)

Viktor az eletrol es a halalrol

( sj | 2011. 07. 30., szo – 21:58 )

megtalaltam John Klensin (egyik) email cimet, es - csak a poen kedveert - leirtam neki a topik osszefoglalojat az rfc koruli vitarol, es kertem, mondja meg, hogy jol latom-e az ugyet? Ha valaszol, akkor megosztom itt is, barmi legyen is az eredmeny...

Deutsch: Ki a fasz az a Thomas Melia?

:-) Valaszt (meg) nem kaptam, de gyanitom, hogy mar nem is fogok, azonban az elkuldott levelet nyilvanosan is vallalni merem (az esetleges grammar issue-kkal egyutt), ime:

**********************************************************************************
Dear Mr Klensin,

I've read RFC5321 you have written, and I need your help to some clarification.

There's a free email provider (@citromail.hu) that uses an unusual smtp level check
againt spammers: it checks whether the domainname part of the email has a valid MX
record or not, and if not, it rejects the smtp session even if the domainname has a
valid A record.

There's a debate whether this check is RFC compliant or not, and I thought I would ask
your opinion about the matter since it's your RFC :-)

According to RFC 5321 (http://tools.ietf.org/html/rfc5321) 5.1 section (Locating the
target host):

The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as
if it were the initial name. If a non-existent domain error is
returned, this situation MUST be reported as an error. If a
temporary error is returned, the message MUST be queued and retried
later (see Section 4.5.4.1). If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host. If MX records are
present, but none of them are usable, or the implicit MX is unusable,
this situation MUST be reported as an error.

Let's say I want to send an email and provide apache @ lithium.aaa.fu in
the MAIL FROM stage. The host 'lithium.aaa.fu' has no MX record, but has
a valid A record.

The paragraph above tells me that it's perfectly fine, and the receiving smtp
should not reject the smtp session because of the absense of the MX record.

So I would like to hear you opinion about the matter whether I am right or wrong.

Thank you in advance,
xxxxx

**********************************************************************************

Viktor az eletrol es a halalrol

( kirsa74 | 2011. 08. 12., p – 16:48 )

lazán kapcsolódik: sj nyominger oldala (homepage a'la 1997, igénytelenül tömörített jpeg, hányadék font, és még rengeteg apró remek)

Nincs olyan oldal amiben ne lehetne hibát találni.. ez alól még a http://www.gabucino.be/ se kivétel:
- homepage a'la 1997: gány oldal elrendezés
- homepage a'la 1997: 680px használata 2011-ben
- és még rengeteg apró remek..
.. van css fájl mégis gányol: .. span style="font-size:13px;"..
.. lukra futott kérés: http://www2.clustrmaps.com/counter/index2.php?url=http://www.gabucino.be
.. Elgurult gyógyszer, a'la "különböző" DOCTYPE-k használata oldalanként:
- és még további rengeteg apró remek, amiket hely és idő hiányában nem sorolok..

Amiben igazad volt az a igénytelenül tömörített jpeg, a többi rezegteti a lécet..

> trey az oka, ... hibanak szamit.

sajnos sem a clustrmaps-re, se trey önkritikájának hiányára nincs befolyásom, továbbá úgy tűnik az "off-site link" fogalmának az elmétekben történő rögzítésére sem

> mikor lesz a hupmeme-en RSS feed? Ok, tudom, hogy nem vagy egy PHP tudor

majd még kicsit rágyúrsz pár évig erre a web témára, és "php pistike" rangodból talán kinőve rájössz, hogy ehhez php se kell (subtle hint: most is van rss, és nincs php)

Arról valóban nem tehetsz, hogy épp nem megy a clustrmaps, arról viszont, hogy a farkad 25 mikronját a clustrmaps-al és boincstats-al próbálod kompenzálni.:)
Áruld el, mennyid dob hozzá?:) Meg tudsz már dugni vele.. hogy családodban maradjon.. mondjuk egy csótányt?:)

Az sem állja meg a helyét Webb Elek, hogy "view source" gomb kellett a bénázásaid megtalálásához, mert ha valaki kicsit ért a webhez, az sugárban hány az oldaladtól, ami nem jó
mert nem környezetbarát: sok tisztítószer kell a monitorok lesikálásához, pontosabban gabucino mentesítéséhez.:)
Kár, hogy nincs kint a postacímed, mert akkor ha téglát nem is, de hányadék gyűjtést rendezhetnél.:)

Szóval.. nem a tartalma miatt hánynak, mint emlékszel: sugárban, mert az jó.. mármint a hányás.:).. na és kivéve, hogy egy k*cs*g g*c* vagy, hogy engem nem vettél fel a listára.:)..
hanem, mert akárcsak a hup és a csúcs (magyar) oldalak többsége nem ismeri a div-ék overflow tulajdonságát, így azoknak a szerencsétlenek, akik szórakozni járnak az említett és nem említett oldalakra,
előbb cirka fél-egy órát kell letekergetnie az oldalak aljára, majd vissza, ha másra is kíváncsiak.. és itt jön az összeesküvés elmélet.. nem lehet, hogy Mr. Gabucino és Mr. Trey egy kocsmában sörözik és röhög a jó?népen?:) Vagy csak a sötét anyag/energia miatt van ez az egyezés?:))

Valószínű, csak az utóbbi, mert gabucino.be kilóg a sorból, mert taknyolója alias "2006-2011 Gábor Bérczi site@berczi.be, amely e-mail cím végéről pár birka "e" lemaradt.. ötlet: akkora barmoknak.. bocs! birkáknak mint Gabu, kell egy .beee tartomány.:).. szóval ezen nagy?tudású webszagértő nem átallotta oldalát 680px szélesre fixálni.. ami sok kérdést vet fel: kezdjünk neki a hányás mellé pénzt gyűjteni rendes monitorra.. vagy inkább mégis téglára, amivel legalább falat húzhat és verheti bele a fejét, kántálva: Idióta vagyok?:))
Napalmmal megspékelve, hogy kis szakmai szagot is vigyünk bele: egy tüzes falat?:)

Szóval a reggeli kávé mellett gondolkozz el azon, hogy miért is kellett a "view source" gomb, hogy megtaláljam pár nagy bénázásod?:)
Persze nem ártana azon sem elgondolkoznod, hogy miért is születtél meg, és, hogy érdemesnek érzed-e még magad, ezek után, hogy egy levegőt szívj más környezettudatos (hányás>tisztítás) emberi lénnyel.:)
Egyébiránt gondold át még egyszer, ha válaszolni akarnál, mert fájna, ha szokásos kis piti formád hoznád és elintéznéd egy tőmondattal ezt a kis esszémet.. úgyis mondhatnám lépj túl magadon.. hisz ismered a mondás: Csótány küzdj és bízva bízzál, futkározz hogy el ne hízzál.:)

Csak ennyi?:)
Mi van birka, ennyit bírsz, ilyen könnyen feladod?:)
Szedd már össze magad, siralmas.. régen még tudtál valamit.. már csak ennyire futja?:)
Ezt is meg kellett érni, Gabu behúzza fülét farkát és annyiban hagyja a dolgot.. pedig most kezdenék belejönni.:)
Figyú mielőtt elsírnád magad, vagy kardodba dőlnél, ha gondolod szívesen adok továbbképzést web fejvesztés témakörében.. hátha túl tudsz lépni egyszer csak a 680 pixelen.:)
Ne feledd: a 680 felett is van élet.:)

Ja, bocs!
Elfelejtettem, hogy lehet Gabu egy másik nickje vagy..:)
A kínos az, amit te csinálsz.. többre nem futja tényleg?:))
Már majd megijedtem, hogy rajongója (vagy nője) akadt ennek a kis csótánynak.. de most megnyugodtam.. kérlek ne hagyd abba: még!, még!:)
Van még valaki?:)

Nyugi van!
Köszönöm az aggódásod, de nem kell félteni.. még csak most kezdek felébredni.. ellenben veled, a híres troll bajnokkal.
Úgy látszik tényleg csak egy-két tőmondatra futja tőled.. ebben merül ki és le az összes tudományod.. érdekes pszichológia eset vagy.. elemezzük csak..
Csinálsz egy ótvaros weboldalt és fikázod rajta a népet.. miért is?
Vajon tényleg a kispöcs defektus jön a képbe, vagy valaki kicsiny szaros szakmai lelkedbe gázolt valamikor, talán egy messzi messzi galaxisban és így próbálod kompenzálni?:))
Elárulhatnád így négyszemközt.. de komolyan, szívesen beáldozna szerintem itt a többség pár 100-as pzs-t, hogy megtudja miért ez a személyiség zavar nálad.. esetleg még hányás helyett.. hogy megint az összedobás szokatlanul magas eszméjét vessem fel, összedobunk neked egy dns vizsgálatot is.. hátha valami mutáns vagy..:)
Bocs: ehhez igazából nem kell dns vizsgálat, ezt mindenki tudja rólad.. a kérdés, hogy melyik fajba tartozol igazából.. ki asszimilált.. a csótányokon kívül.:)
Szóval az esszém.. kösz a kedves szóért.. nagylelkű vagy, hogy te is így jellemezted szerény művemet.. szóval mint látod, eposzi magasságtól még messze van, de a te tőmondataidtól fényévnyi távolságra.. na de komolyan! miért nem veszel már fel a lapodra.. ne lény már ilyen kicsinyes kis trutyi, hogy csak egy bekezdést szántál nekem.. "A fekália maga a HUP és trey személye (© esc)".. elkalandoztam.. ismét.. szóval az eszencia ütött!:) Tényleg komoly bók ez egy univerzális Troll-mestertől.. az élet és Gabu eszenciája volt az esszém mi?:)
Wazze.. érzitek, hogy Gabu bókol?:)
Vagy ez már nem is Gabu, hanem egy lepkefing, aki ki szeretné már sírni valakinek a vállán magát?:))
Ne fojtsd vissza.. de legyél már férfi, mert most inkább tűnsz sírós kis ribancnak, akinek elvették a játékát..

( tibyke | 2011. 08. 12., p – 20:12 )

vajon ki unja meg elobb? biztos nem gabu.

t

Nem, de nem is érdekel. Gondolod, hogy valóban foglalkoztat? Csak benéztem ebbe a topikba, azt hittem egy kicsit elszórakoztatom magam, de rájöttem, hogy kirsa74-nél még a Film+-on menő Terminator 3 is szórakoztatóbb így 724. megtekintésre is. Kiégett troll már régen nem szórakoztató.

--
trey @ gépház

Ne edd magad, nem a te hibád. Az elmúlt években már annyi válogatott faszságot kaptam, hogy nem tudsz már újat mondani. A régi baromságok ismétlésével meg úgy vagyok, hogy nem üti már meg nagyon az ingerküszöböm. Unalmasak, na. Mit csináljak?

--
trey @ gépház

Ahhoz képest elég hevesen kapálózol, hogy minden kirúgás után megengedje, hogy visszagyere. Ha van PayPal számlád akkor vegyél neki valamit http://hup.hu/node/105119#comment-1330867 hátha veled kivételt tesz és nem kell a bonyolult regisztrációt végigcsinálnod. :-D

Vagy mondok mégjobbat! Tedd lehetővé, hogy a blogodon legyen "anon+automatized regisztráció" és akkor ott majd te lehetsz "Trey" :)

--
maszili

Van nekije úgy néz ki még gagyibb weboldala is..
http://pcforum.hu/sugo/lap/impressum.html
"Színvonalas" mű.. a színvilágot le kellene védetni..:)
Erre valóban büszke lehet.. már értem miért csorgatja itt a nyálát és veri a mellét.:))

Szóval..
.. tényleg ez a kopasz kis mitugrász giliszta toporzékol itt a hup-on?:)
http://partizaninfo-wanted2008.blogspot.com/2008/01/brczi-gbor-flrja-ny…
http://hu.linkedin.com/pub/g%C3%A1bor-b%C3%A9rczi/10/a78/502

Egyre szimpatikusabb a hup és Trey.. azt hiszem egyszer még megkövetem..

Ui: lehet még hajnövesztőt venni? vegyünk már ennek a szerencsétlennek, mert egyértelmű, hogy ezért van ekkora kisebbrendűségi érzése..
Ui: látom bee fentebb, még nem sikerült összekapnod magad.. adok egy kis időd, hogy fényesítsd a fejed hátha valami értelmeset is böfögsz egyszer.:-)