ugrás a tartalomhoz

Email rendszer jó API-val

inf · 2012. Aug. 28. (K), 11.54
Szép napot!

Egyik oldalra szeretnék feltenni egy olyan rendszert, ami felhasználó létrehozáskor létrehoz egy email címet is, törléskor törli, felhasználói csoportokhoz is tud email címet létrehozni, stb...
Tudtok ajánlani ilyen rendszert?

(Az ideális az lenne, ha json, xml vagy soap lenne a kommunikációs forma... A még ideálisabb meg az, ha lennének kész HTML űrlapok, amiket csak integrálni kéne a rendszerünkbe...)
 
1

Linux?

Poetro · 2012. Aug. 28. (K), 12.03
Linux alatt ez elég egyszerűen működik. Amikor létrehozol egy felhasználót, akkor ha a levelezőrendszer úgy van beállítva, akkor létrejön hozzá egy email fiók is. Bár lehet, hogy félreértettem a kérdést.
3

Linux egyébként a rendszer,

inf · 2012. Aug. 28. (K), 13.03
Linux egyébként a rendszer, azon van egy weblap nodejs-el, és amikor azon létrehoz az admin egy felhasználót, akkor szeretném, ha automatikusan egy email fiók is létrejönne neki, illetve a felhasználók csoportokba tehetőek, és a csoportoknak is szeretnék közös email címeket, amihez bármelyik csoportban lévő felhasználó hozzáférhet...

Nyilván ezt egy API-val a legegyszerűbb megoldani.
5

Létrehozás

Poetro · 2012. Aug. 28. (K), 13.41
Linuxos parancsok hívásával létre tudsz hozni felhasználókat (useradd), azokhoz jelszavakat, valamint email címet is rendelhetsz, és mindezt úgy, hogy a szerverre nem fog tudni belépni. Ekkor akár csoportokhoz is hozzárendelheted a felhasználót, sőt akár egyszerre több csoporthoz.
11

A felhasználók ezen kívül még

inf · 2012. Aug. 28. (K), 14.32
A felhasználók ezen kívül még ezer dolgot csinálnak az oldalon, nem kifejezetten email szolgáltatást szeretnék csinálni, az csak egy mellékes funkció...
2

PHP

hunkris · 2012. Aug. 28. (K), 12.46
Tudom, hogy nem ezt kérted, de a PHP tökéletes erre, IMAP vagy POP kiegészítéssel.

Egyébként, ha éppen nincs kedved kódot írni, akkor vannak "gagyi" kódot generáló űrlapcsináló weblapok.
4

Köszi, de kizárt, hogy én még

inf · 2012. Aug. 28. (K), 13.04
Köszi, de kizárt, hogy én még egyszer PHP-hez nyúljak, zsigeri undorom van tőle. Valami java-ban írt befordított dologra gondoltam, aminek van egy jó API-ja, és mondjuk SOAP-pal kommunikál, vagy esetleg JSON-nal, ami a nodejs-nek fájntos lenne... Esetleg nodejs-ben írt rendszerre, de arra most rá is keresek, hogy van e...
6

Java?

hunkris · 2012. Aug. 28. (K), 14.02
Ez most vicc?

A Javának alapból nincs helye a weben.
7

PHP

Hidvégi Gábor · 2012. Aug. 28. (K), 14.05
Pont annyi van, mint a PHP-nak. Mindenki használjon azt, ami tetszik neki, és mondom ezt úgy, hogy én sem szeretem a Javát, de ha egy feladatot meg lehet vele oldani jól, akkor miért ne?
8

Indoklás?

Poetro · 2012. Aug. 28. (K), 14.12
Ezt megtámogatnád valami indoklással? Tudtommal elég sok pénz van Java-ban fejlesztett webalkalmazásokban, és elég jól is működnek.
10

Gondolom ő a java-t csak

inf · 2012. Aug. 28. (K), 14.27
Gondolom ő a java-t csak appletekből ismeri, mint általában a php-sek.
12

Nem, nem csak appletekből

hunkris · 2012. Aug. 28. (K), 15.53
amik az okostelefonokon vannak. Láttam már sok Java programot, de a legtöbb nekem lassú, folyton becrashel (bika géppel, tuningolva). Abból, ahogy ti beszéltek róla, azt szűrtem le, hogy nektek nem.
13

web

Poetro · 2012. Aug. 28. (K), 15.58
És ezek közül melyik volt webalkalmazás? Mármint ami szerveren futott és weboldalt vagy más webes szolgáltatást szolgált ki? Azt például tudtad, hogy az összes natív Androidos alkalmazást Java-ban fejlesztik?
14

Volt pár. Már rég letettem

hunkris · 2012. Aug. 28. (K), 16.00
Volt pár. Már rég letettem róluk, szóval most nem jut eszembe egy sem.
Amúgy tudtam. Ezért nem vettem eddig okostelefont se.
15

Hát pl netbeans is java-ban

inf · 2012. Aug. 28. (K), 16.18
Hát pl netbeans is java-ban íródott, liligo mögött is java van, és akkor csak két ismert alkalmazást írtam, de a banki rendszerek jó része is abban van, ahogy a mobil hálózatoké is.
16

Szomorú

Poetro · 2012. Aug. 28. (K), 16.23
Hát az igen szomorú, hogy konkrét indokot nem tudsz az állításod mögé sorakoztatni. Gondolom a LinkedIn, AOL, Bank of America, UPS, Netflix, AT&T, IWIW stb. túl kicsi oldalakat üzemeltetnek szerinted, és lassúak, használhatatlanok stb.
18

Sebesség

Hidvégi Gábor · 2012. Aug. 28. (K), 17.09
Úgy, hogy nem tudjuk, milyen hardver van a felsorolt szolgáltatások mögött, nehéz megítélni, hogy milyen a sebessége a Javának. Azok alapján, amit eddig láttam (apeh nyomtatványkitöltő, mobilos cuccok), én is azt mondom, hogy a Java alkalmazások lassúak és rendkívül erőforrásigényesek egy natív programhoz képest (egyébként pedig nem hiszem, hogy a PHP-nél sokkal lassabb vagy gyorsabb lenne). Persze nem véletlen, hogy a fenti cégek ezt választották, de az sem, hogy mások pedig nem : )
19

Java-hoz nagyon komoly tudás

inf · 2012. Aug. 28. (K), 18.13
Java-hoz nagyon komoly tudás kell, amit meg kell fizetni. Ez az egyetlen ellenérv.
Én csak kívülről látok bele, mert nem fejlesztek benne, nem is szívesen hasonlítanám php-hoz, de ha már előkerült van java-nak nagyon sok előnye, amik közül néhánnyal szerintem php sosem fog találkozni:
  • vm nyelvére fordul, így gyorsabb, mint a php, mert közelebb van a gépi kódhoz. sokkal több hibalehetőséget kiszűr a fordítója (nem csak azért mert erősen típusos)
  • átgondolt nyelv - nincsenek benne olyan összegányolt dolgok, mint a php hibakezelés, php string függvények összevisszasága, 3 mysql lib, és még lehetne sorolni... egyébként is sokkal több ideje volt kiforrni, mint a php-nak
  • sokkal jobbak a fejlesztőeszközök, mint amik a php-hez vannak (pl hibernate, eclipse, stb...) pont ezért lehet pl asztali alkalmazásokat is fejleszteni benne
  • vannak benne thread-ek
  • nagyon jó megoldásaik vannak nagy terhelésű rendszerek építésére, szerver fürtök, stb..

A php-nek egyedül annyi az előnye, hogy olcsó és viszonylag gyors, ezért szokták mondjuk java web service-ek fölé emelni, és soap-pal kommunikálni vele. Olcsóbb így, mintha a presentation tier-t is java-ban írják meg...

(szerintem nodejs miatt php-nak leáldozóban van, legalábbis nagyon bele kell húzni a fejlesztőcsapatnak, hogy ne haljon ki a nyelv)
21

nodejs vs php? hmm.

Arnold Layne · 2012. Aug. 28. (K), 18.52
(szerintem nodejs miatt php-nak leáldozóban van, legalábbis nagyon bele kell húzni a fejlesztőcsapatnak, hogy ne haljon ki a nyelv)

Az ingyenes tárhelyek és a nagyonolcsó hosztingok miatt nem tartom túl valószínűnek, hogy egyhamar kihal a PHP.
22

9k/évre már lehet nodejs-t

inf · 2012. Aug. 28. (K), 19.11
9k/évre már lehet nodejs-t kapni. (egész elviselhető a sebessége, viszonylag ritkán belassul) na jó nem full hostingot, csak egy instance-ot az amazonon, viszont arra pillanatok alatt fel lehet telepíteni...
23

Adatbázis

Hidvégi Gábor · 2012. Aug. 28. (K), 20.01
Amíg nincsen benne az elterjedt adatbázismotorokhoz natív elérés, addig nem alternatíva.
24

Van

Poetro · 2012. Aug. 28. (K), 20.18
Melyik elterjedt adatbázismotorhoz nem találtál?

MySQL:
https://github.com/Sannis/node-mysql-libmysqlclient
https://github.com/sidorares/nodejs-mysql-native
https://github.com/mariano/node-db-mysql

Postgres
https://github.com/brianc/node-postgres

SQLite
https://github.com/developmentseed/node-sqlite3
25

Valóban

Hidvégi Gábor · 2012. Aug. 28. (K), 20.37
A Postgres linkjét néztem korábban, de az src könyvtár elkerülte a figyelmemet. Így viszont nem értem, mi van a lib-ben.
26

Én most mongodb-t tolom,

inf · 2012. Aug. 28. (K), 20.41
Én most mongodb-t tolom, kíváncsi vagyok mennyiben más a relációs szemlélethez képest...
27

All examples will work with

Poetro · 2012. Aug. 28. (K), 20.43
All examples will work with the pure javascript bindings (currently default) or the libpq native (c/c++) bindings (currently in beta)

To use native libpq bindings replace require('pg') with require('pg').native.

Ebből azt szűröm én le, hogy van natív és JS alapú kapcsolódási lehetőség is.
28

beta

Hidvégi Gábor · 2012. Aug. 28. (K), 21.25
libpq native (c/c++) bindings (currently in beta)
azért erre nem biztos, hogy építenék

Egyébként pedig ha meglesz a kritikus tömeg, hisztériaszerűen fog rá átváltani mindenki.
29

Amit eddig láttam, nagyon jó

inf · 2012. Aug. 28. (K), 21.45
Amit eddig láttam, nagyon jó kis cucc ez a nodejs, de én még csak nagyon az elején vagyok... :-) Remélem maradnak a php-nél, nem akarok itt is gányolt programokat javítgatni :D
31

Na-na

Pepita · 2012. Aug. 29. (Sze), 04.04
Azért ne legyen már minden PHP-ben kódoló gányoló!
32

Nem mindegyik az, de nem

inf · 2012. Aug. 29. (Sze), 05.11
Nem mindegyik az, de nem ritkák az olyan melók, amiknél egy "kész" rendszert kell javítani, és az ember csak fogja a fejét...
33

OK, vettem, vétel.

Pepita · 2012. Aug. 29. (Sze), 05.21
Én az általam készített oldalt kifejezetten szeretem "javítani", máséhoz meg lehetőleg nem nyúlok...
30

Kicsit több ellenérv

Pepita · 2012. Aug. 29. (Sze), 03.58
vm nyelvére fordul, így gyorsabb, mint a php, ...
Itt pont a jvm, ami lassú. Azt nem vitatom, hogy PHP-hez képest gyorsabb-e, mert nem tudom. A főiskolán kb. velem egyidős Java-oktatómmal nagyon jókat vitáztunk erőforrás-igényekről, egyebekről, lévén ő megrögzött Java-párti, én meg windows/Delphi-párti. Többször "versenyeztünk", kódolási gyorsaságtól kezdve erőforrás-igényekig, volt teszt bőven. Mindig azzal jött, hogy a windows (xp) milyen erőforrásigényes, én meg azzal, hogy a jvm az. Mindkettő az. Ha desktopra gondolkodunk, akkor a jvm a kihagyható tétel, mert a win 90%-ban ott van.
És ezért nincs - itthon - szélesebb körben elterjedve desktopra a Java, mert a "hétköznapi" gépekhez képest erőmű kell ahhoz, hogy win alatt gyors jvm legyen. Szerveroldalon persze jobb/más a helyzet.
átgondolt nyelv - nincsenek benne olyan összegányolt dolgok, mint a php hibakezelés...
Pontosan így van, csakhogy PHP-ban sokkal könnyebb programozni (kivéve amikor nem :) ), ill. kevesebb tudást igényel (mint írtad is).
sokkal jobbak a fejlesztőeszközök, mint amik a php-hez vannak
Nyilván a Komodo, NetBeans, Eclipse gagyi...

A PHP egy sereg olyan - kifejezetten webes - függvényt/szolgáltatást nyújt, amit a Java - tudtommal - nem, vagy nagyon körülményesen. Ezért (is) könnyebb programozni. Mondjuk Java-val rég nem foglalkoztam semennyit, tehát a mai helyzet akár egész más is lehet, mint sejtem.

Nekem sem nagy kedvencem a PHP (és gyengén típusossága), de a Java sem. Utóbbi inkább nagy projektekhez való, nagy cégeknek, sok lóvéval (~ért). A PHP meg nagyon alkalmas nem túl nagy webes fejlesztésekre - még mindig, és szerintem ez jópár évig meg is marad.

Sokat szidtad már a PHP-t (részben okkal), mégis sajnálom, hogy "végleg szakítottatok".
34

Nyilván a Komodo, NetBeans,

inf · 2012. Aug. 29. (Sze), 05.26
Nyilván a Komodo, NetBeans, Eclipse gagyi...

Én netbeans-t használok php-hoz. Nem rossz, de lehetne jobb is. Pl lassan már halálba kerget, hogy phpdoc-ot kell megadni, ha típust akarok adni bármilyen változónak, ahelyett, hogy mondjuk legördülne egy lista, amiből választhatok típust. Ez legalább az időm negyedét elviszi, amit php fejlesztéssel töltök... Alternatíva nincs, vagy nem működik az automatikus kiegészítés...

A phpstorm-ot ajánlották még, kipróbáltam, de pocsék a kód színezése a netbeans-hez képest. Állítgattam rajta, hogy tűrhető legyen, de még úgy sem volt az igazi... Netbeans-ben a property, a method call és a method declaration mind külön színnel van, itt meg mindnek csak egy színt lehet megadni, ami túlzottan akadályoz a kód átlátásában. A másik gondom vele, hogy nincs olyan, hogy go to declaration, csak az van benne, hogy find usages, amivel így sokkal több időbe telik a deklaráció megtalálása. (Nagyon sokat használom ezt a funkciót netbeans-ben...) A harmadik gondom vele, hogy még ez sem működik rendesen, van olyan, hogy valami miatt elő sem hozza a listát, pedig példányosításnál használtam, nem phpdoc-al megadott típusnál... Persze ezen kívül vannak előnyei, elég stabilnak tűnt, csinál hibakeresést, a tesztek sokkal jobban állíthatóak benne, és még szerintem lehetne sorolni, a fentiek miatt viszont nekem sajnos használhatatlan...

Eclipse-t kipróbáltam annak idején, már az első indításnál elszállt valami hibaüzenettel, azóta nem foglalkoztam vele.

Komodo-nál ahogy nézem ugyanolyan a kódszínezés, mint phpstorm-nál, úgyhogy ki sem próbálom.

Sokat szidtad már a PHP-t (részben okkal), mégis sajnálom, hogy "végleg szakítottatok".

Egy jó IDE-vel meg egy jó keretrendszerrel még szerintem lehet tűrhetően fejleszteni, de mégsem nyújtja azt az élményt a php-amire nekem szükségem van. Sok vele a nyűg, ha OO fejleszt az ember... Én úgy vagyok vele, hogy egy idő után jobb továbblépni, ha a helyzet olyan, hogy nem elégedett vele az ember, és már nem tud javítani rajta. Lehet, hogy a php-t nem nekem találták ki, túlságosan törekszem a tökéletességre... Annyiból jó volt php-zni, hogy utána megtanulja az ember értékelni, ha valami alapból jól működik, és nem kell workaround-ot írni meg hasonlókat. Ezért végülis szerintem megérte. :-)
35

Többnyire igazad is van,

Pepita · 2012. Aug. 29. (Sze), 06.03
mármint a te szemszögedből.
Én netbeans-t használok php-hoz.
Tudom. Én meg Komodo-t, és én elégedett vagyok a kódszínezésével. A kódkiegészítéssel viszont nem - és ezt Netbeans-el sem tudtam elég jól megoldani, így a Komodo-nál maradtam. Ha jól emlékszem, ebben pont te (is) segítettél elég sokat nemrégiben, végül (eddig) nem lett jó megoldás, valószínűleg maga a PHP lesz a hunyó. Ez is egy "nyűg, ha OO fejleszt az ember".
Annyiból jó volt php-zni, hogy utána megtanulja az ember értékelni, ha valami alapból jól működik...
Mondjuk elkezdeni programozni elég gáz lehet egy nem jól működő rendszerben. Szerintem te sem PHP-val vagy js-el kezdted, de javíts ki, ha tévednék. És talán nem is jó gyengén típusos nyelvvel kezdeni, mert utána váltani típusosra sokkal nehezebb, mint fordítva. A PHP-OOP is emiatt nem az igazi, bár ezt már többször kitárgyaltuk...
Még a végén engem is kiábrándítasz belőle...
36

Én js-el kezdtem, aztán

inf · 2012. Aug. 29. (Sze), 07.49
Én js-el kezdtem, aztán php-ra tértem át pár éve. A típusosság egyébként mindkét nyelvnél hiányzik nekem, mert egyszerűbb, mintha minden metódus elejére beteszem a kötelező paraméter típus ellenőrzért... js-ben próbáltam megvalósítani típusos osztályokat, de az volt a gondom vele, hogy ha már megcsinálom, akkor utána egy teljes keretrendszert ráépíthetek, mert a többi keretrendszer nem támogatja...

PHP-ben legalább type hint van, a bemenet típusellenőrzését meg típuskonverzióját meg egy saját osztállyal oldom meg, aminek gyakorlatilag egy config tömböt adok át, a többit meg megcsinálja magától... Így elég tűrhető ez az egész, de mégis jobb, ha mindezt készen kapja az ember, és nem kell magának megírnia...

Nodejs-nél is gondolom lesz bajom a típusellenőrzéssel, de mégis szívesebben használom a js-t, mint a php-t, mert sokkal rugalmasabb, és ha egy adott stílusban akarok kódolni mondjuk automatikus típusellenőrzéssel, akkor akár azt is rá tudom kényszeríteni. Még meglátom, hogy milyen megoldások vannak benne, aztán döntök, hogy hogyan tovább... Amit már biztosan tudok, hogy használni fogok az a fibers. Sokkal átláthatóbbá teszi a kódot... A másik megoldás, hogy singleton-okat csinálok, és azoknak a metódusaik lesznek az eseménykezelők, a lényeg, hogy ezer szint mélységben nem akarok blokkokat... (Egyelőre még nem kezdtem neki a nodejs-es fejlesztésnek, még egy php-s projektet be kell fejeznem, de az max 1-2 nap ...)
37

phpStorm Themes

tiku I tikaszvince · 2012. Aug. 29. (Sze), 09.17
de pocsék a kód színezése
Nézz szét itt: phpStorm Themes

hogy nincs olyan, hogy go to declaration
Ctrl+B vagy Ctrl+Click-et próbáltad? Működik változóra, függvényre, osztálynévre. Az autocomplete lista pedig ugyanúgy működik mint Netbeans-ben. Ha tudja, hogy az adott változó, vagy metódus visszatérési értéke milyen típusú (igen PHPDocból olvassa), akkor tud ajánlani.
38

Ha ezek a témák ugyanazt

inf · 2012. Aug. 29. (Sze), 09.33
Ha ezek a témák ugyanazt tudják, mint amit kézzel is be lehet állítani az IDE-ben, akkor ugyanúgy használhatatlanok.

A menüben néztem a go to declarationt, ott nem találtam sehol, ezért gondoltam, hogy nincs ilyen funkció. Ezek szerint mégis van. Az autocomplete láttam, hogy jó, nem azzal volt gondom, hanem az osztályokat nem találta meg a projektben a find usages-el. Gondolom valamit elrontott az index-elésben, vagy passz.

Közben megnéztem a témákat, ugyanolyanok. Ami a bajom velük, vagy hát az IDE színezőjével, hogy összemossa a tulajdonságokat a metódusokkal és az osztályokkal. Netbeansben a tulajdonságok zöldek, a metódus és osztály deklaráció vastag fekete, a metódus hívás és az osztály példányosítás vékony fekete. Így elég jól meg lehet különböztetni őket, én meg általában ezeket használom, mert oo fejlesztek...
39

Szövegszerkesztők

Hidvégi Gábor · 2012. Aug. 29. (Sze), 09.52
Már annyit vitáztatok azon, hogy melyikőtök szerkesztője hosszabb, hogy illene saját témát nyitni nekik.
41

:D :D :D

inf · 2012. Aug. 29. (Sze), 09.57
:D :D :D
47

Bocsi

Pepita · 2012. Aug. 31. (P), 03.47
Bele szoktunk futni ilyenbe Infernoval, de ez legalább az ő témája. :) (Ja, és az én szerkesztőm vastag is!)
48

:D :D :D

inf · 2012. Aug. 31. (P), 11.41
:D :D :D
9

Én közben találtam egy

inf · 2012. Aug. 28. (K), 14.25
Én közben találtam egy nodejs-ben írt email szervert. A dolog szépséghibája, hogy mivel a neve simple, ezért ilyen finomságok, mint spam szűrés nem hiszem, hogy van benne. Majd még tanulmányozom, hogy mire képes, aztán beszámolok róla.

Ahogy nézem ez csak egy figyelő, ami fájlokra alakítja át a beérkező leveleket... Ehhez még tákolni kell egy html megjelenítős valamit, mondjuk talán ha csinálok egy külön subdomain-t az email-eknek, és iframe-be teszem be őket, abból nem lehet nagy baj. Még kell egy wysiwyg editor, amivel szerkeszteni tudok, és ennyi. (Na meg persze a cross-domain kérésekre szűrés, js szűrés, képek szűrése, stb... nem egyszerű...)

Mondjuk ezen kívül még van kb ezer mail server, ami nem nodejs, úgyhogy lehet valami komolyabb-at választok ehelyett... Körbenéztem kicsit, és nem igazán találni olyan megoldást, ami szűr is. Viszont találtam helyette olyat, ami gmail-t használja fel szűrésre... A másik megoldás, hogy rendelünk egy spam szűrő alkalmazást...

Végül az lett, hogy itt van egy rakat spam szűrő szolgáltatás, meg emellé a nodejs-es SimpleSMTP-t feltesszük. Azért azt, mert egyszerűbb kommunikálni vele, ha nodejs-ben van, mintha más nyelven. A html szűrést viszonylag egyszerűen meg lehet oldani xpath vagy css selectorText-ek segítségével. Haraka-t találtam erre, mint kész megoldást, de még nem néztem meg. Gondolom azért működik, de ha nem, akkor írok sajátot...
40

Bevillant az is, hogy pl egy

inf · 2012. Aug. 29. (Sze), 09.56
Bevillant az is, hogy pl egy Outlook megoldja helyettem a html megjelenítést, szóval ahelyett, hogy az oldalon jelenítem meg a leveleket inkább csinálok egy olyan megoldást, ami levelező klienssel kommunikál... A spam szűrés nem biztos, hogy bekerül a rendszerbe, azon még gondolkodok.
43

Spam szűrés

janoszen · 2012. Aug. 29. (Sze), 19.36
Spam szűrés nélkül eszedbe ne jusson levelező szervert tenni a netre. Meg fogod bánni, ugyanis olyan szinten tele lesz a géped szeméttel, hogy 2 hónap múlva be fogod csukni a szolgáltatást. Nekem egy számottevő levélforgalom nélküli gépen tegnap 2854 próbálkozás volt levélszemét továbbítására.
44

Ok.

inf · 2012. Aug. 29. (Sze), 21.26
Ok.
17

Virtualmin?

Karvaly84 · 2012. Aug. 28. (K), 16.44
Én még nem használtam csak nézegettem a Virtualmin nevű eszközt, amihez van CLI API.
20

Ez érdekesnek tűnik. Jóval

inf · 2012. Aug. 28. (K), 18.19
Ez érdekesnek tűnik. Jóval többet tud, mint ami most nekem kell, majd még nézegetem, hátha fel tudom használni valamire a későbbiekben.
42

Jajjjajjjaj

janoszen · 2012. Aug. 29. (Sze), 19.32
Jujjjj gyerekek, itt azért vannak félreértések. Próbáljuk egy kicsit tisztázni a dolgokat.

Ahhoz hogy leveleket tudj fogadni, kell egy SMTP-t fülelő szerver, másnéven MTA. Ennek az MTA-nak ismernie kell a felhasználóidat. Szerencsére mára már eljutott a technika oda, hogy az MTA-k tudnak un. virtual usereket, tehát nem kell a felhasználókat a Linuxon létrehozni, hanem elég őket egy adatbázisba (mondjuk egy MySQL-be) belerakni. Ilyen MTA például az Exim, amit melegen tudok ajánlani, mert alig-alig van olyan, amire nem tudod rávenni és igen könnyen programozható.

A levelek elolvasásához a felhasználónak szüksége van egy POP3 vagy IMAP elérésre, amit a levelezőprogramjával (vagy éppen a webmailen) el tud érni. Egészen hihetetlen módon ezt megint csak lehet adatbázisból csinálni. Ilyesmit tud például a Dovecot (az egyetlen IMAP szerver, ami normálisan tud szűrőket és kvótázást egyszerre).

Ahhoz, hogy a felhasználó tudjon levelet küldeni, szükséged van egy autentikációval műküdő SMTP szerverre, amire megint csak igen kiváló az Exim.

VISZONT! Én építettem mailszervert és ez minden más, csak nem könnyű. Különös képpen, ha normális spamszűrést akarsz. Szívni fogsz a spamszűrőkön mindenféle túlterheléssel, a felhasználók panaszkodásával, a szarul kódolt levelekkel, a szarul konfigurált, szanaszét a világban levő mailszerverekkel, stb. Ha egy lehetőséged van, akkor erről a tervedről sürgősen tegyél le, mert egész embert kíván és ezzel együtt olyan embert, akinek tapasztalata van a levelezésben. Ha felhánysz egy VirtualMint vagy valami hasonló automágikus cuccot, egyszer csak össze fogja magát szarni a szolgáltatásod és lövésed nem lesz, hogy miért csinálja, hiszen fogalmad nincs, belül hogyan is működik.
45

Valami hasonló

inf · 2012. Aug. 29. (Sze), 21.28
Valami hasonló körvonalazódott bennem is. Jobban megéri fizetni valamelyik szolgáltatónak, vagy gmail-re átirányítani, mint nulláról megírni...
46

Naigen

janoszen · 2012. Aug. 29. (Sze), 22.15
Naigen, de szerinted melyik szolgaltato fogja hagyni, hogy az o feliratkozasi policyjet, robotszuresi taktikait kikerulve Te egyszeruen csak ugy letrehozz egy mailcimet?
49

http://stackoverflow.com/ques

inf · 2012. Aug. 31. (P), 11.47
http://stackoverflow.com/questions/1874786/is-it-possible-to-use-an-amazon-ec2-instance-as-an-email-server

Ettől függetlenül tényleg sokkal nagyobb meló egy ilyet csinálni, mint elsőre gondolná az ember... Jobb fizetni egy már létező szolgáltatónak...