tonline-os quota exceeded

Ilyeneket kapok ma:

postfix/smtp[8580]: C1AA42C18DB: to=, relay=mail.axelero.hu[195.228.240.10], delay=0, status=deferred (host mail.axelero.hu[195.228.240.10] said: 421 4.7.1 : Recipient address rejected: You have reached your daily quota. Please use mail.t-online.hu (in reply to RCPT TO command))

Ha átírom a javasolt mail.t-online.hu -ra, akkor az meg hisztizik, hogy nem relay-el.

Mi a fene van?

Hozzászólások

Szerintem nevet és jelszót kell megadni a mail.t-online.hu -nak, hogy továbbítsa a levelet.

--
hup.user.js

Este miután elküldtem a hozzászólást, azt gondoltam, hogy vmi trivit kérdeztem, mert senki más nem kérdezte meg a bennem felmerült kérdést. Ezért inkább ily módon töröltem.
De ahogy elolvastam a reggeli "termést", megkaptam a választ a kérdésemre a lentebbi hozzászólásokban.

Emlékeim szerint 2005-ben, mikor Axeleróból T-Online lett a cég kiment mindenkinek egy körlevél (valaki anyázott is miatta valami fórumon, hogy miért küldözget neki ilyet a cég), amelyben meg lett említve (sok más mellett), hogy mail.t-online.hu és linkek a beállításról.

A mail.axelero.hu meg fog szűnni, ne használd.

Hasonló stílusban. :)
Mennyi levelet küldesz naponta?
Ennyi levéllel miért dinamikus IP-s előfizetést veszel?
Stb.

Volt egy cég, ahol hálózatot építettem, meg úgy általában a kliensek konfigurációját, stb. végeztem. Pontosan már nem emlékszem hány gép volt, de a cégnek egy saját irodaháza volt, három szintes, olyan 50-100 körül dolgozhattak ott (nem mindenkinek volt számítógépe).

Mondták, hogy a legkisebb DSL-t akarják megvenni, de szeretnének saját weblapot, saját levelezőszervert, meg kutyafülét.
A legviccesebb az volt, hogy a cég, ahol nézték a DSL-t különválasztotta az üzleti és magán előfizetéseket, a magán persze olcsóbb volt (fele, harmada?). A faszi (vezérig. vagy micsoda :) előadta, hogy ő a saját nevére fogja megvenni, mert az olcsóbb.

Győzködtem kicsit, aztán feladtam. Megcsináltam, amit kért, dyndns, valami csumpi PC-ből valami szar szerver, aztán három hónapig könyörögtem a pénzemért.

Végül akkor fizetett ki, amikor kiderült, hogy szar az egész, mert kevés a sávszélesség, meg rengeteg a bejövő levél és egyszerűen nem bír átjönni és kérte, hogy adjak tanácsot. Nem adtam. :)

A lelki békéd érdekében olyat fogok tenni, amit egyik másik ISP-től sem kapsz meg (HUP-on előre szól valaki :). Most tájékoztatlak, hogy a dinamikus DSL-ed kimenő TCP 25-ös portja is le lesz tiltva -erről is fogsz körlevelet kapni, de azt ugye sem te, sem az ügyfeleid nem olvassák-, magyarul nemsokára (nem tudom mikor) ha nem a mail.t-online.hu-n keresztül próbálsz meg a postfixoddal levelet küldeni (bár mint írtad, ennek sok értelme nincs *MOST*, mivel mindenki spammel, mint állat, emiatt mindenhonnan tiltva vagy), az nem fog menni.

Mire föl:
- túl nagy már a zombihálózat és túl régen meg kellett volna már ezt lépnie a cégnek
- because they can (theos megközelítés)
- CSAK és ne szólj bele (ezt tőled tanultam ;)

Forrás: polifórum (néha érdemes olvasni), ami épp nem megy. :)

>>Most tájékoztatlak, hogy a dinamikus DSL-ed kimenő TCP 25-ös portja is le lesz tiltva...

Helyes, bár én annak is örülnék ha a dinamikus rbl-eknél (is) le lennének jelentve a megfelelő IP block-ok. (Lehet, hogy a t-* esetében pont így van, de sajnos sok szolgáltatónál nem.)

A T-Online esetében nagyon egyszerű dolgod van, még csak RBL-t sem kell használnod: tilts minden SMTP kapcsolatot *.pool.t-online.hu hostokról. Én is ezt teszem.

És igen: sajnos nagyon sok szolgáltatónál nem ilyen egyszerű megkülönböztetni a dinamikus usereket. Többel is szívtam már, mert látszólag poolos ügyfelek voltak, aztán kiderült, hogy fix IP-sek is vannak benne bőven. :-O

Hali.

... a dinamikus DSL-ed kimenő TCP 25-ös portja is le lesz tiltva [...] ha nem a mail.t-online.hu-n keresztül próbálsz meg a postfixoddal levelet küldeni [...] az nem fog menni.

Ezt most nem értem. Ha dinamikus DSL-em van, de a postfix a mail.t-online.hu -t használja relayhost -nak, akkor maradhatnak dinamikus DSL-en? Vagy?....

Próbálom hívni ezt a nyomorult tonline-t, de mivel én csak messziről üzemeltetem a rendszert, nincs hozzáférésem a kérdéses cég szerződéseihez, viszont még az ügyintézőt sem tudják kapcsolni, amíg nem adok meg egy 8+4 karakteres ügyfélszámot + azonosítót.

B+!

Annyit azért be bír mondani a droid, hogy a mail küldéshez azonosítanom kell magamat. De hogy mivel, azt már nem bírja elmondani, a TOnline-tól meg csak az adsl-t veszik, a mail szolgáltatást nem, de úgy gondolom ettől még a tonline-os smtp szervernek be kell fogadnia tőlem a levelet, mert az ő adsl-es subnetjükről jön.

Ha meg nem adok meg relayhost-ot a postfixnek, akkor kivágnának mindenféle grey- meg blacklistre a címzettek smtp szerverei, mivel dinamikusan osztott IP-je van a szervernek.

A gmicsko@ e-mail címhez pedig biztosan trey uid tartozik. A megoldás abban rejlik, hogy az e-mail azonosításhoz használhatod az elsődleges e-mail címed és az e-mailes userid-det is.

A két jelszó pedig biztosan megegyezik, ahogyan a userid is. Ha megváltoztatod az e-mailes vagy a DSL-es passot, rögtön tapasztalhatod. :)

Na, a helyzet a következő.

Az T-Online biztos küldött tájékoztatót, de azokat nem mi kapjuk, hanem az ügyfelünk. Ott meg gondolom ment a devnull-ra és ráadásul csütörtök estig nem is jelentkezett a probléma, az üzletmenetük meg már évek óta beállt a mostani állapotra, szóval még hirtelen mail mennyiség növekedésről sem lehet beszélni (egylébként a logok szerint is igazat mondanak).

Elvileg nem nagy levelezők, napi 40-60 levél lehet a kimenő forgalom.

Azért van dinamikus adsl-ük, mert "CSAK" és ne szóljunk bele, erre fizettek elő X évvel ezelőtt és kész.

A postfixnek beállítottam az adsl-es login/pass-t, de a mail.axelero.hu nem autentikálja be (a logban egy szó nincs auth kísérletről, csak a hiba üzenet van, hogy túlléptük a kvótát), a mail.t-online.hu -ra meg "Authentication failed: cannot SASL authenticate to server mail.t-online.hu[84.2.46.3]: no mechanism available" hibát kapok.

Most a franc tudja, mi van.

Na, ez a valasz aztan ott van a szeren... Az
smtp_sasl_security_options =
benne van a postfix main.cf-jeben? Innentol illene mukodnie a mezei plain es login auth-nak is (SSL nelkul alapbol ezeket nem hasznalja a postfix), legalabbis ha a libsasl2-modules is fel van rakva (debianban ez a csomag neve)

Ez (http://www.postfix.org/SASL_README.html) alapján dolgoztam, de maradt a "no mechanism available" üzenet.

Ez most a konfig:

main.cf:


   relayhost=mail.t-online.hu
   smtp_sasl_auth_enable = yes
   smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
   smtp_sasl_security_options = noanonymous

/etc/postfix/sasl_passwd:


   mail.t-online.hu  usernev kukac axelero.hu:jelszo
(ez az adls-es login/pass, a levelezes masik szolgaltatonal van, axeleros mail login/pass-rol nincs tudomasom)

postmap /etc/postfix/sasl_passwd
postfix reload

Próbáltam volna még a main.cf-be bevenni a


   smtp_sasl_mechanism_filter = plain, login

sort, de a 2.1.5-ös Postfix ezt még nem ismeri.

----- szerk -----

wildy! igazad volt.

Elég a


   smtp_sasl_security_options =

nem kell neki paraméter. Suxxx.

Így most már csak 'sima' auth failed-et kapok, vagyis rossz a login/pass. Azon meg már elvileg lehet segíteni hétfőn.

A jó szakember holtig tanul. Te most megtanultál pár dolgot, amit olyan emberként alapvető fontosságú tudnod, aki másnak üzemeltet bérbe informatikai megoldásokat.

Ezek között van, hogy mikor szerződést köttök, elkérsz minden olyan papírt, amely a munkavégzésedhez szükséges, hogy azt ne később, hosszú napokig kelljen keresgélni, mikor adott esetben sürgősen szükség lenne rá.

Öt évig jártam cégekhez (most már csak telefonon beszélgetünk :), de ezt nagyon hamar megtanultam. Te még az elején lehetsz. >;-)

"És ha vmit változtattak, miért nem szóltak?"

Csupán elméleti kérdés: a fenti esetben kinek kellett volna szólniuk? Illetve hogyan? Hiszen mint írod az e-mailjüket sem olvassák (mindkét értelemben, azt a mailboxot sem, amit megkapnak, meg azt sem, amit a DSL hozzáférésükhöz kaptak).

Te milyen értesítési formát tartanál jónak? Weblapot, amit nem néznének, faxot minden változásról, amit kidobnának? Tényleg érdekelne, hogy szerinted mi ebben az esetben a hatékony ügyfélkommunikáció menete.

Esetleg téged, mint kapcsolattartót le kellett volna jelenteniük? Vagy mint üzemeltetéssel megbízott cég neked kellene olvasnod a nem használt mailboxot? :)

A hupot, ahová a panaszodat írod megfelelőnek tartanád erre a célra? Ezt csak azért kérdem, mert mint Zahy is írta, jópárszor kitárgyaltuk már, hogy 2005. májusa (lassan két éve) óta a mail.axelero.hu-t nem célszerű használni, valószínűleg ezévben meg fog szűnni.

A hupot sem olvasod? :)

--- Értesítés: Teljesen igazad van, nem egyszerű a kérdés.

--- mail.axelero.hu: eleinte próbáltunk róla lemászni, de a mail.t-online.hu -val gondjaink voltak (nem értük el, vagy nem fogadott tőlünk levelet, vagy nem akart relay-ezni, már a fene tudja). Aztán el is feledkeztem róla, amikor meg eszembe jutott, azt hittem, hogy majd egy DNS aliassal átirányítják a mail.axelero.hu -t a mail.t-online.hu -ra és minden megy tovább mint eddig.

--- hup olvasás: write-only user vagyok.

Nem érted el: több emberrel (nem hívnám rendszergazdának őket, ha nem gond) találkoztam már, akik itt-ott panaszkodtak, hogy hol megy, hol nem. Aztán kiderült, hogy a nagy eszükkel bedrótozták az egyik IP címét a csomagszűrőjükbe, aztán nem vették észre, hogy kettő lett. Elképesztő, hogy az általános problémamegoldás mennyire nem megy ezeknek az embereknek. A héten (ismét) találkoztam egy olyan esettel, ahol valami ultragagyi ""tűzfal"" (wildy kedvéért két idézőjelben :) szokás szerint béna SMTP "fuxup" megoldásával nem volt kompatibilis az Outlook, amire egyébként a Microsoft oldalain is több KB van, azt részletezve, hogy mi a probléma és hogy kell kikerülni (tűzfalban ennek a feature-nek a letiltásával, vagy SSL használatával. Sajnos a TLS-t ugyanúgy elkeféli.).
Nem akart relayezni: ahogy fent elnéztem (és mert már ilyen emberek is kértek tanácsot) valahogy nehezen megy az embereknek az MTA-jukba (leginkább postfixről hallok) SMTP authot varázsolni, pedig tele van leírásokkal az internet. Javaslom a hupwikibe mindenki szedje össze az általa favorizált beállítási módját, hogy később legyen mire hivatkozni RTFM-mel. :)

WO: sajnálom, a te bajod, de akkor ne is várj megoldást, mert úgysem fogod látni. ;)

Erre válaszként: http://hup.hu/node/35719
A fél napot nem kommentálom, más is ennyit, vagy még többet szív vele (számomra érthetetlen miért, talán érdemes lenne Venemának írni, hogy egyszerűsítsen a dolgon).

Nem értem, hogy az, hogy a te szervered a dróton hogy küldi a jelszót hol számít abban az esetben, ha amögött megkattan egy gép. Sehol. A jelszólopásra sincs hatással egyébként, ha van energiád még a postfix tanulásához és bekonfigurálod a TLS/SSL-t is.

Az openrelay-t sem teljesen értem, a mail.axelero.hu sem volt az, a mail.t-online.hu sem az. Ha mégis, akkor annak a kliensei tették azzá, amelyek esetében teljesen mindegy, hogy IP alapján, vagy userid/jelszóval kerülnek beengedésre.
Üzemeltetésből élsz, csodálkozom, hogy ezeket magyarázni kell.

Az, hogy autentikálnod kell egy smarthostra azzal az előnnyel jár a szolgáltatónak, hogy könnyebben nyomonkövethető, hogy ki küldte a levelet, több esélye van rá, hogy szankciókat léptessen életbe, ha erre szükség van.
Ha végiggondolod, ugyanezt megcsinálni többféle access user esetén (DSL, dialup, KTV, mikro, wifi, sorolhatnám), a forrás IP címből bár nem lehetetlen (mint ahogy a mail.axelero.hu-n is per user kvóta van), de nem is olyan könnyű.

Ha szerény véleményed szerint "lájtos", írd meg te hogy csinálnád, mivel akadályoznád meg, hogy azok a "rendszergazdák", akiknek még nem megy olyan jól a google használata, hogy megtalálják, hogy kell beállítani a levelezőjüket, vagy csak simán a PC-s zombi enduserek ne tegyék használhatatlanná az adott mailszervert.
Engem érdekelne és annak ellenére, hogy eddig miket írtál nem tartom kizártnak, hogy valami olyat tudsz, amire a világ nagyrészén SMTP szervereket üzemeltető ISP-sek még nem. :)

Ne tartsd magadban, írd meg a tutit.

mail.t-online.hu el nem érése: annyira azért nem vagyok láma, hogy bedrótoztam volna az IP címét. A postfix log nyüszített mindenfélét, de mondom, már nem emléxem, régen volt.

[...] valahogy nehezen megy az embereknek az MTA-jukba (leginkább postfixről hallok) SMTP authot varázsolni [...]

Igaz, de ki van/volt itt rászoktatva ilyesmire? Senki....

A fél napot nem kommentálom, [...] talán érdemes lenne Venemának írni, hogy egyszerűsítsen a dolgon).

A fél nap nem a postfix-re vonatkozott, hanem arra, hogy nem tudtam, hogy a T-Online policy-t váltott. Ez fullra az én hibám/bajom és kommunikációs hiba eredménye (köztünk meg az üzemeltetett cég között).

Nem értem, hogy az, hogy [...] ha amögött megkattan egy gép.

Úgy értettem, hogy ha vmi spam küldő szart telepít vmelyik jóképességű user és a progi megtalálja a céges smtp szervert (miért is ne tenné), onnantól rákattan és rátesz 6 köbméter levelet, az meg küldi a T-Online felé tök szabályosan és ez ellen nem véd az, hogy az én smtp szerveremnek autentikálnia kell a T-Online-hoz. Tényleg, utána kellene néznem, hogy outlook-ban (OE, MSO) van-e smtp auth...

Az openrelay-t sem teljesen értem, a mail.axelero.hu sem volt az........

'95-'98 között a saját szolgáltatóm elég szaros smtp szervere helyett az axelero-sat (matávosat?) használtam és talán még ez után is 1-2 évig.

Üzemeltetésből élsz, csodálkozom, hogy ezeket magyarázni kell.

No flame plíz....

Ha szerény véleményed szerint "lájtos", írd meg te hogy csinálnád [...]
Ne tartsd magadban, írd meg a tutit.

Értem az iróniát, csak most nincs hozzá hangulatom. A 'lájtos' jelző visszavonva, csak most perpill ezek olyan szigorításoknak tűnnek, amiktől nem lesz biztosan jobb a világ, bár a jóság foka talán kicsit nő.

Igen, azellen valóban nem véd, ha a te szervereden keresztül küldik a szart (illetve ez sem igaz, próbálj csak meg sok spamet küldeni, egy idő után a mail.t-online.hu sem áll veled szóba). Pontosabban annyit biztosan, hogy innentől kezdve könnyebben fog veled a cég szerződést bontani az ÁSZF alapján. Nem kell az IP címeket kibogarászni, egyértelműen ott van, hogy te küldted (pontosabban a te accountoddal, ami a te felelősséged).

De, a világ kicsit jobb lesz. Bár az valóban igaz, hogy ennyi nem elég a boldogsághoz, ahhoz több kell. Viszont minden szigorításnak az az alapja, hogy tudj valakivel szigorú lenni, azaz tudnod kell, ki küldte a levelet.

Ha van jó ötleted, arra tényleg kíváncsi vagyok.

Ez a tema sajnos jo ideig orokzold marad :( Amikor egy kisebb ISP-nel dolgoztam, en is mindenfele eszkozokkel probalkoztam elerni, hogy az ugyfelkor ne SPAM-elje szet az SMTP szerverunket. Elobb-utobb mindig beleutkoztem par ugyfel negativ hozzaallasaba "nekem ne mondja meg a szolgaltato, mit hogy csinaljak, en jobban ertek hozza, mint o". En amugy a belso halozaton kifejezetten megkovetelnem az authentikaciot, emellett azt is beallitanam, melyik user milyen levelcimrol kuldhet levelet - mondjuk ezt nehez lesz kulsoskent atverni a cegen, de egy probat meger.

Meg micsoda meló ezt adminisztrálni egy nagyobb cégnél, ahol esetleg már jönnek-mennek is az emberek.

Szvsz a legjobb (és egyben legerőforrás igényesebb) az lenne, ha mindenkinek lenne digitális aláírása és az összes smtp szerver csak digitálisan aláírt leveleket továbbítana, amiket persze küldés közben ellenőriznének is. B-))))

Ja, sajna sokszor az az erzese az embernek, hogy a Cisco tanfolyamokon is betanitott munkasokat kepeznek. Egy proxy tuzfalon meg csak-csak belefer, ha az ICMP-vel jatszanak (azert az ECN-nel lehet ott is jokat szivni), de az IP forward-os mokaknal szivas, bar pl. a linux kernel egesz jol kezeli az ICMP-t mint RELATED state. Mind1, a kerdesedre valaszolva BalaBit->Morgan Stanley, de azert meg mindig Zorp-rajongo vagyok :)

smtp.t-online.hu :)

--
deejayy DOT hu