Hirdetés

2024. április 19., péntek

Gyorskeresés

Útvonal

Fórumok  »  Egyéb hardverek  »  [Re:] Beazonosítható spammerek (téma lezárva)

Hozzászólások

(#1) hf


hf
csendes tag

Érti valaki hogy ez hogy működik? Ha nem azzal a szolgáltatóval csatlakozok, akié az email cím akkor más smtp-ről küldöm a levelet. Ilyenkor hogy megy ez?

(#2) X-COM


X-COM
nagyúr

tökmindegy honnan csatlakozól

ha valaki feladó@akármi.com címmel küld levelet, akkor leellenőrzik, hogy az akármi.com mailserverén van e ilyen felhasználó, ha nincs akkor szemét

Blog:http://ikszkom.freeblog.hu RSS:http://ikszkom.freeblog.hu/rss.xml http://live.xbox.com/member/ikszkom

(#3) L3zl13 válasza X-COM (#2) üzenetére


L3zl13
nagyúr

Meg gondolom azt, hogy az adott IP cím amiről a levél jön valóban az akármi.com-e.

Aki hülye, haljon meg!

(#4) hf válasza X-COM (#2) üzenetére


hf
csendes tag

Ha úgy működik ahogy X-COM mondja akkor teljesen OK. De amit L3zl13 mond azt nem értem mert az IP akkor az smtp szerveré ami nem egyezik a mailboxot tároló szerverrel. Vagy nem?

(#5) dabadab válasza hf (#1) üzenetére


dabadab
titán

Ez nem a ''From:'' e-mail mezorol szol, hanem a ''MAIL FROM:'' SMTP kulcsszorol (ezt az opcionalis ''Sender:'' e-mail mezo tartalmazza) - a ketto eleg sok esetben egybeesik, egy csomo mas esetben viszont nem (pl az altalad emlitett esetben, v levlistaknal, ahol a ''From:'' az uzenet irojat, a ''MAIL FROM'' viszont mar a levlista cimet tartalmazza)

Egyeb info:
[L]http://spf.pobox.com/faq.html[/L]

DRM is theft

(#6) dabadab válasza X-COM (#2) üzenetére


dabadab
titán

Ne keverj :) Felhasznalo nevet nem ellenoriznek, ez csak a DNS rekord kiegeszitese, es arrol van szo, hogy azt ellenorzik, hogy az a gep, amelyik a levelet kuldi, kuldhet-e emailt az illeto domain neveben (ami NEM a ''From:'' mezot jelenti)

DRM is theft

(#7) Bgs


Bgs
senior tag

Ez az egesz meg az RBL rendszernel is rosszabb!!!

Mi csinal az a felhasznalo aki tobb szolgaltatohoz is belep (pl. laptopos). Mit csinal az aki tobb domain-ben is rendelkezik email cimmel ?

Elterjedt SMTP AUTH-tal megoldhato, viszont ha ez adott akkor a SPAM problema is megoldott lenne...

Mar megint a becsuletes felhasznalokat akarjak szivatni :((

Bgs Kek modolt farmer, SMP bicska, spam taszito ing, integralt karora, personal firewall gatya, antisztatikus zokni, 5 sec alatt rebootolhato cipo.

(#8) dabadab válasza Bgs (#7) üzenetére


dabadab
titán

Gondolom direkt nem olvastad el a tiedet megelozo ket postot, hogy haboroghassal egy jot ;)

Egyebkent az RBL-lel sincs semmi gond, csak esszel kell hasznalni, pl defaultban spamassasinban a SORBS 0.1, a spamcop.net meg 1.5 spam-pontot er (5 ponttol lesz ''valoszinuleg spam'', 15-tol meg ''majdnem biztosan spam'').

Az AUTH nem tunik jobbnak (ha jol sikerult legreppelnem a lenyeget az RFC-bol), mert a clientet bekonfigolni eleg bonyinak tunik (aztan utana meg barmelyik worm lenyulja a szukseges cuccokat)

DRM is theft

(#9) Bgs válasza dabadab (#8) üzenetére


Bgs
senior tag

Nagyon tevedsz, direkt elolvastam az osszeset.

A rendszer bajahoz semmi koze a From: es az envelop sender kozotti kulonbsegnek.

1) A levelezo kliensek a sajat e-mail cimet szoktak megadni envelop sender-nek, tehat a becsuletes felhsznalo eseteben a ketto megegyezik, tehat gaz van.

2) Ha pedig csinalnak egy uj levelezo klienst amiben az uj szabvany erdekeben meg lehet adni, hogy milyen cimet hasznaljon envelop sender-nek akkor abbol lehet gond, hogy pl. mas ceg neve IS szerepel a levelben. Vegyuk pl. egy egyszeri rendszergazda esetet, aki tobb cegnek is dolgozik. Ha az egyik neveben akar levelet kuldeni, akkor lehet, hogy nem jo otlet ha a masik cegnek is ott vannak a nyomai a levelben, meg akkor is, ha nem feltuno.

Az RBL-lel az a gond, hogy a szerverek tobbsege binaris szinten hasznalja es visszadobja az adatbazisban levo IP cimeket. Ez pl. egy dinamikus IP cimu ADSL kapcsolatnal nagyon idegesito tud lenni.

Az AUTH lehet megoldas, ha SSL-lel egyutt hasznaljak. A kliensek bekonfigolasa pedig altalaban annyibol all, hogy beikszeled a ''Use authentication'' vagy hasonlo nevu opciot. Ha meg az SSL-re conatkozo opciot is beikszeled akkor meg jelszot sem fognak lopkodni.

Bgs Kek modolt farmer, SMP bicska, spam taszito ing, integralt karora, personal firewall gatya, antisztatikus zokni, 5 sec alatt rebootolhato cipo.

(#10) dabadab válasza Bgs (#9) üzenetére


dabadab
titán

1) A levelezo kliensek a sajat e-mail cimet szoktak megadni envelop sender-nek, tehat a becsuletes felhsznalo eseteben a ketto megegyezik, tehat gaz van.

Nem tudom, eddig en azt lattam, hogy az envelope korrekt szokott lenni.


2) Ha pedig csinalnak egy uj levelezo klienst amiben az uj szabvany erdekeben meg lehet adni, hogy milyen cimet hasznaljon envelop sender-nek akkor abbol lehet gond, hogy pl. mas ceg neve IS szerepel a levelben.

Ez nem lehet gond, mivel a Received: mezokben amugy is ott van a masik ceg neve.

Az AUTH-ot meg nem teljesen fogom: nem ugy mukodik, hogy van vmi key, es azzal csinalnak vmi challenge/response dolgot? (Hadd ne kelljen mar vegignyalaznom az RFC-t :) )


[Szerkesztve]

DRM is theft

(#11) Bgs válasza dabadab (#10) üzenetére


Bgs
senior tag

1) Nem a korrektsegrol van itt szo, hanem a tartalomrol. Egy rendes kliensben, normal level kuldes eseten a From: es az envelope sender azonos. Tehat ha tobb fiokod is van, tobb szolgaltatonal, akkor az uj rendszerben nem tudsz levelet kuldeni a fiokjaid egy reszerol.

2) A Received: mezoben miert van ott a masik ceg ? A Received:-ben a cimzett(ek) dolgai vannak.

AUTH: Az auth csak alapvetoen ez amit a neve is takar: autentikalast. Ez lehet akar plaintext is, mint a pop3-nal. A kulcsos dolog akkor kell, ha speci autentikalast akarsz hasznalni. (Es ezt a szerver es a kliens is tamogatja). Az SSL-nel van meg kulcs, de azt az Outlook kivetelevel minden kliens automatikusan kezeli, a felhasznalonak csak el kell fogadnia, mint megbizhato adatot.

Bgs Kek modolt farmer, SMP bicska, spam taszito ing, integralt karora, personal firewall gatya, antisztatikus zokni, 5 sec alatt rebootolhato cipo.

Útvonal

Fórumok  »  Egyéb hardverek  »  [Re:] Beazonosítható spammerek (téma lezárva)
Copyright © 2000-2024 PROHARDVER Informatikai Kft.