Nagy cégek ócska SMTP szerverei

Flame

Bongeszgetem neha az mta-ink queue-jat, s rettentoen el tudok szornyukolkodni azon, hogy mekkora cegek b*nak a levelezesukre, mert nem megy/felre van konfigolva az smtp szerveruk.

Topicnyitonak kezdjuk ezzel:

$ date
Fri Mar 17 19:34:04 CET 2006
$ host -t mx samsung.hu
samsung.hu MX 8 mail.samsung.hu
$ telnet mail.samsung.hu 25
Trying 194.149.3.186...
telnet: Unable to connect to remote host: Connection refused

A kezbesitendo levelet 16-an hajnali 1:55-kor irtak, azota kezbesithetetlen, mert nem megy az mta-juk. sulyos.

  • 7887 megtekintés

( trey | 2006. 03. 17., p – 19:47 )

A Samsung valóban nagy cég, de a Samsung.hu?

Btw: egy csomó helyre járok, ahol siralmas gépeken futtatnak levelezést. És legtöbbször nem a rendszergazda a tróger, hanem a tulaj, aki sajnálja a pénzt a megfelelő vasra.

--
trey @ gépház

Nagy cegek alatt olyanokat is ertek, akiknek neve hallatan a legtobb ember tudja mire gondoljon. Irhattam volna gipsz jakabne bt-jenek mta-jarol is, de az senkit nem erdekel. (Viszont ne is gmail/aol-szintu cegekre gondolj.)

Flame-be postoltam, de nem egyenek ellen szolok. Csak a falnak megyek attol, hogy ahol napi nyereseg milliokban merheto ott nem kepesek ilyen nuansznyi dologra odafigyelni, mint egy mta.

( jaci | 2006. 03. 17., p – 20:06 )

Sajnos egyre több az ilyen, és én is a falnak megyek ezektől. Aki be tud írni 5-6 sort a postfix main.cf-be az már "profi"-nak hiszi magát.
Az a szomorú, ha egy mailservert tökéletesen bekonfigolsz, akkor valószínű hogy saját magadon kívül senkivel nem tudsz levelezni....

( Sun | 2006. 03. 17., p – 20:47 )

Igaz nem félrekonfig, hanem tudatlanság, de...

Ma kaptam(unk) egy levelet hogy azonnal oktassuk ki a dolgozókat, hogy csak < 1MB levelet küldhetnek, mert ha nem így tesznek akkor úgy tekintik mintha nem válaszolnánk...

Ő a volkswagen.sk

( uid_228 | 2006. 03. 17., p – 21:45 )

Óóóó, ez régi és kedves téma. :))))

Nincsen a kimenő mailservernek rendes reverse DNS-e, a HELO string a DNS-ben nem létezik, mint a két leggyakoribb bénázás. :I Ráadásul mindez olyan helyeken, ahol az ember a cég nevéből azt gondolná, hogy van pénz megfizetni egy hozzáértő rendszergazdát. :I

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Meg amikor a 67MB-os mail hasra vágja az exim+spamd duettet, illetve a spamd részét, de szért legyen korlátlan minden. Konkrétan a másfél giga ramos szerveren újabb másfél gigát swappelt el a spamd. Azóta picit okosítottam a kérdésen. :)

Egyébként a UPC SMTP-i miatt sem lehet a rossz/hibás zónabejegyzésekre támaszkodni. A reverse vs. A rekord gond van velük. :(

A másik, ami utálok, hogy jön ez a millió inet@microsoft.com -os feladós cucc (egészen mig nem tűzfalazódnak ki) és hiába írok az netadmin címekre, szarnak rá sokhelyen. Egyszerűen érthetetlen, hogy ha a hálózat adminok nem hajlandok picit sem tenni ezügyben, akkor mégis mitvárunk az egyszeri felhasználótól?

Sokszor nem azzal van a gond hogy nem akar tenni ellene hanem hogy nem tud. Hiába írsz neki hogy ez meg ez a bibi, még ezekután sem tudja megoldani. Az ilyentől nem lehet azt sem sem élvárni hogy a saját logjai alpján elhárítsa a hibát, ha egyáltán tudja miaz a log...Vagy hogy mit kell nézni rajta:)

Nem jártam egyetemre, szerintem nem is onnan kellene a naprakész információkat beszerezni. Az a baj,hogy nagyrészt hozzánemértő láma f*szok azt hiszik hogy értenek hozzá.
Ha meg azért egyetemre kell menni hogy egy hostot és reverse zonat valaki beállítsa, és a logokat értelmezni tudja, akkor az már nagyon nagy probléma és szerintem az illető pályát tévesztett.
Pl elég sok a kátyú az utakon, lehet hogy jobban illene hozzá az a munka.

Persze, mert az niif-es halo bazinagy. Azt meg lehet nem latod, hogy sok *muzeum, *konyvtar van, ahol van egy olyan ember aki a tobbieknel jobban ert szamtechez (ertsd: win-re tud programot telepiteni) es egyszercsak koltseghatekonysagi okokbol megkapja egy *smtp uzemelteteset. Persze hogy nemtud vele mitkezdeni. Egyebkent az niif-ben az ilyen problemakat a csirt-nel meg lehet reklamalni, ok eleg hatekonyan (pl. az adott ip-t egy az egybe kitaltjak) szoktak intezkedni...

Mik

UPC miatt nálunk is volt az utóbbi időben folyamatosan szívás. A vége az lett, hogy egy subnetjükre a reverse DNS ellenőrzését kikapcsoltam, mert egyszerűen olyan volt, mint a népmese: hol volt, hol nem volt. :I Milyen rendszergazdáik vannak, hogy ilyen egyszerű dolgot nem képesek megcsinálni?! :I

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

A beérkező leveleknél a Postfixeim (kikapcsolható módon) a küldő gép IP-jére csinálnak egy reverse lekérdezést, hogy mi a neve. Az UPC-nél ez kb. heti rendszerességgel megszűnik működni, majd visszaáll.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( andrej_ v | 2006. 03. 18., szo – 14:29 )

Viszont akkormár ki kéne dolgozni néhány általános ajánlást és ittott próbálni hírdetni. Olyanokra gondolok, amik minden normális MTA-val könnyen elérhetők. A célok a hamis feladók/hosztok, spamek, vírus és hasonló fölösleges forgalmak visszaszorítása lehetne. Mindezt addig, amíg nem újul meg nagyon az SMTP protokoll vagy jön jobb. :)

Van ajánlás: rfc821,rfc1869 stb. Viszont senki nem meri teljesen betartani. Ha teljesen betartod, megszabadulsz a spam-ek nagy részétől, viszont drasztikusan megcsappan az amúgy rendes leveleid száma is. 8)

"Mé' nem megy el magukhoz a levelem? Máshoz elmegy, így biztos maguk nem értenek hozzá."

Ennek oka: az isp-k sem merik az rfc-t betartani, márpedig érdembeli levélforgalom náluk bonyolódik. Ha egy csapásra minden hazai isp azt mondaná, hogy na mostantól menjetek a fenébe, szigrúan vesszük a rfc-t, akkor a hazai gondokat meg lehetne oldani, ugyanis nem mondhatná azt Fikusz Jancsi, hogy "De máshoz elmegy".
Megfordulna a dolog, rengeteg alibi admin feje hullana a porba.
Viszont innetől kezdve jönne a többi probléma, ugyanis külföldön sem jobb a helyzet, mint itthon.
Az, hogy egy két emberke nekiáll ezt megvalósítani az kevés, úgy ők maradnak kisebbségben, most is vannak jó páran, akik küzdenek ezzel.
Csak úgy lehet, ha a többség be tartja a szabályokat.

Emlékeim szerint a 2821-es RFC az idevágó. Reverse DNS valóban nem kell, viszont a HELO/EHLO után feloldható hostnév, vagy MX-nek KELL (MUST) szerepelnie. Na, sok helyen még ez sincs meg, mert bekonfigurálták a mailservert valami belső hostnévvel, amit vidáman hirdet a külvilág felé is levélküldéskor. :I

Az alibi-adminokra meg van egy érdekes történetem is, ahol a hozzá nem értés kirívó pofátlansággal párosult. :I

Egyik ügyfelünk egy alapítvány, az ott dolgozó egyik nőnek a pasija egy ilyen szolgáltatásokat nyújtó cégnél melózott. Mivel egyszer csak nem tudott a nőnek írni (a HELO string miatt a Postfix visszadobálta a leveleit a sz*rul beállított irodai Exchange-üknek), elkezdett balhézni. Amikor a kollégámmal a pontos RFC számot is megadva elmagyaráztuk nekik, hogy mi a gond és hogy ők nem képesek az Exchange-üket normálisan beállítani, akkor nem elég, hogy még lehülyézett minket, de rögtön az alapítvány igazgatóját is letámadta egy árajánlattal - mondván, hogy az ő cégük majd átveszi a levelezés menedzsmentjét. Szerencsére az igazgató tisztában volt vele, hogy ki a hülye és kiröhögte. :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nem tudom, miért problémáztok a HELO-n annyit. Az egész egy címeres ökörség, semmire sem használható. Ez abból az időből való, amíg az Internetet ~10 gép alkotta.

Az RFC egyébként ezt mondja:

These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.

Tehát nem kell A/MX rekord. A SHOULD pedig azt jelenti: RECOMMENDED. Az egész HELO-nak nincs semmi értelme. A rossz HELO-ra jó sok SpamAssassin pontot kell adni és kész.

Ja és még valami DJB oldaláról: (http://cr.yp.to/smtp/helo.html)
RFC 1123 prohibits HELO-based rejections.

No comment...

Nem sértődöm meg, de a HELO-nak akkor sincs semmi értelme, ha a szabványban leírták. Persze, mivel le van írva, használni kell, de hát azért hőbörögni lehet, nem? :)

Azt meg végképp nem értem, hogy a spammelőknek miért kell rossz HELO-t használni. Bár igaz, ehhez tudni kéne a publikus ip címet, ehhez pedig legalább 1 paranccsal több kell. Szóval, amint tömeges lesz a HELO miatti spam eldobás, szerintem azonnal jó helo-val érkeznek majd a spamek. Nincs mese, spamszűrő kell.

megneztem ezt az rfc 1123-at. ide vonatkozo resz:

5.2.5 HELO Command: RFC-821 Section 3.5

The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

(a vastagitott resz magyarul: a fogado oldalnak tilos visszautasitani az uzenetet, meg akkor is, ha a kuldo helo parancsanak ellenorzese sikertelen.) igy valoban igazad van. mar nem volt hiaba valo a topic inditasa. :) sajnos akkor egy ervenytelen helo/ehlo tenyleg maximum spampoint novelo lehet, mas nem igazan. mar ha rfc compilant akar lenni az mta-t uzemelteto gazda.

sajnos akkor egy ervenytelen helo/ehlo tenyleg maximum spampoint novelo lehet, mas nem igazan. mar ha rfc compilant akar lenni az mta-t uzemelteto gazda.
Nem. Bár jól értelmezed az ajánlásnak ezt a részét, de nincs igazad.

A HELO ellenőrzés nem mindenható, de sokat számít.

A HELO-nak meg kell felelnie bizonyos alapvető szabályoknak, még ha nem is köthető a kliens IP címéhez, vagy nem oldható fel bizonyos szabályok szerint.

Ha valaki idejön hozzám és azt HELO-zza, hogy "abubbuuubbu" akkor én kivágom, min a *****. (illetve nem, még nem, de hamarosan ezt fogom tenni. :@)

nem tudom, hogy akkor ki ertelmezi jol az ajanlast. ha neked jon valaki egy "abubbuuubbu" helo-val, annak az ellenorzese sikertelen lesz. pont azert, mert nem felel meg az ajanlasnak. viszont a boldositott resz kimondja, hogy ez esetben sem szabad eldobni a kapcsolatot.

hozzateszem: most szigoruan csak az rfc-t nezem, az sajnos termeszetes, hogy a balf* helo igen magas %-a spam. (de nem mind)

:-D Aszittem, ez nekem szól... erre mégcsak nem is az a topic... :-D

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

Kéretik némi kétkedéssel fogadni mindent amit leírok.
Jelszavam - Sándor Györgytől kölcsönözve: "A hülyeség, ha nem is xylofonozik - FOSZFORESZKÁL!!"

Kissé félreértetted. Amiatt nem szabad visszautasítania, ha a HELO paramétere nem arra az IP címre mutat, ahonnét a levél jön.

Annyi mindent írtatok, talán az RFC-t kéne megnézni:

ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

3.6-os pont:

Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:

- The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

IMHO a 3.6-os pont nem kifejezetten a HELO-ról szól, hanem általában a domain nevekről. Azaz HELO-nál FQDN vagy address literal jöhet. Ami nem világos, hogy NAT-olt gépnél a HELO paramétere lehet-e privát IP cím. Szerintem alapvetően igen ("address literal"), innentől kezdve mindenki azt ír oda, amit nem szégyell.

azt hiszem en azok koze az 1-2 emberke koze tartozom. :)

hetente jon a telo, hogy valaki nem tud levelet kuldeni nekunk (persze beszallito) en akkor szepen leirom mit basztak el a szerveruknel, de mar faraszto. inkabb azt mondom: maguk hulyek az emilhez kerem faxoljanak. :)

De szívemnek kedves ez a flame. :) Néha úgy érzem egyedül vagyok. Én bezettem a következőket.

smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/luzerhelo, reject...

smtpd_client_restrictions = check_client_access hash:/etc/postfix/luzerip, reject_unknown_client

Én már nem vitatkozok, aki elsőre nem érti hogy a localhost.localdomain -nel helo -zó exchange miért nem tud "csak mindenki másnak" levelet küldeni, és persze a cégnek fontos hogy azért megjöjjön a mailje, az megy a luzerlistákba-ba.

Na valahogy így vagyok én is. Tényleg durva, hogy milyen nagy cégeknél is előfordulnak ilyen gondok, vagyis leginkább ott! ...és ami ennél is érdekesebb, hogy informatikai cégek viszik nálam a pálmát. ...pl egy magyar, de világhírű cég is.

A legjobb, hogy általában a nagy infós cégek kifejtik, hogy én nem értek hozzá, meg így meg úgy az SMTP protokoll, aztán azért csak rábeszélem őket, hogy elküldhessem nekik a napló részletét. Ezek után se egy bocsi (a hangnem miatt), hanem egyszer csak látom mégis jön a mail.
A legviccesebb az volt, amikor a fent említett magyar, de világhírű cégnél ismét gond volt. Közölték, hogy az ő DNS-üket használjam, mert abban jól szerepelnek a gépnevek. ..nem értették miért nem akartam használni a DNS-üket. ...inkább felkerültek kivételnek, mert a levelek kellenek tőlük.

Üdv: M.

http://www.pingit.homelinux.org a megoldás.

( sj | 2006. 03. 21., k – 17:37 )

Az en kedvencem meg az, amikor xy szol, hogy 'he, rajta vagytok xyz rbl listan, es nem tudunk nektek levelet kuldeni (vagy mi nem tudunk nekik), es csinaljatok valamit, keruljetek le rola.' Erted? Az en problemam az, hogy _o_ egy (v. tobb) megbizhatatlan rbl listat hasznal....

ASK Me No Questions, I'll Tell You No Lies

ezekre a bl-ekre altalaban harom fele keppen lehet felkerulni: vagy spammeltek a cimrol, vagy floodoltak (pl. tomeges hirlevel, ami nem biztos, hogy spam, de mindenkepp flood), vagy openproxy a szolgaltatasod. a magara valamit is ado bl admin nem fog egyetlen spam-report utan felvenni a listajaba, ahhoz eleg sok jelzes kell ill. ismetelt tevekenyseg. mivel te adminolod az mta-t, ezekrol mind tudnod kell s valamilyen szinten felelosseget is vallalod. van persze olyan, amirol nem te tehetsz; tipikusan iyen a dul (dial-up list), ami az isp-k dinamikus ip cim tartomanyait tartalmazza. ha arrol az ip-rol amit epp most te hasznalsz elozoleg spammeltek s bekerul egy bl-be, nem te tehetsz valoban. ezert kell smarthostot hasznalni, ami alt. az isp-d smtp szervere.

"Na ennek örülök. Ezek szerint az IP-hamisított spam nem túl gyakori, azért nem kell (nagyon) aggódnom, hogy valaki a domainemről ÉS az én (statikus) IP-met odahamisítva spammel."
Dehogy nem kell aggódnod.
A nyakamat merném tenni rá, hogy bármikor átküldök a te mail szervereden is (már ha van) egy spamet bárki számára az interneten.

És persze a te szervered ip címe nem "bele lesz hamisítva" a spam-be, hanem gyakorlatilag és konkrétan a TE SZERVERED FOGJA KÜLDENI azt a spam-et, amit én adok át neki kézbesítésre.

Természetesen nem lesz semmi hackelés, csak egy egyszerű sendmail parancsot fogok kiadni a szerveremen a megfelelő paraméterekkel, és máris landol az e-mail címeden a spam, úgy, hogy látszólag a te mail szervered küldte neked.

Ha nem hiszed, akkor tegyünk egy próbát: küldd el ide a mail szervered domain nevét: szucspontmeeiponthu, és egy adj meg egy külső e-mail címet is, amin majd a spam-et detektálhatod.

A próbán csak nyerhetsz: ha nem sikerül, akkor megkövetlek (mondjuk ez speciel nem nagy haszon), viszont ha sikerül, akkor olcsón rájössz, hogy a konfigodon még egy csöppet finomítani kell (mert bizony még egy ártalmatlannak látszó beállítással is könnyen vissza lehet élni).

Ne keverd össze azt, hogy meghamisítod egy mailszerver IP címét azzal, hogy egy spamet bounce-oltatni tudsz, esetleg a feladó domain-jét hamisítod.
Az általam ismert IP spoofing technikák több kérést/választ tartalmazó TCP kapcsolatra csak nagyon speciális hálózati feltételek mellett használhatók (gyk. ugyanazon a LAN-on kell lenni, mint az áldozat). IMHO tényleges IP hamisítástól mail szerver esetén tényleg nem kell félni - mivel ennél sokkal egyszerűbb techinkák is léteznek. (Természetesen a HELO-ba és a headerbe akármit lehet hazudni, a tartalmukat ennek megfelelően kell komolyan venni.)
Spam bounce-olás ellen elég nehéz védekezni. RCPT check, return MX check, content rejection at SMTP-time segíthet abban, hogy legalább te ne küldj spam-et tartalmazó bounce-t.

Ha más a trükk, akkor bocsánatot kérek. Ez esetben várjuk, hogy a mester fellebbentse a fátylat a varázslatról. :)

ISP-k eléggé gyakran felkerülnek amiatt, mert vannak olyan vírusok, amelyek a legitim smtp szervert használják spam küldésre. Ezt elég nehéz kivédeni. Az RBL-ek pedig elég lassan reagálnak, ezt tanúsíthatom... :(

Megint csak (kövezzetek meg, ha akartok:)) az az igazság, hogy jó dolog az RBL, de nem mindenható. Sok SpamAssasin pontot neki!

BTW van rá nagios check, hogy rajta vagyunk-e RBL listán. Érdemes használni! Na meg azt is, hogy a Spamassassin a relay-zni való leveleket is csócsálja meg, hátha.

Tanusíthatom, mivel magam is használom őket.
...igaz pl. a nagy T szervereit fel kellett vennem kivételnek, mivel az egyik szerverük 2-3 hétig is ott volt a SORBS-on és nem csináltak semmit ellene. Szóval "az élet nem habostorta."

Üdv: G.

http://www.pingit.homelinux.org a megoldás.

...vagy legalábbis cseszegesse a szolgáltatót. ..bár hatni úgysem hat, én a monornetnél adtam meg ipcímet és időpontokat, hogy mikor próbálkoztak a kis idióták win-es portokat cseszegetni, de persze szartak rá.
(monornetes az otthoni gépem és monornetesek voltak a próbálkozók is)
Most akkor tegyek rendőrségi feljelentést informatikai rendszerbe való behatolás megpróbálásáért, aztán majd a yard kikéri tőlük, hogy mikor melyik címet kinek adta ki a DHCP?

Üdv: M.

http://www.pingit.homelinux.org a megoldás.

"nezd, a cimed nem ok nelkul kerul fol egy ilyen blacklistre."

Pl. mert nemely igen inteligencs rbl /24-eket vesz fel? Aki meg beleesett a szorasba, az bebukta.

Ajanlom figyelmedbe ezt a cikket:
http://www.paulgraham.com/falsepositives.html

Es egy gyongyszem a spews-rol:

"How do I get off the list?", SPEWS' FAQ answers "Sorry, SPEWS is a list of known spammers, spamming operations, and spam supporters, if you fit the criteria there's a good chance you will be listed and stay listed. If you are a spammer, may we suggest you get a real job?" In other words, if we say you're a spammer, you're a spammer. Forever. And if you're not a spammer?

(http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2873539,00…)

Na ezert mondom, hogy az rbl-lista (mint megoldas a spam-re) hasznalhatatlan, sot, a rengeteg false pozitiv miatt mar rosszabb, mint maga a spam. Tudomasul kene mar venni az embereknek, hogy ebben a formaban eljart felette az ido, ideje atterni korszerubb, valamilyen statisztikai alapu modszerre (pl. Bayesian, inverse chi-square, ...).

ASK Me No Questions, I'll Tell You No Lies

( rage | 2006. 03. 21., k – 21:18 )

Ugyan nem fatalis dolog, de azert alap muveltsegnel nem igenyel tobbet a dolog, megis sok mailhostnal lattam: "numeric domain name in resource data of MX record".

( sj | 2006. 03. 22., sze – 15:11 )

Meg az rbl-ek kapcsan jutott eszembe, hogy erdemes olyan email cimeket reklamozni, amely leveleit egy program dolgozza fel, majd kigyujti belole a te gepeddel kapcsolatba kerulo IP-cimeket (esetleg whitelist-tel kombinalva), es azokat teszi egy lokal IP-adatbazisba ugy 2-4 orara (aztan egy cron job automatice torli). Na pl. egy ilyennek latom ertelmet. Ebbe nem kerul bele egyetlen fals pozitiv, senki sem tesz bele /24-eket, etc.

ASK Me No Questions, I'll Tell You No Lies

( LiRul v | 2006. 03. 29., sze – 16:31 )

Kis adalek: azota sem jo a samsung.hu MX-e. Ez mar ROTFL.

Ujabb siramom, hogy hű maradjak a topichoz. metro.hu MX. Az idiota admin -- mert azt nem hiszem, hogy postfix default igy mukodne -- ugy allitotta be az MTA-t, hogy nem letezo email cimekre kuldeskor nem am 5xx hanem 450-es hibat kap vissza a kuldo. Grrrrrrrr... Igy probalkozhat a vegtelensegig, feleslegesen foglalja a savszelesseget es mindket fel szerverenek eroforrasait (CPU, disk, I/O stb.).

Azt viszont eszrevettem, s errol az egyik mlf listara is irtam, de ott nem izgatott senkit, hogy van meg jopar ilyen rosszul beallitott postfix (mert mind az, vagy legalabbis annak hazudja magat). Pl.:

mail.spiderweb.hu - 62.112.220.9
www.zalaszam.hu - 194.88.50.3
www.kmmk.hu - 193.225.90.90

Loosers.

Es vegre egy pozitiv peldaval is szolgalhatok. :-) Az kmmk.hu adminja felvette velem a kapcsolatot, megbeszeltuk, hogy mi a teendo, s megcsinalta. Korrekten, nem anyazva. Ot mar le is vettem a loosers listarol. :-) Sajnos a metro-soknak hiaba irtam emailt, le se sz*tak. Egyszer ha jo kedvem lesz, majd probat teszek a zalaszamnal es a spiderwebnel.

( LiRul v | 2006. 05. 07., v – 11:02 )

Tovabbi erdekesseg:

The address to which the message has not yet been delivered is:

  hirdetes@bumerang.hu
    Delay reason: failed to open /etc/virtual/bumerang.hu/aliases for linear search:
    No such file or directory

( LiRul v | 2006. 09. 13., sze – 14:06 )

Újabb érdekesség: 


2006-09-13 05:22:52 Malformed SMTP reply from mail0.primposta.com [195.228.75.75]
in response to initial connection: exim: /usr/local/lib/libsasl2.so.2: no version
information available (required by /usr/lib/libldap.so.2)

( Chain-Q v | 2006. 09. 13., sze – 14:34 )

Amikor az ex-melohelyemet felvasaroltak, akkor az uj tulajdonos Exchanget hasznalt, es nem tudtunk levelezni, mivel a kirajul bekonfigolt, es amugyis ultrabugos 5.5-os eszkcsencsuk osszef*sta magat a 8bites levelektol (holott EHLOzas kozben meg ofkoz azt hazudja magarol h. tamogatja).

Persze jott azonnal a werdikt, a kulhoni M$/Cisco-szertified agycsokevenyek kitalaltak, h. azonnal csereljuk le a szar nemszabvanyos Linuxunkat, hogy mukodjon a kiraly szertified Eksztsendzsel. Persze kuldtem linkeket a microsoft.com-rol, ahol leirjak a problemat, meg a megoldasat is, de figyelemre se meltattak, csak hetente ketszer kulonbozo PowerPoint fajlokat kuldozgettek a "migration process"-rol. Vegul a Postfixnal hala, lehetett workaroundolni a problemat, hogy veluk fixen 7bitesen akarjunk levelezni, lef*sva, hogy mit hazudik az Eksztsdendzs EHLO kozben, a vilag tobbi reszevel meg emberi modon.

Utana idekuldtek vmi dual Xeont, 3Ghz, anyamtyukja, hogy majd az lesz a lokalis Win2003 domain meg eksztsends nekunkis megmittomen. Ekkor jottem el, hogy ehhez en nem kivanok asszisztalni. Parszor megprobaltak ra migralni (mar nelkulem), nem sikerult. Azota is az altalam osszerakott 600-as Celeron + Debian viszi az egesz infrastrukturat, a dual 3Ghz meg zorog es fu"ti a vilagurt. Aztan neha felhivnak, ha kuzdeni kell a Linuxszal. :)

De legalabb most mar lehet mutogatni h. minden certified. :) Hat nem csodalatos?

(Ps: egyebkent hasonlo musor/hiszti ment a Cisco PIX vs. Linux tunnelek kapcsan is, azota is Linux tunnel (meg OpenVPN) van, deugye ez itt most offtopic, es asszem mar le is irtam a HUPra egyszer.:)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

De gonosz vagy, hogy nem certified solution-t telepítettél nekik! ;>
Remélem ha felhívnak továbbirányítod őket a certified szakemberekhez. ;>

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( rTib | 2006. 10. 16., h – 10:04 )

http://dsbl.org/listing?195.228.240.50

Status

IP: 195.228.240.50
State: Listed
Listed in unconfirmed (unconfirmed.dsbl.org): yes
Listed in singlehop (list.dsbl.org): no
Listed in multihop (multihop.dsbl.org): yes
Reverse DNS identifies server as: mta01.mail.t-online.hu

Nagyon orulok, hogy kedvenc ISP-nk mindent megtesz, tudasa legjobbjat adva a SPAM ellen.

TiB

Nyilván, én azt írtam ennek hogy kell működnie. És így lenne értelme megcsinálni, hogy feleslegesen ne szopassák azt, aki tudja mi az smtp és sajátot használ. De lentebb írja bra, hogy webes felületen kikapcsolható lesz a tiltás. Ez korrekt. Így kellene mindenhol.