Holnaptól tiltja a T-Online a dinamikus ügyfelei 25-ös portját!

Hálózatok egyéb

Headsup annak, aki esetleg T-Online-os DSL-en, KTV-n lógó ügyfeleket üzemeltetne, saját SMTP szerverrel:
holnaptól a T-Online elkezdi tiltani a dinamikus (DSL, KTV, dialup, stb) IP-vel rendelkező ügyfelei kimenő, TCP 25-ös portját (LiRul eredeti felvetése: http://hup.hu/node/31447) és csak a mail.t-online.hu-t lehet majd ezekről elérni.

  • 15289 megtekintés

ezt mar mindenki tudja. sokan nem is szerzodnek vele,ha tehetik. (koztuk en is)

ps.: tventwork.hu -tol ezert jottem el anno. kis vita port engedelyzeve, majd uj rgazda es megint tiltva igy goto 1. en meg a penzemert nem vitatkozni akarok minden fajta kezdorgazda/usz-sel. magyarul: szopjanak le.

szerintem meg az szopjon le, aki ragaszodik ehhez a módihoz, hogy minden dinamikus ip-ről lehet küldeni.
1.: a fél világ tilt
2.: lehet, hogy Te szívsz, de helyette megszabadulunk több ezer vagy még több spambot-tól, ezt hívják közösségi gondolkodásnak. Ha jól emlékszem Te is szidtad a magyar módszert, hogy mindig a irigység, semmi közösség. Hát tessék, most itt van a közösség védelme és nem tetszik
3.: a szabályok általában nem a szopatásra vannak. Azért nem tetszenek a legtöbb embernek, mert akkor meg kell változtati a szokását. Az, hogy a fél világ szív emiatt, az nem számít.

"Ha kitiltasz valakit, akkor tud másik néven regisztrálni nem?"

Nem. Mivel én hagyom jóvá a regisztrációkat. Azt ugyan meg lehet tenni, hogy fake néven újra regel, de az első pár hozzászólása után, ha megint nem bír valaki magával, banra kerül. Előbb utóbb elfogy a kedv új email címek regisztrálására. Én nekem ez nem fáj, egy kattintás az egész. Jobban jár mindenki, ha a minimális kérést betartja.

Offtopiknak inkább az "Offtopik"-ban nyissatok szálat. Ne itt tárgyaljunk erről.

--
trey @ gépház

már nem azért, de nem a küldést, hanem a fogadást tiltja. Egybéként meg baromira nem érdekel, ha másik relay-t használok. Néhanapján a szolgáltatók smtp szervere blacklistre kerül. Persze ezzel ki vagyok segítve....

Szóval: az ok, hogy nem érdemes küldenem, de miért nem fogadhatook leveleket?

( uid_228 | 2007. 06. 25., h – 10:14 )

És a T-Online saját mailserverei ezentúl működni fognak rendesen? :))))

Ahol át kellett állnom másikra, ott ez nem véletlenül történt. Simán előfordultak fél-egy napos késések a küldésnél, ami mondjuk egy speditőrcégnél nem túl nyerő. Ja, és ráadásul nekik még fix IP-jük is volt, tehát valamilyen szinten kiemelt ügyfelek voltak. :/

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

A névváltásig elképzelhető, passz, már régen volt.

Amikor Axeleróból TO lett, akkor átírtam mail.t-online.hu-ra (talán még körlevelet is küldtek róla anno), de azzal meg nem működött, visszadobta a kimenő leveleket. Így lett belőle smtp.t-online.hu, az volt lassú. Azt ugyan látom, hogy jelenleg ez azonos a mail.axelero.hu-val, akkor nem tudom, hogy mi volt a helyzet.

Mindegy, 2+ éve nem a T-online SMTP-szerverét használják, azóta működik jól a kimenő levelezésük. :))

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

Bizonyára érzékcsalódás áldozata vagy. ;))

Közben eszembe jutott még, +1 ok a dinamikus IP-n levelezőszerverhez: ha az irodán belül is van levelezés, akkor azt jobb helyben elintézni, mint kipasszírozni ADSL-en, aztán újra letölteni.

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

"Bizonyára érzékcsalódás áldozata vagy. ;))"

Vagy inkább rossz tapasztalat :)

"ha az irodán belül is van levelezés, akkor azt jobb helyben elintézni, mint kipasszírozni ADSL-en, aztán újra letölteni."

Iroda mérete válogatja. 2-3 kliensért nem szoktak mail szervert beállítani. Sokallják rá a lóvét.

--
trey @ gépház

"ha az irodán belül is van levelezés, akkor azt jobb helyben elintézni, mint kipasszírozni ADSL-en, aztán újra letölteni."

Iroda mérete válogatja. 2-3 kliensért nem szoktak mail szervert beállítani. Sokallják rá a lóvét.

Nekem az a tapasztalatom, hogy ez cégfüggő (értsd: zsugori-e az ügyvezető :) ).

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

Lehet levelezőszerver dinamikus ip-n is, csak használja relayhost-nak az isp-szerverét. Így a "belső" leveleket nem küldi ki az isp-hez.

Nekem "dinamikus" ip-m van, ami olyan, hogy január óta nem változott. (Akkor váltottam isp-t) Viszont sorbs-ban benne van, mint dinamikus tartomány. Innentől b@szhatom a levélküldést saját kis smtp-szerveremmel :(

Felteszem dinamikus tartományban vagy. Ebben az esetben elmondhatom, hogy ezt a chello is elkövetti időnként. Vannak olyan IP-ik, amiket tilt, mielőtt a saját smtp szervere átvenné a levelet. Tiszta őrület, de a lényege az, hogy a saját IP-in is végez blacklist ellenőrzést.

Csak 28 millió helyen lett elmondva (igen, abban a körlevélben is, amelyikre emlékszel), hogy a mail.t-online.hu-hoz SMTP autentikáció kell, ehhez képest a kezdorgazda (megtetszett ez a szó :) feladja az első kísérlet után, majd sziggya a szógátató mélszerverét.

Jaj, Adi. =)

Ha benne lett volna a körlevélben, akkor biztosan így próbálom megtámadni, azért ennyire szórakozottnak ne nézz már plz! :)

Ugye reagálsz valamit Trey fönti postjára is, hogy neki még mindig csinálja néha? :))

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

Persze. Mondtam neki, hogy reportolja. :)

Emlékeim szerint valami hasonló tartalmú oldalra mutató link került elküldésre:
http://www.t-online.hu/ajanlataink/termekek/20070514email.html
(www.t-online.hu/email)

Legalábbis a kliensek beállítása rész stimmelt. Nyilván a postfix beállításáról nem fognak screenshotokat készíteni, mert nem ez a célközönség.

Hm. Ha jól értelmezem, és így, egyszerűen egy linkre kattintva kikapcsolható a szűrés, és azt meg is jegyzi az ADSL/KTV accounthoz, akkor az korrekt.

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

( thuglife | 2007. 06. 25., h – 10:24 )

hurra megint hallgathatok X ugyfelet hogy nem megy a levelezoszerveruk es magyarhatom nekik hogy a szolgaltatonak sirjanak :)

Éspedig miért? Simán használhatna más smarthostot (a T-online-nál ez indokolt is :))), mint a szolgáltatóét, pláne ha igényesen: autentikált SMTP-vel, SSL-en át csinálja.

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

A szimpatikus, kedves magyar vállalkozót sokkal inkább kifizetik, mint a gonosz, arctalan multit. :)

Egyébként én sem rajongok az ilyesmiért, de volt már ilyen melóm, nem is egy.

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

Pont erre céloztam. Mehet egy dinamikus IP-ről is tök legitim forgalom TLS-sel és jelszóval védve egy külső smarthostra. Ezt ugyanúgy blokkolni fogja egy portszűrő, mint a kimenő spamet/férget.

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

Átmegyek linuxos fejlesztőmodelles flamewarosba: mondj jobbat, ha meg nem tudsz, STFU. ;)

A cél az, hogy attól a több százezer zombitól megszabadítsa a cég a világot és emellett aki akarja, tudja használni a szolgáltatást transzparensen.
Ezért lesz default mindenkinek bekapcsolva és ezért kapcsolhatja ki mindenki. Ha csak az kapcsolja ki, akinek tényleg kell, már megérte, de ez egy eszköz is azok tiltására, akik spammelnek (eddig ilyen nem volt).

A cél az, hogy attól a több százezer zombitól megszabadítsa a cég a világot...

Atyavilág! Csak nem fogják az összes országban, minden DT-érdekeltségnél kinyírni az ügyfélszolgálatosokat?!

;))))

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

Ha ez igy menne, mar hulyere kerestem volna magam... :)
Nalunk ez ugy megy valahogy, hogy Cisco netflow-val figyeljuk a a forgalom kulonbozo parametereit, es keresgeljuk a tuskeket (pl. a tcp/139 fele hirtelen megugro konkurrens kapcsolatok szama, meg az ellentetes iranyban erkezo nagy rakas icmp-admin-prohibit packet sok jot nem jelent), meg ezen kivul van "klasszikus" NIDS is, leginkabb arra, hogy ellenorizzuk a gyanut, vagy hogy figyeljen arra, amit igy nem lehet eszrevenni.
Ezen kivul meg vannak low-interaction honeypotok elszorva a halon, ha valaki azokat elkezdi ellatni virusmintakkal, akkor szinten be lesz mark-olva "ALJAS"-nak (egyebkent ezen nagyon gyorsan fennakadnak nagyon sokan, igy a "kezi" modszereket nem kell tul gyakran alkalmazni).
Amelyik gep pedig ezt a minositest megkapja, az kap masik VLAN-t, ahol gondolkozhat egyedul nyugodtan, amig a gazdaja kezelesbe nem veszi, es meg nem gyozodtunk rola, hogy tiszta.
Ez egyetemi halon mukodik is, egy ISP-nel viszont egyaltalan nem, vagy csak soksok munka+penz raforditasaval lehet ilyesmit csinalni, szoval... jo kerdes (bar hallottunk mar olyat, hogy a T. User radugta a gepet valamelyik kommersz ADSL szolgaltato halojara, ra nehany percre jott a telefon az ISPtol, hogy terjeszti a wormoket nagyban, es hogy szurik a worm altal hasznalt portokat, majd szoljon, ha leirtotta, es visszakapcsoljak - bar ez nem a T.* volt, es valoszinuleg nem uzemszeruen csinaljak).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( Csigaa | 2007. 06. 25., h – 10:28 )

Csodás spam-ellenes rendelkezés, főleg hogy a T-Offline SMTP servere egy open relay.
Lehet hogy előbb ezzel kéne valamit kezdeniük, a nagy hadakozásban?

LOL

Ne felejtsük el azt se, hogy régebben az abuse@ címről frankón pattogtak vissza a levelek, amikor az ember be akart nekik jelenteni valamit. :))

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

t-online halozatrol kuldted? mert akkor az nem open relay...

egyebkent altalaban nem engedi a @t-online.hu-tol eltero feladokat user+pass nelkul tovabbitani, de neha meg igen. kb 1-2 honapja epp nem ment, de kb 1 eve meg igen. de elotte is volt egy idoszak amikor nem ment. gondolom neha bekorlatozzak aztan ha sokan sirnak akkor UNDO.

A'rpi

( zsitvaij v | 2007. 06. 25., h – 10:33 )

lol. akkor mostmár ez sem fog működni?

eddig tök kényelmes volt hogy a helyi leveleket szétszórta a megfelelő helyre, a kimenőt meg továbbpasszolta az smtp.gmail.com-nak.

( Panther v | 2007. 06. 25., h – 10:47 )

szerintem már ma sem megy. 25-ös port: no route to host, a 80-as meg csak timeoutol.

( Skuzzy | 2007. 06. 25., h – 10:58 )

Hostolt servert hasznalom smtp-nek, mert laptoppal nem kell orokke mindenhol valtoztatgatnom.. (persze authtls)
Az mennyire igenytelen megoldas,hogy a szerveren forwardolom mondjuk a 26-os bejovo forgalmat a 25-osre? Igy 26-oson is elerem, es az nincs kiszurve...

( siposa v | 2007. 06. 25., h – 11:08 )

Ha jól tapasztalom, Emitelnél is így van.

( sany | 2007. 06. 25., h – 11:38 )

" lehet, hogy Te szívsz, de helyette megszabadulunk több ezer vagy még több spambot-tól, "

Ezt mivel magyarázod?
Melyik "házi" linuxos smtp küldözget utlokkal? 


X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-FW-Spam: No (7.7)

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

( arpi_esp v | 2007. 06. 25., h – 11:54 )

Hu, az fasza lesz. Van egy ugyfelunk, aki t-online adsl-en log, de nincs mailbox-a. Hogy miert, azt a T-sek sem tudjak, de nincs, es nem is tudnak neki csinalni, csak ha felmondja elofizeteset es ujra megkoti (rotfl.). A tonline smtp szervere meg persze authentikaciot ker... Ezert aztan most a munkahelyi szervert hasznalja mail kuldesre, sasl auth-al, de annak akkor most jol keresztbe tesznek :(

A'rpi

Ugyfel tobbszor volt szemelyesen is az ugyfelszolgalaton, verte az asztalt, sot mikor ok allitottak hogy marpedig van mailbox es ez+ez a belepes (ami persze nem mukodik), bevitet a notebookjat hogy akkor tessek beallitani rajta, na nekik se sikerult.
Utana en is beszletem veluk (telefonon), akkor javasoltak hogy probaljuk meg felbontani a szerzodest majd ujat kotni, akkor biztos kapunk uj, mukodo accot.

Egyeblent az a bajok forrasa, hogy amikor kotottek (uzleti elofizetest), akkor valami akcio volt epp es kaptak hozza ingyen egy .hu-s domainnevet, ami nem kellett nekik, de attol meg jart, es a mailcim is arra a domainre vonatkozott. a mailbox usernev is postmaster@domainnevuk.hu volt. Mivel nem hasznaltak a domaint, 1 ev utan, mikor mar kulon fizetni kellett volna erte, nem fizettek, igy az szepen meg is szunt a domiain nev. Es valoszinu ezzel egyutt a mailboxuk is... Az adsl elofizetes persze maradt, azt fizetik azota is.
Na most hiaba generaltak mar vagy 10x uj jelszot nekik, ahogy en neztem mar az usernevvel is gondja van a szervernek, azt pedig nem tudjak allitolag megvaltoztatni, csak uj szerzodes eseten...
(amit azert nehezen hiszek el, persze amiket olvasni a T-burokraciarol, semmi se lehetetlen)

A'rpi

Vegul is egy kozepes szintu hozzaertonek sem tarthatna tovabb 10 percnel ezt kisakkozni alias-okkal vagy barmi mas modon... de ha mar egyszer azt allitja a t-akarmi, hogy csak szerzodesbontas utan lehet ujra mailbox, akkor siman megmondanam, hogy ezt adja irasba, ezek utan kozolnem vele, hogy o.k. bontok, de ujat mashol kotok es az irasba adott bontasi kenyszer papirt valamint az uj elofizetesemet a masik cegnel postazom a felettesenek. Biztos lehetne ott meg keresni valamit :-))

Udv:
Feri

Hja. Az a legnagyobb baj, hogy ezeknel a mammutcegeknel kozonseges halando csak olyan ugyfelszolgalatosokig juthat el, akik nem unix adminok, hanem betanitott munkasok, akik elott van egy szep kattingtatos windozos management felulet ahol az elore gyartott wizardokkal lehet nehany funkciot (pl. uj jelszo generalasa) vegrehajtani, de ha nem talal olyan gombot ami kene akkor mar tanacstalanok...

Btw amikor en beszletem veluk, e smegkerdeztem hogy akkor mondja el az smtp szerver beallitasahoz az user+pass-t, egybol azt kerdezte, milyen programmal levelezek (nem mintha nem lenne tok mind1). Mondtam, thunderbird, de amugy nem mind1? Mondta, hogy ahhoz nem ertenek, csak outlook-hoz. Hulye droidok...

A'rpi

Nem az ugyfelszolgakat hibaztatom, hanem a rendszert. Meg lehetne, es meg is kene oldnai, hogy ha a level-1 szuro (droid) nem tud mit kezdeni a problemaval (ergo nem az ugyfel a hulye, es nem lehet 1 varazslo kattintassal megoldani), akkor passzolja feljebb olyannak akinek tobb jogosultsaga van a rendszerben, es pl. meg tud nezni egy mailbox usernevet... ahelyett hogy ilyen tanacsokat osztogat hogy bontsuk es kossuk ujra a szerzodest :) kb mint a windoz ujrainditas...

Es en egy szoval sem mondtam, hogy mashol jobbak, mert mashol se... bar en pl. a pantel-nal megtalaltam a kiskaput, ha faxon kuldod el nekik a hibabejelentest, az egybol a muszakiakhoz jut, nem a droidokhoz :)
(nem ugy, mint az emailen vagy telefonon bejelentett dolgok - bar ha eleg sok szakszot hasznalsz az emailben, akkor kis szerencsevel azt is forwardoljak hozzaertobbnek :))

A'rpi

AHHAHHA, Invitel!

Velük valami olyat szívtam, hogy máig sem értem hogy csinálták. Adott volt négy hálózat:
- Invitel (valami dialup)
- T-Online (ADSL)
- NIIF/HBONE/Hungarnet, whatever you want (ssh login :)
- Interware (szintén ssh)

A mail.invitel.hu-ra az invitel hálózatból be tudtam lépni rendben, az IP-je x.x.x.x volt. Na innentől nem emlékszem pontosan, hogy melyikből, de a T-Online-tól biztosan, az IW-től, vagy a HBONE-ból pedig valamelyikből nem lehetett ugyanazzal a login/pass-szal belépni.
Jobban megvizsgálva az esetet az látszott, hogy az invitel névszerverei az inviteltől (és a másik működő hálózatból) x.x.x.x-et adnak vissza, míg mindenhonnan máshonnan y.y.y.y-et.
Ha x.x.x.x-re léptem be, működött mindenhonnan, ha az y.y.y.y-re, nem.

Nem teljesen világos ezt hogy sikerült elérniük, mindenesetre a cégem rohadt ideges volt, felhívtam hát az ÜK-t, hogy mondjon már valamit. Mondom neki, hogy vigyázzon, amit most fogok elmondani, az bonyolult lesz és nem valószínű, hogy megérti.
Nézett hülyén a telefonba, de azért megpróbáltuk.

Aztán kaptam valami műszaki embert, akinek ismét beadtam a fenti képtelenséget, majd kb. lehülyézett, elkezdett ilyenekkel jönni, hogy állítsam be a névszerverem, meg hasonlók.

De van még, ha akarsz. :)

Olyan nincs, hogy nincs ügyfélszolgálatra szükség. Te okos, művelt, képzett, profi rendszergazda vagy, mégis lehet olyan pont az életedben, ahol már nem elég, hogy feltöröd a szolgáltató rendszerét és megjavítod magadnak a hibát.
És hidd el, a többség még a saját gépét sem tudja egyedül beállítani, nekik kell valami segítség.

Nálunk a cégnél pl. a belső hálóban a névszerverek olyan IP címeket adnak a kérésekre, amik csak a belső hálóban élnek.
A külvilág felé meg valami mást.

Nos, lehet, hogy a te példádban is az invitel a belső hálón xxxx-et adott, a külsőn meg yyyy-t. Aztán valamiért egy másiknak szintén a belső hálós adat ment át.

Vagy valami ilyesmi.

G

Szerintem rég rossz, ha egy interneten lévő autoritatív névszerver megkülönböztet belső és külső hálózatot, főleg, ha az előbbibe beletartozik egy másik ISP hálózata is, viszont egy harmadiké meg nem.

Persze nem kizárt, de ehhez azért valószínűleg több kellett, pld. egy load balance-olt DNS, és mindkét helyen sikerült más NS-t kapnom.

Szerintem a számlázó rendszer korlátja. Vannak ilyenek (persze ostoba tervezés, és ostoba kódolás eredménye), ami ilyen hülye dolgokat eredményez.

Már nem emlékszem, de az rémlik, hogy pl. valami előfizetési paraméter váltás (talán egyéniről üzletire, nem tudom) azzal jár(t), hogy a számlázórendszerben le kell szerelni, és újra fel kell szerelni a szolgáltatásokat.

De mivel leszereled, ezért pl. a mailboxból eltűnik minden levél. Stb.

Gondolom a T online esetében is hasonló a probléma, és bizonyára a főnöke, sőt a főnök főnöke is tud róla.

Persze fura, hogy egy mailbox címet miért nem lehet kijavítani. Gondolom kézzel azért lehetne, csak az ügyfélszolga a saját felületén nem rendelkezik ilyen opcióval.

G

> de nincs, es nem is tudnak neki csinalni, csak
> ha felmondja elofizeteset es ujra megkoti (rotfl.)

Nem egeszen ertem, miert gondolja barki a Tonline-nal, hogy ha valaki felmondja veluk a szerzodest, az ujra veluk fogja megkotni, ha ilyen egyszeru dolgokat se tudnak elintezni meglevo szerzodesu ugyfeleknek...

( hokuszpk | 2007. 06. 25., h – 12:21 )

very helyes lepes. a ceges tuzfalon magam is szurom kifele a 25-os portot.
na jo,a sajat kulso szerverunk fele nem, viszont arrafele egesz jol elvagyunk smtps/smtpauth -al.
ugye a 465 -ot nem szuritek ?

( airween v | 2007. 06. 25., h – 14:25 )

Hello bra,

a hír már a múlt héten eljutott hozzám, azóta is görcsölök, mit lehet majd csinálni - mint bennfentes, pls help! :)

Szal' az a helyzet, hogy X cég irodájában van egy T-Kábel-es előfizetés, a szolgáltató a T-Online. Rendeltünk fix IP-t, de azt mondták, hogy már nem szolgáltatnak (kábelen?) fix IP-t. Ezt nem értem, mindegy, elfogadom.

Van a mail.t-online-hu, ami SMTP-auth-ol, ezt sok helyről használom - ahol az irodai MTA tud ilyet. Ebben az irodában (sajnos) egy Windows 2000 SBS van, amiben az Exchange nem tud SMTP auth-ot :(

Ilyenkor mi a teendő? A cég saját domain-nel szeretne levelezni, tehát a szolgáltatáshoz adott user@ceg.t-online.hu címek felejtősek. Most (asszem') a mail.axelero.hu van beállítva, az meddig marad?

(válasz arra a kérdésre - másoknak -, hogy ezt miért itt kérdezem: mert a telefonos ügyfélszolgálat nem nőtt fel erre a szintre, és talán nem is az a dolga).

(szerk.: eddig az smtp.t-online.hu volt beállítva)

a.

A megrendelést nem én intéztem, hanem az ügyfél. Felhívtam a figyelmüket a fix IP-re. Nem kaptak, szóltam, hogy nézzenek utána (volt vmi helyi üzletkötő/kapcsolattartó, ő segített). Onnan jött az infó először. Mikor bekötötték, kint voltam a helyszínen beállítani a netet, és akkor is ez volt a válasz, hogy már nem szolgáltatnak, de a telefonos ügyfélszolg nem volt hajlandó többet mondani. Tudsz valamit, amit én/mi nem? :) Hol érdeklődjek?

Köszi:

a.

tapasztalat, hogy az értékesítők képesek hülyeséget beszélni. Ismerőst meg tudom kérdezni (aki nem bra:)), hogy mi a helyzet a témával. Az ügyfélszolgálaton nem vagyok meglepbe... :omg: Csak kellenének konkrétumok. (cégnév, valami azonosító ami alapján tudnak keresni)

Nah, helyzet a következő. Fix IP-t csak Kábelnet Profi (asszem ez az üzleti csomag)csomaghoz adnak, a többihez nem. De egyébként ehhez a csomaghoz rendelhető, be is tudják állítani, működik is a kontakt szerint. Küldj mailban adatokat, konkrétumok alapján jobban meg tudom nézetni.

( csko | 2007. 06. 25., h – 14:44 )

:(((
Elméletileg dyn ip-s vagyok, de már vagy egy hete nem sikerült IP-t váltanom...

"nem sikerült IP-t váltanom" != nem lesz IP cím váltás a szabadságom előtti péntek du. :)

Egyébként 2-3 naponta változik az IP.

(de tényleg ne ragadjunk le ennél a problémánál - hacsak nincs valakinek valami titkos telefonszáma, ahol megmondják, hogy ezt most miért...:)

Szakadás minden nap van. Áramszünet is volt azóta, modem restart, stb(persze egyik sem szándékosan, vagyis kivéve egy modem restartot mert leállt a net). Amúgy elképesztően selejt szolgáltatást kapunk drága pénzért, de ezt most itt nem részletezem.

lehet.. Engem nem ez a része érdekel: a suséss pppd esetén a régi ip cím újra lett kérve, vagy ilyesmi, amit pl. gentooban nem láttam, ezért már nem is megy nekem. A routeremen gentoo van, mióta a 8.2-es suse nem támogatott. Újabb meg nem ment rá :S Nyilván az i586 nem támogatott. Sux.

( lzrd | 2007. 06. 25., h – 17:12 )

Kell venni fiksz ípét és lehet vígan szpemmelni tovább. (Amíg blacklist nem lesz az IPből)
--
unix -- több, mint kód. filozófia.
Life is feudal

( tamsa | 2007. 06. 25., h – 17:23 )

Most beszéltem a t-online ügyfélszolgálatával és készségesen megoldották a problémámat.
Flotta szerződésünk van velük, és egyik előfizetéshez sincs mailbox, így nem is tudunk autentikálni. Ezt pár perc alatt kiderítette és megoldotta a dolgot. Sőtt javaslatot is tett arra, hogy használhatunk többen 1 azonosítót ha csak smpt szolgáltatás kívánjuk használni.
Ez volt az első olyan alkalom amikor gyorsan, jól oldották meg a problémám. eddig: 8-1 a rossz:jó hibamegoldás

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Nálam ezt úgy oldották meg, a kért időpont előtt 1 hónappal kötötték le a telefont (és a netet). Első körben az ügyfélszolgálatos sem értette a bajomat, aztán megemlítettem, hogy milyen időponttól kértem a lekötést, világos blett a helyzet. Másnap este ment minden újra.

Mázlis vagy...

Tavaly ezzel nekem majd' egy hónapig bénáztak, a T-Com és a T-Online egymás között pattogtatta a labdát, hogy kinél áll a folyamat, és miért nincs még átkötve a telefon az új lakásba, miután lemondtam az T-ADSL-t...
(bár ha az ő oldalukat nézem, akkor nem volt se telefon, se ADSL, tehát a feladatot elvégezték...)

a.

( nagy_peter v | 2007. 06. 25., h – 17:48 )

Szerintem nem rossz ötlet a szűrés, bár gyanítom, hogy egy héten keresztül mindenki hívni fogja a rendszergazdákat, hogy miért nem megy a levelezése. De aki ért hozzá, az úgyis könnyen visszakapcsolja. Akit meg nem zavar, hogy szűrik a 25-ös portját (észre sem veszi), az meg úgysem fogja engedélyezni.. (érdekli is őt.. Azt se tudta, hogy van 25-ös portja, mikor ő csak 4 USB-t lát a gépén) Szóval SPAM-ból, meg zombiból talán kevesebb lesz, a többi meg úgyis menni fog. Akkor hol itt a probléma?

( BaT | 2007. 06. 25., h – 20:17 )

És smtp-nek muszáj a 25-ös porton figyelnie? Pl. a gmail smtp kiszolgálója is az 587-es porton figyel, igaz az titkosított...

Ezekszerint csak akkor lepnek egy iranyba, ha komoly igeny merul fel iranta? Pedig lehetnenek uttorok. Jo persze nem azt mondom h ssl certet Mari neninek is, de mondjuk a nagyfelhasznaloknak, vagy akik eleve PKI-be illesztenek be a sajat rendszeruket, jol johetne. Azt meg minden mail.t-online altal atvett level headerjeben latom, hogy: 


Received: from foobar.hu (unknown [62.201.xx.xx])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by mail02d.mail.t-online.hu (Postfix) with ESMTP id 9E7E2BA65
        for <linux@mlf.linux.rulez.org>; Tue, 26 Jun 2007 09:36:35 +0200 (CEST)

Úgy gondolom, hogy kevés hasonló méretű cég rendszere van felkészítve arra, hogy szélesebb körben certificate-eket használjon user autentikációra, míg mindegyik rendelkezik kész megoldással a jelszavas részre (pld. LDAP-pal, mint backend és ennek autentikációs (weblapok, e-mail, ftp, radius, stb) megoldásaival).
Elég kicsi esélyét látom annak, hogy ez a belátható jövőben változzon, de persze ki tudja.

( LiRul | 2008. 01. 11., p – 21:11 )

Bra, nem feltetlen nyitnek uj topicot a kerdesnek, ez is T-Online-hoz, s némileg spamhoz tartozik. Ha valaki smarthostnak a mail.t-online.hu-t hasznalja, akkor en fogado oldalon milyen T-s smtpd-ktol kaphatom meg a maileket (IP)? Amiket jelenleg be tudtam azonositani: 84.2.40.5-tol 84.2.40.9-ig. Koszi!

Ha semmit sem tudok ezekről az alábbi módon indulnék el:
host mail.t-online.hu
mail.t-online.hu has address 84.2.46.3
mail.t-online.hu has address 84.2.44.3

Ezek láthatólag nem azok a címek, amiket te kaptál, de nyilván ezt használják a userek, tehát:
telnet mail.t-online.hu 25
Trying 84.2.44.3...
Connected to mail.t-online.hu.
Escape character is '^]'.
220 mail01a.mail.t-online.hu ESMTP You must authenticate before sending mail

Nézzük a másik címet is:
telnet mail.t-online.hu 25
Trying 84.2.46.3...
Connected to mail.t-online.hu.
Escape character is '^]'.
220 mail01d.mail.t-online.hu ESMTP You must authenticate before sending mail

Hmm.
host mail01d.mail.t-online.hu
mail01d.mail.t-online.hu has address 84.2.42.6
host mail01a.mail.t-online.hu
mail01a.mail.t-online.hu has address 84.2.40.6
Aha!

Ebből kiindulva:
for a in 40 42
> do
> for b in `jot 10 5`
> do
> host 84.2.$a.$b
> done
> done
5.40.2.84.in-addr.arpa domain name pointer mail00a.mail.t-online.hu.
6.40.2.84.in-addr.arpa domain name pointer mail01a.mail.t-online.hu.
7.40.2.84.in-addr.arpa domain name pointer mail02a.mail.t-online.hu.
8.40.2.84.in-addr.arpa domain name pointer mail03a.mail.t-online.hu.
Host 9.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 10.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 11.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 12.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 13.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 14.40.2.84.in-addr.arpa not found: 3(NXDOMAIN)
5.42.2.84.in-addr.arpa domain name pointer mail00d.mail.t-online.hu.
6.42.2.84.in-addr.arpa domain name pointer mail01d.mail.t-online.hu.
7.42.2.84.in-addr.arpa domain name pointer mail02d.mail.t-online.hu.
8.42.2.84.in-addr.arpa domain name pointer mail03d.mail.t-online.hu.
Host 9.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 10.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 11.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 12.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 13.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)
Host 14.42.2.84.in-addr.arpa not found: 3(NXDOMAIN)

Ebből azt mondanám, hogy 84.2.40.5-8 és 84.2.44.5-8, de ezt ugye sosem jó bedrótozni sehová, úgyhogy nem is értem miért kérdezed. :)

Koszi szepen! Bedrotozni csak annyiban szeretnem, hogy feltennem whitelistre ezeket a cimeket, joval kevesebb ellenorzest vegezven az innen erkezo levelekre. Termeszetesen, ha a megnovekedett terheles miatt a T-sek uj smtpd-ket allitanak hadrendbe, azok nem lesznek benne a kivetellistaban. Level emiatt el nem fog veszni, csak amig eszre nem veszem az uj IP-ket, az azokrol erkezo mailekre minden --amugy szokasos-- vizsgalatot el fog vegezni az smtpd-m.