webgalamb hosting

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

Az egyik ügyfelünknek olyan (remek) ötlete támadt, hogy hírleveleket küldözgetne az ügyfeleinek, azok közül is szigorúan azoknak, akik feliratkoznak rá. (Ez eddig sima ötlet: legyünk mi is spammerek, csak támogatni tudom, de ez teljesen mindegy)

Ami viszont fontosabb, hogy az ügyfél webgalambot szeretne. Írtam levelet a kapcsolat [kukac] webgalamb [pont] hu -nak, de ennyi nekem nem elég.

Valahogy 2012 - 2013 körül üzemeltettem ilyet, de akkor csak a gond volt vele, ami azóta remélem elmúlt (5 év nagy idő)

Szóval aki üzemeltet(ett) ilyen csodát az árulja már el nekem, hogy:

  • Szereti-e ez a php-fpm -et (vagy fcgid -t)?
  • Fut-e Docker konténerben?
  • Rate limit -et hogy oldottad meg
  • Lehet-e az admin felületet külön domainre és vhost confra rakni?
  • Mi a helyzet a erőforrás igénnyel / performanciával?
  • Egyéb amire érdemes oda figyelni?

Ha ezeket, akár csak tipp, vagy ötlet szintjén megválaszoljátok sokat segítetek...

( andrej_ v | 2017. 02. 06., h – 19:51 )

Ez egyáltalán nem spam, ha olyannak küld hírlevelet aki kérte kifejezetten az hírlevél. Én is több hírlevélre vagyok feliratkozva, rendszeresen kapok hasznos infókat, még akkor is ha épp nem élek velük. Ha hosting ügyfél tömeges mailezik, akkor szintén elég szigorúan ezt elvárjuk tőle.

A webgalambosok vállalnak telepítést, sőt ingyen felrakják és egész ügyesek emlékeim szerint. A PHP-FPM-et simán eszi, a dockert egyáltalán nem eröltetném, illetve a különdomaines dolog se létkérdés.

A ratelimitre saját exim szabályom van, minden vhostra vonatkozik és mindenki csak autholt smtp-vel küldhet. Ez egyébként egy sql insert és egy cronjob ami a tábla alapján 5 percenként fut és az elmúlt 60 percben küldött mailek alapján korlátoz ha szükséges.

A webgalamb a mailek közötti szünettel oldja meg a ratelimitet, szépen kiszór akár sokezer levelet is így. Ami fontos, hogy állítsátok be a visszapattanók automatikus kezelését.

Egyszerűen az accept -nél van egy continue = ${lookup mysql{INSERT INTO mailstat.... jellegű sor, van egy cronjob ami egy flaget átállít ha adott darabnál továbbmegy és van egy deny rule még az accept előtt, ami a flag alapján adott esetben visszadobja a levelet egy "quota reached" hibával.

Ez inkább megtört oldal elleni intézkedés, a hírleveles (double optin ugye, nem csak vakvilágos spammer) emberekkel egészen jól lehet kommunikálni erről. Ha túlságos megszór egy nagy szolgáltatót az úgyis korlátoz vagy rossz esetben kitilt, tehát semmiképp se mennek el hamarabb a mailje. Azt az akadályt is jól veszik, hogy hiába látja hogy az alkalmazás kiküldte, attól még a szerver ugyanúgy sok órát vagy napot görcsöl a maileken.

( sj | 2017. 02. 06., h – 20:00 )

ha a 'reformancia' az performanciat jelent, es valoban double opt-in feliratkozokrol van szo, akkor nem lehet gond a teljesitmennyel max. 1-2000 email eseten...

( janoszen v | 2017. 02. 06., h – 20:02 )

Sztem ha az ugyfel sokkal boldogabb lesz pl. Sendyvel, mert az tamogat Amazon SES-t. Ez azert fontos, mert ezzel csomo olyan bounce handling ficsort kap meg, amit IMAP-os vagy egyeb felolvasasnal eleg nehez megvalositani. Ha erdekel, tudok teszt accountot adni.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Az a helyzet, hogy az Amazon itt szóba sem jön, a webgalambot ők választották, viszont a bounce kezelésre még valóban fel kell hívnom a figyelmüket.

Beszéltek / írtak ról, nagyjából tisztában vannak a fontosságával.

----
올드보이

Nyilván!

A probléma akkor kezdődik, amikor egy adott DMZ -ben van a megrendelő mail servere és egy másikban meg lesz a webgalamb. A kettő között tűzfalak tömkelege...

Tehát jöjjön vissza a galambba a bounce (és kezeljem azt, hogy a levelet megkapó ügyfél, válaszol a levélre), vagy engedjem be a tűzfalakon (ami annyira nem tűnik komfortosnak), vagy maradjon a manuális bounce kezelés, aminek meg a megrendelő nem fog örülni.

----
올드보이

( szilard_ v | 2017. 02. 07., k – 20:56 )

Én is vettem Webgalambot, és hozzá évi nettó 12e-t tárhelyet náluk.
Ezt leveleztem velük, ezt írták ha ők üzemeltetik:

Kifejezetten a Webgalamb futtatására alkalmas tárhelyet (nem jár hozzá FTP, saját domain, e-mailcím) tudunk adni a szoftver használatához, amelyhez nem szükséges domain név. Éves díja 12.000,Ft+áfa, amiben havi 10.000 db e-mail kiküldése van benne.
Az előfizetett csomagban foglalt havi e-mail küldési mennyiség túllépése esetén a többletként kiküldött elektronikus levelek esetében 10fillér + áfa/e-mail díjat számít fel a kollégám, amit a következő hónap elején számláz ki a Felhasználó részére. Fel nem
használt e-mail küldési kvóta nem vihető át a következő hónapra!

Azért mondtam az ügyfélnek, hogy inkább béreljen, mert ha kitiltják a céges levelező IP címét a hírlevelek miatt, az nagyobb szívás.

mert ha kitiltják a céges levelező IP címét a hírlevelek miatt

kiemeltem, hogy konnyebben eszrevedd az ellentmondast: hirlevel miatt nem szoktak kitiltani. Spammeles miatt annal inkabb. Az meg az ilyen esetek pikanteriaja, hogy az 'ugyfelek' szerint ez hirlevel, a cimzettek szerint meg lepra spam...

Értem amit mondasz. Ami a tartalmi része volt, hogy a hírlevélküldést és a céges levelezést ne egy IP-ről bonyolítsuk. Szerintem.

Van rá példa, hogy nagy mennyiségű levelet (UPC-t megkérdeztem, amikor a cég kereste a megoldást ÁSZF 2.3.8) nem fog kiengedni a szolgáltató, és ha a cég levelezője és a hírlevélküldő egyazon IP-n van, akkor baj lehet.

Azt is értem, hogy hírlevél =/= SPAM, de négy éve probléma mentesen kimenő hírleveleinket a freemail úgy cseszte ki és rakott listára, hogy három hét volt visszalapátolni a lóba a citromot. És tudom, hogy most már mást használ, de az akkori rendszert használta más szolgáltató is.