Céges belső levelező tervezése

Web, mail, IRC, IM, hálózatok

Adott egy cég (legyen Cég Kft.) egyetlen info@ceg.hu email címmel.
Jelenleg a levelező szolgáltatótól lekérjük a leveleket, belső "házi" szerveren tároljuk, levelező szolgáltatótól meg kitöröljük, mert napi szinten a dokumentáció, csatolmány orbitális mennyiséget tesz ki, több 100 MB per nap. Ezt lokálisan bedobjuk a közösbe, ahol DOVECOT végez helyi munkát, s ebből a fiókból dolgozik mindenki. Küldeni is ezen keresztül küldenek kifelé, ami a szolgáltató smtp-jén viszi tovább a POSTFIX.
Tehát ilyen "pop3 leszívós, helyi imap-os, helyi smtp-relay" szerű dolgot alakítottam ki, és szuperül megy minden jópár éve.
A helyi gépnek van domain neve is, teljesen más, mint a cégnév (legyen hisztis.hu).
Kívülről-belülről a hisztis.hu-n lehet hozzáférni a belső levelezéshez. Ez is kafa.

Tovább szeretnénk ezt bonyolítani:
szeretnénk további belső virtuális emaileket létrehozni - ember1@ ember2@... @ceg.hu - megtörtént, fiók működik
szeretnénk, ha ezen további emberek info@ceg.hu-ként küldenének levelet kifelé - megtörtént, működik a smtp_generic_maps = hash:/etc/postfix/generic beállításával
szeretnénk, ha az info@ tudna a virtuális emberXY@-nak bent levelet küldeni - ez még nem megy. Talán "myhostname, mydestination, mydomain + aliases" körül lesz a beállítás, ugye? Valahogy fel kell keltsem ezt a LocalDeliveryAgent-et?

  • 1847 megtekintés

( ggallo | 2019. 06. 23., v – 08:36 )

Hát erre nagyon kíváncsi vagyok, ebből mi sül ki, úgyhogy sub.

P.s.: a megoldást nem tudom, sohase próbáltam egyetlen e-mail címen ki-be fűzni egy teljes cég levelezését. Mintha NAT-olnál, csak nem IP címmekel/portokkal, hanem e-mail címekkel...

Ez sztem SIEVE-vel simán megoldható, sőt nálunk ez az alapmegoldás olyankor, amikor közös (csoportos) mail címeket akarunk használni. A csoportos e-mail cím egy nem létező user, ami hibás üzenetként egy központi elosztó fiókba kerül, ahol a címzett szerint osztja szét a szűrő. Ennek a következménye, hogy ha egy levélnek több címzettje kell legyen, akkor a gyűjtő e-mail címre elküldött levél csak egy helyen tárolódik, a közös mappában, amely minden felhasználónak elérhető. TB-ben simán definiálható identity-ként ez a közös cím, és akkor akinek kedve szottyan, innen küldhet üzenetet (miközben ez a cím nem is létező user).

Az indítóban leírt megvalósítást egyébként nem értem, fölöslegesnek látszik az egész egy jól beállított saját IMAP szerveren + OwnCloud szerű valami https://alternativeto.net/software/owncloud/?platform=self-hosted sztem mindent tud, ami elvárás. A külső szolgáltató és a POP letöltés innentől meg teljesen fölösleges.

( kallaics | 2019. 06. 23., v – 08:54 )

Erre szerintem nem biztos,hogy a Postfix a legmegfelelőbb megoldás. Gondolok itt a több 100 MB-os csatolmányokra és a "belső levelezésre".

A nagy csatolmányok helyett tennék fel egy OwnCloud-ot (Seafile etc.) és mindent rendszerezetten oda kéne tárolni. Így nem csak gépről,de mobilról is elérhető

A "belső levelezésre" ott a RocketChat például, ami Slackhez hasonló self hosted megoldás.

A belső levelezésre azt szoktam mondani, hogy nem dokumentumtár és nem ott kell tárolni az árajánlatokat és egyéb hasonló céges dolgokat. Utóbbira vannak elég jó megoldások szintén.

Az, hogy mindenki egy e-mail címről küldjön levelet is megfordítanám, hogy legyenek szerepkörök (info,sales etc.), mint alias és azok legyenek személyes postafiókokba továbbítva. Az alias felvehető egy-egy személyes postafiókhoz és van lehetőség úgy küldeni a kliensről levelet, hogy az alias lesz a feladó.

ÉN a mai technológiák mellett ebbe az irányba mennék.

( zolo | 2019. 06. 23., v – 11:49 )


szeretnénk, ha az info@ tudna a virtuális emberXY@-nak bent levelet küldeni

marmint, ha kivulrol jon egy level az infora azt belulre xyp@localdomain-ra szortirozni? Es milyen szuro alapjan akarod szetvalogatni?

Nem igazan ertem ezt az egesz katyvaszt sem. Marmint minek?! Nem egyszerubb vagy sajat levelzoszervert uzemeltetni (mar ugy is van) vagy egy webhostingot emailekkel, manager felulettel kezelni es a hivatalos doksikat meg kotelezoen lementi a munkavallalo a megfelelo local storagera?

Nem kell kívülről küldeni emberXY@ -ra, csak belülről kellene majd egymás között üzengetni.

Külső hosting-ban nem bízik a vezetés, semmit sem adna ki a kezéből, régimódi. Bízik a helyi vasban.
Az egészet már rég GoogleApps-ra tettük volna...

Amúgy ez így, ahogy van, tökéletesen működött idáig!

( zeller | 2019. 06. 23., v – 12:52 )

Száz milibit, azaz egytized bit nem sok, mindhatni semmi... :-D

Zeller épp ezért írta nekem. De már javítva. Nos, magam sem szeretem a pontatlanságot, de nem akadok fenn ilyeneken, hacsak nem valami írtó fontos adat az, vagy félreérthetőségre adna okot a cikkben / szövegben a dolog. És sem zellert nem bántani akarom, sem magamat ignorálni, de amikor például valaki ékezet nélkül írt (sok éve itt is dívik), olvashatatlanul, azon talán első 10-20 ízben fennakadtam, de nem szóltam, aztán mára már megszokta a szemem (mondanám: tanulunk így is olvasni, legalább), de a témaszálat nem szoktam megbontani, s "melléfröcsögni". ((A helyesírásról, a helyes tagolásról, mondatvégi jelekről meg már rég ne is beszéljünk, ugye, magyarok, magyar nyelv(h)űek?!) Úgyhogy kérlek titeket, ezen most gördüljünk tovább, s ha segíteni tudtok inkább, azt megköszönöm!! :) [mosoly]

Erre gondolsz?
https://hu.wikipedia.org/wiki/SI_m%C3%A9rt%C3%A9kegys%C3%A9grendszer
https://hu.wikipedia.org/wiki/Byte

"A byte többszöröseit kifejező szorzók tekintetében értelmezési zavart okoz, hogy e területen is az SI mértékegységrendszerben használatos előtagokat alkalmazták a byte többszöröseinek kifejezésére, viszont az SI-től eltérően ugyanezen előtagok más szorzót fejeznek, vagy fejezhetnek ki, az alkalmazási területtől függően. A háttértárak kapacitásának és a hálózat sebességének meghatározásakor ugyanaz az egység más méretet jelent (tíz hatványai), mint például a memória méretének meghatározásakor (kettő hatványai).[2][3] Ezt az ellentmondást hivatott feloldani az IEC kiegészítése, amely új mértékegységeket rendelt a bináris szorzókhoz. Az új elnevezések használata a szakmában a kiadást követő években nehezen terjedt. "

https://hu.wikipedia.org/wiki/Bin%C3%A1ris_prefixum#A_hat%C3%A1lyos_el%…

Tehát a KiB, MiB, GiB, TiB mást jelent mint a kB, MB, GB stb.

( Proci85 v | 2019. 06. 25., k – 15:15 )

Igazából ha rákeresel a "postfix virtual users" kifejezésre, kb bármelyik megoldáson végigmész, jó lesz neked szerintem. Az, hogy te az egyiket virtuális usernek hívod, az info-t meg nem, az csak zavaró. Ha nem UNIX user, akkor mindegyik virtuális user, tehát az összes (info + "virtuális" usert) be kell vágni egy virtual_mailbox táblába (ez lehet sql vagy fájl szintű), és azzal etetni a postfixet, dovecotot.

( tigrincs | 2019. 06. 25., k – 15:36 )

Ha amugy is ti uzemeltetitek a levelezest akkor minek szarakodni virtualis domainnel/emailekkel?

Mitol feltek mi lesz a userrel ha lesz neki egy tenyleg letezo email cime?

Ha az a valasz ,hogy hat ne kuldjon vele levelet akkor mondjuk be kene korlatozni, hogy csak domainen belul tudjon kuldeni/fogadni

Kivulrol meg maradhatna a szuper alias (bar ezt se igazan ertem miert nem lehet mondjuk a szerepkoroknek sajat mail fiokja ami kivulrol cimezheto)