Mail kuldes felulbiralasa

Linux-haladó

Sziasztok!

Szeretnem a tanacsotokat kerni, hogy szerintetek milyen megoldas letezik az alabbi feladatra, vagy milyen nyomon lenne erdemes elindulnom!

A feladat tehat: van egy x felhasznalos helyi halozat akik szeretnenek levelezni. Viszont itt jon a problemam, a levelek ellenorzes nelkul nem kerulhetnek ki a halozatbol, igyhat szukseg lenen egy szolgaltatasra aminek segitsegevel belel lehetne pillantani a level tartalmaba/csatolmanyaba, mindezt webes feluleten ahol engedelyezni/tiltani lehetne a levelek kezbesiteset, mindezt ugy, hogy a level kuldojenek szemelye valtozatlan maradjon.

Valaszokat elore is koszonom!
Udv

  • 1278 megtekintés

( efbijn | 2008. 06. 30., h – 21:06 )

Ilyet szerintem tilos csinálni.

@@
"You can hide a semi truck in 300 lines of C."
Debian Lenny 2.6.26-rc2-mm1

( congo v | 2008. 06. 30., h – 21:17 )

Gyakorlatilag az e-mailt egy workflow részeként át akarod futtatni egy approval folyamaton. Hirtelen egy levelezőszerverbe épített content filter modul jutott eszembe, de sokkal egyszerűbb ha a felhasználók eleve weben írják meg a levelet, és nem kerül a levelezőszerverre amíg jóvá nem hagyod.

( arpi_esp v | 2008. 06. 30., h – 23:35 )

elsore az ugrott be, hogy fox egy postfixet, tobb queue-val. a bejovo levelek bekerulnek az egyik queue-ba. heggesztesz ra egy webes feluletet, ami kilistazza a queue-t, es ha approvolsz egy levelet, az atkerul a masik queue-ba, ahonnan a postfix mar elkuldi. gyakorlatilag a postqueue parancs hivogatasaval (a webes cgi-bol) megoldhato minden.

de a dolog megoldhato contentfilterrel is, ilyenkor a filter rakja le kulon fileokba a (kivulrol jovo) leveleket, es approvolaskor ezek ujra elkuldesre (de mar loclahostrol, igy nem megy ra megint a filter) kerulnek. ilyenkor az envelope sender/recipient tarolasat is meg kell oldanod (erre jo lehet pl sql is), kulonben gond lehet a felado/cimzettel (bcc: stb)

A'rpi

eszembe jutott. content filterrel beküldi a postfix a rendszerbe, majd a levelet berakja egy queue-ba. a rendszerből már nem kell újraküldeni, csak szólni a megfelelő hostnak, hogy queue-olja tovább a levelet. így erőforrás-barát és skálázható is. már csak valami azonosítót kell találni amivel össze lehet kapcsolni a queueban a levelet azzal, amit a content filter kapott. :)

vagy kihagyjuk a content filtert, az smtp hostokon egyszerűen pollolod a megfelelő queue-t (erre biztos van jobb megoldás) és amikor újat találsz, lekommunikálod a jóváhagyó adatbázis felé. annak semmit nem kell tudni gyakorlatilag csak egy host/id párost (meg ami metadata kell még a jóváhagyáshoz). Ha nem csak metadata kell akkor talán érdemesebb betolni valami imap folderbe, jóval egyszerűbb hozzá akármilyen felületet hegeszteni mint queue fájlból nekiállni MIME contentet kiszedni/megjeleníteni. Akár azt is meg lehet csinálni, hogy ha levelezőből behúzzák az 'approved', 'rejected', 'ávh' stb mappákba akkor megtörténjen a dolog (kell valami saját id header), ez is 100% skálázható csak több lehallgatótisztet kell beültetni.

ide valaszolok mindkettotoknek. szoval szamomra ezt a queue+content filter dolgot kisse bonyolultnak talalom, reszben mert nemtudom hogyan mukodnek ezek es mikent tudnam ezt webes feluletrol basztatni.viszont talaltam egy haszanlhatonak igerkezo cuccot, dbmail a neve es sqlben tarolja a leveleket ami nagy segitseg a felulethez. mar csak az a kerdes, hogy a jovahagyast, hogy lehet vele megoldani. (meg nem telepitettem fel)
viszont milyen szavakra erdemes rakeresni, mert a legnagyobb problemam az, hogy nemtudom minek nevezik ezt a folyamatot angolul. erre valami otlet?

( tamsa | 2008. 07. 01., k – 10:37 )

Nem lenne egyszerűbb, minden levelet letárolni és utólag ellenőrizni( gyanú esetén), mint minden kimenő levelet egyenként ellenőrizni?

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

Kéremkapcsojjaki! (a mailszervert) :-))

Ha ki _akar_ juttatni információt, méghozzá e-mailben, akkor ki fogja juttatni (hint: steganográfia). Ennek persze jóval kisebb az esélye, mint annak, hogy valaki szándékosan vagy véletlenül egy belső doksit kiküldjön :)

A megoldással egy gondom azért van: A "jóváhagyó" szerepkörrel kik fognak rendelkezni? Az általuk a levelezésbe bevitt késleltetés (ebédel, megbeszél, házon kívül/betegen/szabadságon van, stb.) és bizonytalanság üzleti folyamatokra gyakorolt hatását valaki végiggondolta? Mekkora a levélforgalom? A jóváhagyó szerepkör mekkora időráfordítást igényel, ez mennyibe kerül? Mennyi idő eldönteni egy levélről (belép a jóváhagyó felületre, kiválaszt, elolvas, dönt, enged/visszadob, kilép), hogy mehet vagy sem? Hogyan lesz ez szabályozva? (Mit csinál pl. az általa ismeretlen nyelven íródott, elektronikus aláírással ellátott/titkosított levéllel?)

Az e-mail csak egy szelet a tortabol, mindenrol tudnunk kell ami a halozaton kivulre iranyulo forgalom, csak egyes oldalakat engedelyezhetunk stbstb. Az fogja ellenorizi akit oda ultet a vezetoseg es az altaluk bevitt kesleltetes fogja oket a legkevesbe erdekelni ha millios karokat elozhetnek ezzel meg, masreszt pedig az lesz a feladatuk hogy a leveleket elelnorizzek es nem az hogy mellete rendszergazdak meg php koderek legyenek.Elore lathatolag nem lesz nagy level forgalom mert az ott dolgozoknak nem kapcsolat tartas lesz a feladatuk. Mivel egy epuletben lesznek, maximum odamegy es megkerdezi/megkeri, hogy mutassa meg a levelet az eredeti formajaban, vagy tiltja. Ennek eldontese es az egyebb altalad leirtak ENGEM NEM ERINTENEK, az a feladatom, hogy legyen egy ilyen mukodo rendszer, nem annak kitalalasa, hogy ki mit mikor es milyen mertekben fog csinalni.

( sany | 2008. 07. 01., k – 12:07 )

" A "jóváhagyó" szerepkörrel kik fognak rendelkezni?"

Az ipari kémek.
Ők tudják mit keressenek. :D