Brīdī, kad Google bezmaksas e-pasti domēniem beidza savu pastāvēšanu (Google solītais mūžīgi ienāca 2022. gada vidū), bija jāsāk meklēt jauns e-pastu serveris ar mazākām izmaksām un lielāku kontroli. Reiz, kad Google Gmail e-pasti saviem domēniem bija bez maksas, biju saveidojis daudz e-pastus. Tagad tiem jāmeklē jaunas virtuālās mājas.
Šis ir vairāk tehnisks raksts par e-pastiem
Satura rādītājs
- E-pasts 200+ domēniem
- Veidot savu e-pastu serveri un pakalpojumu
- Iepriekšējā pieredze
- Jauni rīki, zināšanas un Docker
- Virtualizējamie e-pastu risinājumi
- Kopsavikums
E-pasts 200+ domēniem
Ja sākotnēji savu serveri nemaz nevēlējos veidot izmaksu un uzturēšanas dēļ, jo man bija ap 200+ domēniem, tad pat 1 dolārs/eiro par katru e-pasta kastīti būtu bijis daudz. Viens variants bija samazināt e-pastu skaitu, ko arī izdarīju, otrs – mēģināt pašam veidot e-pastu serveri.
Tuvākais maksas e-pasta variants, ko atradu bija Zoho Mail. Bet, pat pie samazinātā e-pasta skaita, izmaksas bija palielas, ņemot vērā, ka liela daļa no projektiem īsti nenes naudu un ir paredzēti dažādām mācībām un eksperimentiem, kur svarīgi bija derīgs e-pasts, kas piesaistīts lapai (domēnam).
2022. gada 1. jūnijs un Google Workplace
Ja nebūtu bezmaksas e-pastu pieejamība domēniem no Google, visticamāk, veidotu tos visus apzinīgāk, bet 2008. gadā tas nebija aktuāli, jo nebija jāmaksā un nezināju, ka tik ilgi nodarbošos ar web veidošanu. Bažas gan radās 2012. gadā, kad jaunus e-pastus vairs nevarēja izveidot, tomēr 2022. gada 1. jūnijs ir diena, kas visiem Google Workplace domēniem piesaistītie e-pasti kļūs maksas – 6 ASV dolāri par pasta kastīti. Tātad, 1. jūnijs tuvojas.
Veidot savu e-pastu serveri un pakalpojumu
Šo biju dažas reizes iepriekš jaudarījis, bet nekad nopietni un ilglaicīgi, jo uz Google bija pieejami vairāki tūkstoši bezmaksas e-pasta adreses jau pie esošajiem domēniem. Google Gmail varēja izveidot līdz ~2000 e-pastu vienam domēnam, ja pareiz atceros un skatoties pēc tā, cik biju pieteicis, reģistrējot domēnus e-pastiem. Tik daudz nevienam domēnam nebija, bet bija, kur n-padsmit bija izveidoti. Tiesa daļa kā arhivārie e-pasti.
Iepriekšējā pieredze
Pirmie mēģinājumi sākās ap 2019. gadu, kad sāku pētīt iespējas veidot e-pastu automatizācijas, lai nosūtītu rēķinus vai reģsitrācijas datus projektos. Arī maksas pieejamie transakcionālie e-pasti, jau bija izsmelti, kad vēl maksāt nebija jēgas, bet limitus jau pamazām sāku sasniegt.
Mandrill un Mailgun
Viss sākās ar MandrillApp e-pastiem. Tajā laikā vēl bezmaksas. Vēlāk tas kļuva maksas un to nopirka Mailchimp, kur tas tika integrēts kā papildus iespēja e-pastiem. Šis risinājums kalpoja gadiem, līdz arī kļuva maksas pakalpojums, bet ienākumi nebija tādi, lai atmaksātos un bija vienkārši hobiju lapām un eksperimentiem.
Pēc kāda laika, pievienoju arī Mailgun. Tas bija gandrīz 1:1 ar MandrillApp un tika izmantots ilgu laiku, kā aizvietotājs, kad Mandrill kļuva par maksas pakalpojumu.
Amazon Simple Email Service (SES)
Kad jau parādījās kaut kāda nauda, tika izskatīti arī vairāki maksas pakalpojumi, kur vajadzību izpētē un cenas pieejamības ziņā Amazon SES (daļa no Amazon AWS) kļuva par optimālo variantu. Arī šis variants darbojās diezgan ilgi, kad izsūtīju klientiem MediaBox.lv rēķinus caur manu TEAM.HOUSE. Iepriekšējā pieredze strādājot ar MandrillApp un Mailgun bija noderīga un aplikācijās vajadzēja pievienot tikai jaunu iespēju un/vai moduli. No programmēšanas viedokļa tas bija vienkārši, jo mainījās tikai daži parametri starp MandrillApp, Mailgun un Amazon SAS risinājumu.
Patiesībā kādu brīdi tie visi 3 darbojās paralēli, lai noskaidrotu, kurš labāk noderēs aplikācijām.
Elasticemail, Mailerlite, Sendgrid, Postmark,…
Kādā brīdi tika izmantoti arī Elasticemail, Mailerlite, Sendgrid, Postmark, Mailjet un vēl daudzi citi risinājumi. Visticamāk, arī šobrīd veidojot aplikācijas šie būtu pirmie kandidāti e-pasta nodrošināšanai tieši programmēšanas iespēju dēļ (automatizācija un API).
Nākamais rindā ir Cloudflare piedāvātais e-pasta risinājums, tikai jāatrod pareiza aplikācija, kurai to pielietot.
Jauni rīki, zināšanas un Docker
Un tomēr… Bija vēlme izpētīt ar kļūdu un iespēju palīdzību šo pakalpojumu “līdz kodolam”. Tik dziļi, varbūt ne, bet pietiekami, lai saprastu kā izveidot pašam vai vismaz kā tas strādā.
Es cenšos visu laiku papildināt savas zināšanas kā programmētās un izstrādātājs. Tas nozīmē daudz eksperimentēt, kļūdīties un atklāt jaunus risinājumus. Kā jau nojaušams, lasot līdz šai vietai, tad ekeperimentēšana ne vienmēr ir finansiāli izdevīga, vēl jo vairāk peļņu nesoša, toties pieredze un zināšanas ir neatsveramas. Sākotnēji tās nejūt un nevar apzināt.
Ar laiku pamani, ka tā vietā, lai meklētu Google risinājumu, viss, kas nepieciešams ir tikai laiks, lai izstrādātu un uzprogrammētu risinājumu pašam.
Docker un Docker Compose
Tā nonācu pie Docker mācīšanās. Te liels paldies Ronaldam, ar ko esmu dažos hakatonos piedalījies, par ievadu virtualizācijas tehnoloģijās un jau ar paraugu – WordPress mājas lapu. Ronalds visu par simbolisku $$ parādīju un … es par to aizmirsu, jo nebija laika un bija citas prioritātes. Tad es aizgāju no darba. Bija daži mēneši laika, lai virtualizācijai un automatizācijai pieķertos nopietnāk. Arī meklējot darbu, noteikti tas būtu biji bonuss. Bija.
Un pēc kāda laika nonākam pie tā, ka e-pastu serverus (un mājas lapas, un web aplikācijas) lieku tikai virtualizētā veidā – Docker + Docker Compose.
Virtualizējamie e-pastu risinājumi
Neslēpšu, šis process vēl turpinās un raksts ar laiku var tikt papildināts ar jauniem risinājumiem.
Pēc tam, kad Docker kļuva par manu ikdienu un pietiekamā limenī, lai būtu noderīgi, sāku skatīties virtualizēto e-pastu serveru risinājumu virzienos. Vai vismaz skriptētu.
Zemāk aprakstītajiem e-pastu kastīšu vienīgais ierobežojums ir servera vietas daudzums un veiktspēja.
Aprakstītajiem e-pastu risinājumiem:
- tika izdalīts savs virtuālais serveris (VPS) un “auksta” IP adrese;
- MX ieraksti vienkāršība – viens serveris tikai (pagaidām).
- DMARC, SPF un citi ieraksti ļoti labi darbojas un mēstuļu (spam) kastē iekrita tikai dēļ “aukstās” IP adreses un svaigā e-pasta pakalpojuma servera domēna;
- administrācijas panelis e-pastu domēniem un pasta kastītēm;
- iebūvēti antispama (mēstuļu filtrēšana) pakalpojumi;
- vienkārša migrācija no esošā e-pasta hostinga;
Abos gadījumos jāņem vērā, ka visa uzturēšana ir Tavās rokās – ja kaut kas neiet, tev jāmeklē risinājums kļūdām.
Mail in a Box
Mail-in-a-Box nav virtualizēts, bet “uzliec un aizmirsti”. Vismaz es tā domāju, kad pirms diviem gadiem to uzliku kā pirmo izmēģinājuma e-pastu. Diemžēl, pie vienas atjaunošanas kaut kas galīgi nogāja neatgriezeniski greizi. Lai arī kļūdas atjaunošanā radās, e-pasti joprojām darbojas vairākus mēnešus. Tikai to administrēšana ir neiespējama.
Uzliekot šo pašu Mail-in-a-Box uz jauna servera un jaunāku versiju, viss darbojās labi. Lai arī bija būtiska kļūda, mazām lapām un web aplikācijām šo variantu izvēlētos joprojām.
Mail-in-a-Box priekšrocības bija:
- ļoti vienkārša piesaiste pie domēna;
- domēna ieraksti viegli saprotami un uzstādāmi;
- automātiska konfigurēšanās Thunderbird un citās datora e-pastu programmās, ja tā ie iestatīta domēnam;
Mail-in-a-Box izmaksas ir 5 ASV dolāri mēnesī + ikgadējā domēna maksa.
Dīvainības
Dīvainā kārtā viens no e-pastu domeniem nedarbojās HKG.APP, kurš kaut kā ne visus e-pastus saņēma nedz arī nosūtīja – bloķēti vai iekrīt mēstulēs. Ļoti maz e-pasti nonāca līdz adresātiem arī pēc “uzsildītas” IP adreses. Parunājoties ar citiem, nonācām pie secinājuma, ka kaut kur kādam nepatīk Honkongas saīsinājums domēnā. Tā ir mūsu sazvērestības teorija. Lietojot to pašu kodu uz tā paša servera, pamainot domēnu viss darbojās. Visi domēnu ieraksti 1:1. Šo teoriju nav sanācis iztestēt uz cita risinājuma, izmantojot HKG.APP domēnu.
Mailu
Pavisam nesen tiku iepazīstināts ar Mailu. Mailu jau ir virtualizēts Docker e-pasta pakalpojums, ko var izvietot uz sava servera. Mailu pagaidām ir aktīvā eksperimentā un pagaidām izskatās kā kandidāts uz palikšanu. Jāsagaida tikai atjaunošanas process, lai nesanāk kā ar Mail-in-a-Box.
Mailu priekšrocības bija:
- vienkāršota uzstādīšanas konfigurācija, kas viņiem ir speciālā mājas lapā: setup.mailu.io;
- Docker un vistualizācija nozīmē, ka var horizontāli paplašināt un sadalīt slodzi uz vairākiem serveriem (ar Kubernetes). Tik tālu vēl neesmu ticis, bet… gan jau arī tur nonākšu;
- e-pastu domēnu pārvalde salīdzinoši vienkārša, bet Mail-in-a-Box patika labāk;
Raksta tapšanas brīdī uz Mailu tiek uzturēti ap 50 domēnu e-pastiem pēc pamatīgas optimizācijas. Un tas viss par 10 ASV dolāriem mēnesī.
Kopsavikums
Gala variants tiek vēl meklēts, bet pagadām šie divi varianti bija vispiemērotākie web aplikācijām no aptuveno 20+ izpētītām programmām. Žēl, ka Google e-pasts nav kā atdalīts pakalpojums domēniem un maksātu mazāk. No otras puses tas ļāva iemācīties daudz ko par e-pastu pakalpojumu uzturēšanu un horizontālo paplašināšanu pakalpojumam.
Esošās izmaksas un veiktspēja ir pietiekama, lai kādu laiku nesatrauktos. Ja man tagad būtu jāiesaka e-pasta risinājums
- daudziem e-pastiem, ko pašam uzturēt – Mailu,
- ja tikai vienam domēnam – Google Workplace vai Zoho Mail. Padārgi, bet nav jādomā.
- Ja vairākiem e-pastiem, bet nepārzini Docker – “Mail in a Box”, jo draudzīga pamācība.