DigitalOceanin virtuaaliserveriin ei saa omaa sähköpostipalvelinta. Mihinkään vakavasti otettavaan virtuaalipalvelinta tarjoavaan palveluun ei saa. Silloin on keksittävä joku toinen ratkaisu. Vaihtoehtoja on käytännössä kolme: webhotelli, Gmail/GSuite ja Amazon SES. Useimmille webhotelli on varmasti järkevin, vaikka sivusto onkin virtuaalipalvelimella. Noin 60 euroa vuosi ja saat niin monta sähköpostiosoitetta kuin jaksat keksiä. Gmail ei maksa mitään, mutta siinä on tiukat lähetysmäärät per päivä ja gmail-osoite syö kaiken uskottavuuden, jos teet yritystoimintaa. G Suite sallii enemmän lähtevää postia ja de facto gmail-osoite saadaan näyttämään domainisi osoitteelta, mutta hinnoittelu on karsea ja per osoite. Amazon SES  yhdistettynä Gmailiin on hyvä G Suiten tyylinen kompromissi, eikä edes kallis. Mutta sen käyttöönotto vaatii hiukan viitseliäisyyttä. Ei se vaikeaa ole, mutta tekemään joutuu.

Laitetaan heti näkyviin yksi mahdollinen rajoitus SES:n käytön suhteen. Jos liikutat tai vastaanotat sähköpostitse tiedostoliitteitä paljon (miksi ihmeessä?), niin webhotellin kautta järjestetty sähköposti saattaa olla järkevämpi ratkaisu. Amazon laskuttaa mm. kilobittien mukaan. Vaikka Gmail mahdollistaa 25 MB liitteet, niin yleinen standardi on, että liitteeb koko on rajoitettu 10 megaan. Tätä noudattaa myös SES. Silloin yhden 10 megan liitteen sisältävän sähköpostin vastaanottaminen maksaisi sinulle liitteen osalta noin 80 senttiä. Se ei ole paljon, mutta jos niitä tulee 10 kappaletta 21 päivänä kuukaudessa, niin puhutaan jo noin 170 eurosta – ja se on paljon. Kannattaa kuitenkin muistaa, että 10 megan liite on iso ja tyypillisesti yhden postin koko lasketaan kiloissa. Amazon laskuttaa koon suhteen 2 senttiä per vastaanotettu täysi 256 kB kakku, joten sähköposteja saa tulla aika paljon, ennen kuin se alkaa aidosti näkyä kuukausilaskussa. Silti se on asia, joka kannattaa pitää mielessä.

Ylipäätään sähköpostin koko kokonaisuudessaan saa olla 30 MB. Se on aika iso sähköposti.

Amazon SES ei ole sähköpostipalvelin siinä mielessä kuin mitä useimmat sen ajattelevat olevan. Sinulla ei ole mitään webmailia mihin mennä tarkistamaan postit ja lähettää sähköpostia. Et voi myöskään käyttää sähköpostiohjelmistoa, kuten Thunderbird tai Outlook, hoitamaan sähköpostejasi (tai voit, mutta siihen tarvitaan yksi palvelu lisää: Amazon Workmail hintaan 4,00 USD/kk/käyttäjä). SES on siten eräällä tavalla uudelleenohjaaja Gmailin (tai muun ”aidon” sähköpostipalvelun) välissä siten, että vastaanottava osoite – se mihin kävijä mailaa – on kuin se olisi domainisi osoite. Tätä asiaa ei voi liikaa painottaa, sillä järjestään asiakkaani, joille SES + gmail on asennettu, kysyvät että missä sitten on osoitteen info@example.com webmaili – no se on siellä missä on osoite oma-osoite@gmail.com. Heidän ei SES:n myötä tarvitsee ostaa erillistä webhotellia saadakseen käyttöönsä vaikka osoitteet info@example.com tai etunimi.sukunimi@example.com.

Jos haluat asentaa Amazon WorkMailin, niin ohjeet löytyvät täältä.

SES sähköpostien lähetykseen

Olen kirjoittanut ohjeet miten Amazon SES otetaan käyttöön lähtevänä sähköpostina, eli SMTP-palvelimena. Vaikka otsikossa on mainittu WordPress, niin se sisältää ohjeet myös serverillä Postfixin säätöön. Lue siitä tarkemmin, sillä on turha tehdä totaalisen identtistä artikkelia.

SES sähköpostin vastaanottamiseen

Jos et ole asentanut SES:iä lähettämään sähköpostia, niin tee se ensimmäisenä. Palaa vasta sitten tänne. Osaksi sen takia, että et tee sähköpostien vastaanotolla mitään, jos et pysty myös lähettämään, mutta siksi, että sinun täytyy todistaa omistavasi käyttämäsi domain – ja ne kannattaa hoitaa lähestyspuolella (ihan vain asioiden helpomman järjestyksen takia, ei muusta syystä). Lisäksi lähettämisen vapauttaminen Amazonin hiekkalaatikosta vie päivän verran.

Kun olet asettanut domainin DNS-tietoihin MX-tietueen osoittamaan SES-palveluun, niin olet periaatteessa valmis ottamaan sähköpostia vastaan. Mutta vain periaatteessa, koska SES ei tiedä mitä saapuvalle sähköpostille tekisi. Tyypilliseen Amazonin tapaan kuvio täytyy rakentaa itse, ja vaikka se saattaa ensi silmäyksillä näyttää vaikealta ja sekavalta, niin ei se ole.

Kaavana (joka ei auta asentamaan, mutta helpottaa ehkä ymmärtämään mitä ja miksi) saapuvalle postille tehdään nämä:

• SES ottaa sähköpostin vastaan
• S3 tallentaa sen
• Lambda selvittää uudelleenohjauksen aitoon email-osoitteesesi
• SES lähettää uudelleenohjattuna saapuneen emailin sinulle

S3 varastoi sähköpostit

SES tarvitsee ohjeet mitä tehdä saapuville sähköposteille. Lyhyesti kuvattuna luodaan sääntö, jossa SES komennetaan tallentamaan saapuvat sähköpostit. Käytettävät tiedostot säilötään Amazonilla aina S3-palveluun, niin tässäkin; email on muodoltaan tiedosto. Joten SES:n haluaman säännön lisäksi luodaan tiedostosäilö, jota Amazonin slangissa kutsutaan nimellä bucket – se on eräänlainen päähakemisto. Molemmat saadaan luotua samalla kertaa – ja kannattaakin, koska bucketille tehdään ikiomat käyttörajoitukset, joten älä käytä olemassaolevaa.

Klikkaa SES:n sivulla vasemmasta valikosta otsikon Email Receiving alta kohtaa Rule Sets. Klikkaa sinistä nappulaa Create a Receipt Rule.

• Jos sinulle kelpaa oletussääntö, että vastaanottaja voi olla vain mikä tahansa hyväksymäsi domainin, mutta ei alidomainin, vastaanottaja, niin sinun ei tarvitse muuttaa mitään. Tämä pätee suurimmalla osalla, koska silloin vastaanottaja saa olla mikä-tahansa@example.com, mikä-tahansa@example.tld jne – kunhan domainit löytyvät verifioituina kohdasta Identity Management > Domains.
• Jos sinulla on useampi domain, mutta sallit vain jostain, niin teet jokaisesta sallitusta säännön laittamalla vastaanottajaksi domainin: example.com. Silloin vain luetellut domainit voivat ottaa sähköpostia vastaan. Itse käytän tätä, koska kaikki domainit saavat lähettää, mutta vastaanottamisessa katiska.info hoitaa sähköpostit perinteisellä tavalla, mutta eksis.one ja eksis.one SES:iä hyödyntämällä.
• Jos haluat hyväksy vain alidomainien osoitteet, niin tee jokaiselle haluamallesi vastaanottaja laittamalla pisteen domainin eteen: .example.com. Silloin vastaanottaja saa olla mikä tahansa malliin mikä-tahansa@ali.example.com, mikä-tahansa@toinen.example.com jne., mutta ei mikä-tahansa@example.com.
• Jos haluat hyväksyä alidomaineista ja domaineista, niin joudut tekemään säännöt molemmille, alidomain pisteellä ja domain ilman pistettä.
• Jos haluat sallia vastaanoton vain määrätylle tai määrätyille osoitteille, niin laita se/ne. Jos sallitaan esimerkiksi info@example.com, niin joku-muu@example.com ei pääse perille.

On hieman makuasia millaisen säännön rakentaa.

Alidomaineja ei minusta kannata koskaan käyttää, koska moinen on oudon näköinen asiakkaalle/lähettäjälle, mutta toki tuokin riippuu tilanteesta. Mutta koska tätä ohjetta luultavasti noudattaa harrastajat, pienet yhteisöt ja yksinää yrittävät, niin alidomaineille ei ole perusteita.

Domainin laittaminen ilman varsinaista osoiteosaa mahdollistaa aivan kaikkien domainille tulevien sähköpostien vastaanottamisen, joten vaikka lähettäjä kirjoittaisi sähköpostiosoitteen väärin, niin se tulee perille. Ja tässä piilee ongelma. Spämmibotit nimittäin arpovat osoitteita ja jos ne menevät AWS:n omasta seulasta läpi, niin ne tulevat sinulle ja sinä maksat.

Sanoisin, että kannattaa asettaa vain muutama osoite, joita todellakin tarvitsee. Varsinkin yksinyrittäjillä on taipumusta käyttää turhan montaa osoitetta, koska kuvittelevat sen antavan jotenkin isomman firman kuvan; kyllä, olen itsekin syyllistynyt tähän. Jos teet henkilönä töitä, tai rakennat henkilöbrändiä, niin aidosti et tarvitse kuin etunimi.sukunimi@example.com. Silti saattaa olla järkevää laittaa myös yritys@example.com, jolloin ei enää tarvita edes jotain info@example.com osoitetta. Sellaisiin posteihin, joita ei valvota, laitetaan usein no-reply@example.com ja jos et salli sitä, niin se palaa lähettäjälle virheenä. Se ei ehkä kuitenkaan ole haluttua, joten ota se myös käyttöön. Kannattaa laittaa myös admin@example.com sillä muu maailma suhtautuu siihen harvinaisissa, mutta määrätyissä tilanteissa (kuten jos hankin maksullisen SSL-sertifikaatin) järjestelmäosoitteena.

Jos sallit domanit, niin vastaanottajalistasi näyttäisi valmiina tämän tapaiselta:

 

Sen sijaan per osoite recipient-lista olisi tämän tyyppinen:

 

Sähköpostiosoitteet ovat valmiiksi Verified, koska olin SES:n lähettävää SMTP-puolta käyttöönottaessani hyväksyttänyt domainit.

Kun olet valmis, niin klikkaa Next Step.

Määritellään mitä SES saapuneille sähköposteille tekee. Siihen tarvitaan sellainen viritys kuin action. Niitä tarvitaan ainakin kaksi: yksi toiminto sähköpostien tallentamiseen ja yksi niiden uudelleenohjaukseen.

Nämä on tehtävä nimenomaan tässä järjestyksessä eli ensin S3 ja sitten Lambda. Järjestys listalla määrää suoritusjärjestyksen.

Aloitetaan tallentamisesta. Valitse alasvetovalikosta <select an action> kohta S3.

• Valitse ensimmäisen kohdan S3 bucket. Voit periaatteessa käyttää jotain olemassa olevaa (jos sinulla sellaisia on) mutta luodaan mieluummin uusi. Osaksi tietysti koska kannattaa pitää omat asiat omissa paikoissaan, mutta lähinnä siksi, että bucketiin laitetaan hieman erilaiset käyttösäännöt, kuin mitä muissa tarvittaisiin. Joten valitse Create S3 bucket.
• Sinulta pyydetään bucketin nimeä. Se saa olla (melkein) mikä tahansa, merkkirajoitukset huomioiden. Suurin rajoite tulee siitä, että sen täytyy olla maailmassa uniikki. Joten keksi nimi, joka on sinulle informatiivinen ja kukaan muu ei käytä sitä.
• Object key prefix on kansio, hakemisto, bucketin sisällä, johon sähköpostit menevät. Laita joku itsellesi merkityksellinen.
• Encrypt Message on mielenkiintoinen kohta. Netin jokainen ohje ohittaa sen. Jos ei laita salausta päälle, niin jokainen tallennettu sähköposti on selväkielinen. Toki S3:n salasana suojaa sen, mutta silti. Tuon pystyy ottamaan myöhemmin käyttöön, joten olkoot tällä kertaa. Muokkaan tätä kohtaa myöhemmin kun minulle on asiasta mielipide. Jätetään tällä hetkellä valitsematta.
• SNS topic liittyy jakamiseen toisille käyttäjille. Jos tiedät, että tarvitset sitä, niin valitse. SNS:n asettamista ei kuitenkaan käsitellä tässä jutussa, koska se on enemmän työryhmien alaa. Joten ei valita sitä.

Klikkaa Next Step

Sinulta pyydetään muutamaa yksityiskohtaa sivulla Rule details.

• Rule name: voi olla mikä vaan, keksi itse
• Rastita ruutu Require TLS
• Jätä muut oletusarvoille

Klikkaa Next Step

Tarkista, että tiedot ovat haluamiasi ja klikkaa Create Rule.

Lambda uudelleenohjaa

Lambda on Amazonin palvelu, joka tekee jotain, mitä en ymmärrä, jotenkin, jota en osaa, Hyvä puoli on siinä, että ei tarvitsekaan. Vaikka seuraava saattaa näyttää kryptiseltä, niin kopypeistausmentaliteetilla mennään.

Avataan ihan ensimmäiseksi Lambdan sivu. Jos menet AWS:n Services -valikon kautta, niin se löytyy otsikon Compute alta.

Sinun pitäisi olla sivulla AWS Lambda ja kohdassa Functions. Klikkaa oikealta oranssia laatikkoa Create functions.

• Valitse (on tosin oletuksena) Author from scratch

Alempana sinulta kysytään koodiin liittyvät asiat.

• Function name: voit keksiä itse
• Runtime: oletuksena oleva Node.js; luultavasti Node.js 10.x jos ei ole tullut uudempaa

Klikkaa Create function.

• Skrollaa alaspäin, kunnes tulet editoriin. Siitä on valmiina pieni pätkä koodia. Deletoi kaikki.
• Klikkaa auki tämä https://github.com/arithmetric/aws-lambda-ses-forwarder/blob/master/index.js ja kopypeistaa koodi Lambdan editoriin.

Joudut hieman muokkaamaan koodia. Etsi kohta var defaultConfig = { (minulla löytyy riviltä 30) ja muokkaa sen alta:

• fromEmail = sähköpostiosoite, joka näkyy sinulle (uudelleen)lähettävänä osoitteena eli ei se, joka mailannut sinulle; on oltava SES:ssä hyväksytyn domainin osoite. Minulla se on redirect@eksis.one – eli kaikki minulle lähetetyt postit näkyvät Gmailissa lähettäjäosoitteella redirect@eksis.one.
• subjectPrefix = jos haluat otsikon eteen jotain, kuten vaikka FW: ; saa olla tyhjäkin, ja se merkitään kahdella lainausmerkillä ""
• emailBucket = sen bucketin nimi, jonka loit actions-kohdassa
• emailKeyPrefix = bucketissa olevan hakemiston nimi, jonka annoit Object key prefix -kohdassa (ei, en tiedä miksi ei käytetä koko ajan samaa termiä)
• forwardMapping = millä säännöillä saapuvia sähköposteja käännellään, koska niille voi rakentaa erilaisia ohjauksia. Jos sinulla on tarpeita moiselle, niin ihmettele alkuperäisen esimerkkejä, ne avaavat kohtuullisesti ideaa. Mutta jos teet kuten minä, eli käännät kaiken gmailiin, niin se toimii esimerkiksi näin:

  "@example.com": [
  "etu.suku@gmail.com"
  ],
  "@example.tld": [
  "etu.suku@gmail.com"
  ]
  

Kun rakennat sääntöjä, niin pysähdy hetkeksi miettimään, että ei tule silmukkaa. Jos ohjaat saapuvat Gmailiin, niin vaaraa ei ole, mutta jos ohjaat sähköpostiin, joka löytyy Amazonin WorkMailista ja on esimerkiksi example.com -loppuinen, niin esimerkki aiheuttaa loppumattoman loopin. Silloin on syytä tehdä jotain vastaavaa kuin minä tein, tähän tapaan:

forwardMapping: {
   "admin": [
      "jakke.lehtonen@eksis.one"
   ],
   "info": [
      "jakke.lehtonen@eksis.one"
   ],
   "no-reply": [
      "jakke.lehtonen@eksis.one"
   ],
   "jakke.lehtonen@eksis.one": [
      "jakke.lehtonen@eksis.one"
   ]

Skrollaa alaspäin kohtaan Execution role. Klikkaa alasvetovalikon kuvaustekstistä linkkiä IAM console. Uuteen välilehteen aukeaa konsoli, jossa luot uuden käyttäjän suorittamaan uudelleenohjauksen koodia.

• Varmista, että ensimmäinen laatikko AWS service on valittuna
• Klikkaa alempaa kohtaa Lambda

Klikkaa Next: Permissions

Muokataan luotavan käyttäjän oikeuksia.

• Klikkaa Create policy, aukeaa uusi selaimen välilehti
• Valitse sivulta välilehti JSON
• Deletoi pohjana oleva teksti ja kopioi tilalle tämä:

• Etsi kohta YOUR-S3-BUCKET-NAME ja laita siihen actions-kohdassa luodun bucketin nimi

Klikkaa Review policy

Anna luomallesi policylle

• Name = joku keksimäsi nimi
• Description = kirjoita itsellesi joku lyhyt kuvaus, että tietäisit ensi vuonnakin mikä ihme tämä on
• Summary varmaan huomauttelee jotain oikeuksista tai niiden puuttumisista, älä piittaa; ne pitäisi fiksata, mutta en osaa – vielä

Klikkaa Create policy

Palaa takaisin selaimen edelliselle välilehdelle, jossa ollaan luomassa IAM-käyttäjää. Jos hukkasit sen, niin palaa ohjeissa pykälää ylemmäs ennen policyn luomista ja klikkaa itsesi uudelleen IAM consoleen ja aloita uudestaan userin luominen (niin minulle kävi).

Sinun pitäisi olla sivulla Create role ja kohdassa Attach permissions policies.

• Ala kirjoittamaan hakulaatikkoon luomasi policyn nimeä, kunnes se löytyy. Valitse täppäämällä valintaruutu nimen edessä (ikänäöllä muuten ruutu on huonosti näkyvissä)

Klikkaa Next: Tags ja heti perään Next: Review

Create user > Review -sivulla pyydetään hiukan lisätietoja:

• Role name: anna roolille haluamasi nimi
• Role description: anna lyhyt kuvaus, että muistat myöhemminkin mitä rooli tekee. Valitan, ääkköset ovat kiellettyjä merkkejä, joten a ja o käyttöön.
• Policies pitäisi olla luomasi policy

Klikkaa Create role

Palaa takaisin selaimen välilehteen, jossa oltiin luomassa Create function ja siellä valitsemassa Execution role.

• Anna ensimmäisessä alavetovalikossa olla Use an existing role
• Klikkaa seuraavan alavetovalikon vieressä olevaa uudelleenlatauksen ikonia
• Napauta alasvetovalikko auki ja ala kirjoittamaan hakukenttään luomasi roolin nimeä
• Kun rooli löytyy, niin valitse se klikkaamalla

Anna muiden olla oletusarvoissa ja klikkaa oikeassa yläkulmassa olevaa oranssista laatikkoa Save.

Uudelleenohjaus sääntöihin

Nyt tehty Lambda funktio, joka uudelleenohjaa SES-palvelun kautta saapuneet ja S3-buckettiin tallennetut sähköpostit, pitää saada vielä käyttöön. Nythän se on olemassa, mutta kukaan ei käytä sitä. Sen takia pitää palata SES:ään.

Voit avata SES:n Services-valikosta nimellä Simple Email Service tai menemällä tästä linkistä suoraan. Valitse vasemmasta valikosta Rule Sets.

Jos sinulla ei ole muita sääntöjä, niin luettelo on tyhjä. Pääset muokkaamaan luomaasi S3-bucketin tiedot sisältävää sääntöä klikkaamalla nappulaa View Active Rule Set. Aukeaa uusi lista, jossa luomasi sääntö näkyy. Klikkaamalla nimeä saat sen auki muokkausta varten.

• Avaa osiossa Actions oleva alasvetovalikko <Select an action type> ja valitse listasta Lambda.
• Lambda function: valitse listasta luomasi funktio
• Jätä muut oletukselle

Sinulla pitäisi näkyä tämän tapaista:

Klikkaa Save rule

Saat luultavasti ilmoituksen puuttuvista oikeuksista:

SES huomasi, että Lambdalla ei ole riittävästi oikeuksia kirjoittaa buckettiin ja tarjoutuu korjaamaan tilanteen. Klikataan Add permission, koska se on helpompaa kuin tehdä käsin vastaava policy.

Testaus

Lähetä vaikka gmailistasi sähköposti sallimaasi sähköpostiin tai domainiin. Ja tulihan se perille.

 

Jos posti ei liiku, niin tuplatarkista tekemäsi asetukset ja varsinkin, että lähetit sallittuun osoitteeseen. Vilkaise myös CloudWatchin logit selvien virheiden varalta, pääset sinne Services valikon kautta. Voit vilkaista myös tekemäsi bucketin onko sinne ylipäätään saapunut mitään.

Gmailin webmaili

Sallittujen domainien sähköpostit kääntyvät nyt minulle gmail-osoitteeseen. Jos vastaan lähettäjälle, niin osoitteeni muuttuu gmail-osoitteeksi. Se ei ole haluttua, mutta suoraan sanottuna aika harva sen huomaisi. Ihmiset katsovat viestin otsikkoa ja lähettäjän nimeä. Fiksataan se silti.

• Avaa gmailin web-liittymä. Oikealla on rattaan kuva. Valitse siitä asetukset.
• Valitse Tilit ja tuonti
  
• Etsi valikon kohta Viestin lähetysosoite ja klikkaa Lisää sähköpostitili.
• Aukeaa popup, johon lisäät näyttönimesi ja haluamasi sähköpostiosoitteen. Täppää kohta Kohtele aliaksena. Klikkaa Seuraava.
• Gmail tunnistaa saattaa tunnistaa SMTP-palvelimen väärin. Tarkista, että se on email-smtp.eu-west-1.amazonaws.com jos regionisi on EU (Ireland). Samaten TLS on valmiiksi valittuna ja portti 587 on asetettuna. Sinulla jää laittaa SMTP:n tunnus (20 merkkiä) ja salasana (44 merkkiä) paikalleen. Klikkaa Lisää tili.
• Saat vahvistussähköpostin. Voit klikata siinä olevaa vahvistuslinkkiä tai antaa vahvistuskoodin.
• Nyt pystyt lähettämään ja vastaamaan Gmailissa luomallasi osoitteella, kun vaihdat sen klikkaamalla lähettäjän osoitetta.

Koska kyseessä on ilmainen järjestely, niin eihän se täydellinen ole. Lähettäjän vaihtaminen vastattaessa ei ole automaattinen, vaan se on muistettava erikseen vaihtaa. Mutta kompromissi se on.

Yksi selvä puute on, joka on jopa ärsyttävä. Lähettäjän vaihtaminen ei onnistu, jos luet gmail-postejasi esim. Thuderbirdillä, Outlookilla, iMaililla tai millä tahansa muulla sähköpostiohjelmalla. Minulle tuo on ongelma, koska pääsääntöisesti en koskaan käytä webmaileja. Lähettäjän vaihtaminen sentään onnistuu iPadissä Gmailin appsilla, joten ehkä tulen toimeen. Joudun vain hieman muuttamaan toimintatapojani.