SMTP szerver nem fogad 25-os porton kapcsolatot

Hálózatok általános

Nem flame, csak erdeklodok. Adott egy SMTP server, ami hirlevelet kuld. Nem fogadjuk a hirlevelet (postfix, reject_unverified_sender), mint kiderult, a hirlevelkuldo szerveren nincs engedelyezve a 25-os port...
Nem tudom, csak nekem tunik ez arconrugasnak? Vagy teljesen normalis dolog, csak en meg nem lattam ilyet?
Meg egyszer, nem flame, nem kell lehordani a fejem (izgalmas, hoyg ezt a hupon ki kell hangsulyoznom), csak velemenyeket varok.

  • 2795 megtekintés

( zeller | 2012. 03. 07., sze – 16:41 )

Miért kéne a küldő gépen nyitva lennie a tcp/25-nek? Attól, hogy valaki levelet _küld_ fogadnia még nem kell. A küldő e-mail címhez (mail from, illedelmes esetben data utáni "From:" sor) kell lenni működőképes MX-nek, és ott kell a tcp/25-ön SMTP-ül beszélő szoftvernek figyelnie.

Keresztkérdés: A DATA utáni "Reply-To: Valaszcim " úgy nézem, kimarad a vizsgálatból, meg akkor sem műx, ha a DATA utánmondja azt a túloldal, hogy nem megy, de szimplán ki is tilthat a túloldal, etc, etc...

Kézzel ellenőrizve az adott "mail from: foo@bar.baz" -hoz tartozó MX-et, mi történik?

Arra godolok, hogy a mail from rossz, de a "Reply To:" jó, működő címet tartalmaz.Tudom, mail from rcpt to alapján döntünk, a DATA után bármi jön, az mesedélutánra jó, abban bízni nem kell - de csak az alapján, hogy a mail from ellenörzésével gebac van, még nem dobnám el a levelet.

Van olyan, ahol az rcpt to után már döntés van, és a DATA-t meg sem várja az MTA, hanem előtte dob egy hibaüzenetet, és van olyan, ahol a ".\r\n" után dobja vissza a levelet. Mindkettőre van példa, és mindkettőt illik kezelni a küldő oldalon. (rcpt to után nyasgemre nem kezdeni betolni a DATA-t, egyáltalábn megvárni, hogy az rcpt to-ra válaszoljon a szerver, etc...)

Hat, par eve uzemeltetek otthon (ismerkedesi jelleggel) postfixet. 3-4 eve, mikor a cegnel is atalltunk postfixre es nemcsak spamszurot hasznaltunk, hanem a postfix UCE-t is, otthon is belottem. Meg kell mondjam, kb. 95%-al esett a spamek szama (nyilvan benne van az unknown_domain_reject es hasonlo is, nemcsak a sender visszaellenorzes). Elotte evben 12000 spam jott, utana evben csak 500 korul. De ez a sajat otthoni szerverem, egy domainnel, 3-4 userrel, arra kiserletet sem tettem, hogy a ceges SMTP servert is megvizsgaljam ilyen szempontbol :)

--
http://www.micros~1

az address verification-al konkrétan az az egy probléma van, hogy a "mail from" azt hazudik amit akar. Ha egy valós címet hazudik a levél, akkor már át is ment a teszten. Ráadásul relative sok erőforrást igényel az ellenörzés.
Vannak ennél hatékonyabb módszerek is (szerintem).

Lehet, en csak azt tudom, amit latok, ott pedig roppant hasznosnak tunik. Nyilvan ki lehet cselezni - kerdes, ha arra nem kepes, hogy letezo domaint allitson be, akkor mennyire fog foglalkozni a mail from hamisitassal. Eroforrasigenyet nem tudom, desktopkent is hasznalom a gepem, de nem tunt fel, hoyg a postfix nagyon enne barmit is (cpu/mem/halozat/stb).

Ettol meg persze konnyen lehet, hoyg igazad van, ezek csak sajat "erzes alapjan" tapasztalatok, merest nem vegeztem.

--
http://www.micros~1

Ha szolgáltatsz, akkor ez a check szerintem nem opció, mert végeláthatatlan harcot fogsz vívni az ügyfelekkel a random közösségi siteok és szolgáltatók mailküldési praktikái miatt. A tendencia alig észrevehetően elbillen abba az irányba, hogy létező mailcímekről küldenek levelet, de erre szerintem még egy jó öt évig nem építhetsz. Hasznosnak egyébként meg nem hasznos a check, mert rengeteg olyan spam van, ami a címzett címéről jön, azt meg ellenőrizheted, úgyis létezni fog. Inkább a bayes szűrő betanítására találj ki valami jó megoldást, ahol én vagyok, ott már alig lő mellé.