Domainit ja niihin liittyvät palvelut / asetukset / jne.

[SamCer]

Hmmm, ei se tarjoa kuin sitä missä lukee, että beta....

Heetkonen menitkö sä klikaamaan DNS --> Email --> DMARC Management?

 

[Aladdin Sane]

Kiitos, nyt löyty ja kaikki näyttää "pass".

Mutta onko siellä ihan loppupäässä tuo X-suspected spam ja true jossain, kun etsit sen pitkän litania joukosta?

 

[SamCer]

Mutta onko siellä ihan loppupäässä tuo X-suspected spam ja true jossain, kun etsit sen pitkän litania joukosta?

Ei löydy ...

Proxy Passista:

Toi Cloudflaren Proxy on upea juttu esim. omille webbisivuille, jotka näkyy koko nettiin, kun se piilottaa sun webbi sevun iipparin, niin, jos joku valopää keksii tehdä palvelunestohyökkäyksen, niin Cloudflare ottaa sen osuman eikä oma servu.

[EDIT] Se tosin rikkoo joitankin palveluita, esim. muistaakseni esim. VPN ei toimi, jos se on päällä kyseiseen A/AAAA-recordiin.

 

[Aladdin Sane]

Ei löydy ...

Jotain hämärää tuossa sitten on silti. Vai katsooko tuo viestin sisältöä vielä niin tarkkaan, kun testiviesteissa ei montaa sanaa ollut, kuin luokkaa "testi testil ölölöl"?

Proxy Passista:


Toi Cloudflaren Proxy on upea juttu esim. omille webbisivuille, jotka näkyy koko nettiin, kun se piilottaa sun webbi sevun iipparin, niin, jos joku valopää keksii tehdä palvelunestohyökkäyksen, niin Cloudflare ottaa sen osuman eikä oma servu.

[EDIT] Se tosin rikkoo joitankin palveluita, esim. muistaakseni esim. VPN ei toimi, jos se on päällä kyseiseen A/AAAA-recordiin.

Miten hemmetissä tuon proxyn saa päälle? Tuonne kun luo käsin recordia, niin ei se anna vaihtoehtoa edes sellaiselle?
Minullakin DNS-recordien listalla proxyn kuvake on vain yhdessä kohtaa (se DKIM rivi ja siinäkään se ei ole täpästä laitettu päälle. Ei missään muussa edes tarjoa sitä...

Toinen outous on, että omalta domainilta toiselle saman alla lähetetty viesti menee roskapostikansioon suoraan!?!?!

 

[Aladdin Sane]

tuplaviesti poistettu....

 

[SamCer]

Jotain hämärää tuossa sitten on silti. Vai katsooko tuo viestin sisältöä vielä niin tarkkaan, kun testiviesteissa ei montaa sanaa ollut, kuin luokkaa "testi testil ölölöl"?


Miten hemmetissä tuon proxyn saa päälle? Tuonne kun luo käsin recordia, niin ei se anna vaihtoehtoa edes sellaiselle?
Minullakin DNS-recordien listalla proxyn kuvake on vain yhdessä kohtaa (se DKIM rivi ja siinäkään se ei ole täpästä laitettu päälle. Ei missään muussa edes tarjoa sitä...

Toinen outous on, että omalta domainilta toiselle saman alla lähetetty viesti menee roskapostikansioon suoraan!?!?!

Älä, älä, koske siihen Proxyyn se tuo vaan nyt lisää ongelmia. Keskity nyt vaan siihen mitä ollaan oltu selvittämässä .

Toi DNS-only on se mitä nyt tarvit

 

[jhalmu]

Onks kokemuksia tuosta Cyber Panelista?

 

[Aladdin Sane]

Älä, älä, koske siihen Proxyyn se tuo vaan nyt lisää ongelmia. Keskity nyt vaan siihen mitä ollaan oltu selvittämässä .

Toi DNS-only on se mitä nyt tarvit

Niin se taitaa olla. Sitä paitsi eihän mulla ole oma ip pelissä, kun domain ja dns on CF:llä ja iCloud Applella. Liekö noita voisin edes proxyttää itse?

Mutta joo, jotain outoa edelleen oman domainin alla on, jos viestejä lähettää muulla kuin Apple omilla sähköpostisoftilla toiselle oman domanin alla olevalle. Onko kukaan tapellut iCloud custom domainien kanssa vaikkapa Outlook Windows apissa?

 

[SamCer]

Onks kokemuksia tuosta Cyber Panelista?

Sanon heti alkuun, että en katonut postaamasi videota ollenkaan. Syy: Videon thubnailissa lukee "Host your own email server" ja oman maili servun hostaaminen on ihan helv**** huono idea! Täälläkin porukka alkaa välittömästi kehoittamaan unohtamaan koko idean, en pelkästään minä. Sen suojaaminen ja toimintakunnon ylläpitämien on kokopäivätyötä, joka ei maksa vaivaa.

Asensin omaan käyttöön Dovecotin, joka palvelee vain ja ainoastaan mun sisäverkkoa ja senkin toimintakuntoon saattaminen oli aika helv***** moinen homma (tosin pääasiassa GSSAPI-autentikoinnin takia kun itellä on sisäverkossa FreeIPA palvelemassa keskitettyä käyttäjien hallintaa).

 

[SamCer]

Niin se taitaa olla. Sitä paitsi eihän mulla ole oma ip pelissä, kun domain ja dns on CF:llä ja iCloud Applella. Liekö noita voisin edes proxyttää itse?

Joo ei, sun oma iippari ei tule peliin missään vaiheessa mailin kanssa mailin lähettäjän/vastaanottajan kanssa. Välissä on sun tapauksessa koko ajan Äpöl .

 

[jad]

Jos Cloudflarea käyttää vain DNS palveluun, voi koko palvelun laittaa pauselle. Onnistuu overview sivulta.

No lisää selvittelyä ja selvisi, että niitä voi maksimissaan olla vain 6 kpl ja meillä oli 3kpl, eli no Prombelm? Se domain pelkästään ei ole 1kpl vaan, se mikä merkkaa on heidän käyttämä mailipalvelu, joka tässä tapauksessa oli Google. Googlella on käyttössä 4kpl ja 3 plus 4 on 7, minkä takia koko homma kusi! VOI VI#$^$&* PER#$^$& SAA$^$%^Y, että vitutti. Tuon VI#$^%$^&$ rajoituksen takia piti tiputta SPF pois kokonaan!

Ei ole tuollaista rajoitusta olemassa. SPF:ään voi listata ip-osoitteita vaikka kuinka paljon. Rajoitus koskee sitä, montako nimipalvelinkyselyä SPF aiheuttaa jas en maksimi on 10 kpl. Hieman kikkailemalla ja säätämällä SPF:ään kyllä saa aika paljon lähettäviä palvelimia sallituksi.

Hyvä SPF testeri, kertoo nimipalvelinkyselyiden määrän ja ehdottelee muutoksiakin. Tosin sfp flattening ei välttämättä ole hyvä ratkaisu, tapauskohtaista.

SPF Surveyor - dmarcian

dmarcian's SPF Surveyor is an SPF diagnostic tool that presents a graphical view of SPF records. Discover any problems with your SPF record.

dmarcian.com

Tässä toinen hyvä testi. Generoi yksilöllisen sähköpostiosoitteen, johon voit lähettää testisähköpostin ja palvelu kertoo mitä kaikkea meilissä oli vialla

Newsletters spam test by mail-tester.com

mail-tester.com is a free online service that allows you to test your emails for Spam, Malformed Content and Mail Server Configuration problems

www.mail-tester.com

Noista domainvälittäjistä ja webhotelleista pikkuinen huomio. Ruotsalainen Miss Group on ostellut suomesta aika monta firmaa ja vaikka ne edelleen toimivat omilla brändeillään, niin en yllättyisi siitä, että hinnoittelu lähitulevaisuudessa muuttuisi kaikissa samanlaiseksi. Tähän varmaan liittyi domainhotellinkin hintojen nosto.

 

[AkQ]

Sanon heti alkuun, että en katonut postaamasi videota ollenkaan. Syy: Videon thubnailissa lukee "Host your own email server" ja oman maili servun hostaaminen on ihan helv**** huono idea! Täälläkin porukka alkaa välittömästi kehoittamaan unohtamaan koko idean, en pelkästään minä. Sen suojaaminen ja toimintakunnon ylläpitämien on kokopäivätyötä, joka ei maksa vaivaa.

Asensin omaan käyttöön Dovecotin, joka palvelee vain ja ainoastaan mun sisäverkkoa ja senkin toimintakuntoon saattaminen oli aika helv***** moinen homma (tosin pääasiassa GSSAPI-autentikoinnin takia kun itellä on sisäverkossa FreeIPA palvelemassa keskitettyä käyttäjien hallintaa).

Meinasin sanoa saman, vähän ikävemmillä sanoilla.

E-mail servun hostaus on työ, sitä ei voi vain "konffata kuntoon ja unohtaa". Ei kannata ryhtyä ollenkaan, ellei kyseessä ole vain harjoitus. Mitään järkevää sähköpostilaatikkoa ei kannata itse hostata, ellei oikeasti halua työskennellä sen parissa vuodesta toiseen.

 

[Aladdin Sane]

Jos Cloudflarea käyttää vain DNS palveluun, voi koko palvelun laittaa pauselle. Onnistuu overview sivulta.

Mitä tarkoitat tällä?

 

[Aladdin Sane]

Joo ei, sun oma iippari ei tule peliin missään vaiheessa mailin kanssa mailin lähettäjän/vastaanottajan kanssa. Välissä on sun tapauksessa koko ajan Äpöl .

Joo, nyt CF:ssä (CF=Cloudflare) ei valita mitään mutta kehottaa kylläkin luomaan mm. WWW DNS recordit, onko tuolle tarvetta tehdä mitään (jotain ohjauksia nulliin tms.), jos ei www-sivuja ole? Samoin sanoo, että DKIM avainta ei edelleenkään ole, mutta tarviiko sitä sen kummemmin, jos se tulee iCloudin kautta, kuten vaikuttaa tekevän? Entä tarviiko/kannattaako CF:ssä luoda SSL/TLS sertifikaatteja tai vastaavia, jos sitä käyttää DNS-palveluna oman domainin sähköposteille (jotka ovat iCloud custom domain palvelussa)?

Mutta isoin ongelma, nyt esim. testiposti omalta domainilta omalle outlook.com osoittelle > meni suoraan roskapostikansioon!
Gmail edelleen otti vastaan vittuilematta ja näyttää myös tiedoissaan, että DKIM, SPF ja DMARC pass.
Tänään myös itselle lähetetty maili oma domain > oma normi iCloud.com email meni läpi, eilen se meni roskiin.
Mutta toiselle oman domainin emailille lähetetty viesti myös kirjaantui roskapostiksi.

Joku ihan perustavaa laatua oleva ongelma (toivottavasti ei ominaisuus) on iCloud custom domanilta lähetetyn postin kanssa.
Mitähän tässä seuraavaksi tutkisi mistä tuo voi johtua?

 

[jad]

Mitä tarkoitat tällä?

Overview sivulla oikeassa alakulmassa on "Pause Cloudflare on site" tms. Tämä kytkee kaikki CF:n proxy ym. ominaisuudet pois päältä, mutta DNS edelleen toimii. Sinula kun käyttö on ainastaan sähköpostia varten, niin voit ihan hyvin pistää pauselle.

Joo, nyt CF:ssä (CF=Cloudflare) ei valita mitään mutta kehottaa kylläkin luomaan mm. WWW DNS recordit, onko tuolle tarvetta tehdä mitään (jotain ohjauksia nulliin tms.), jos ei www-sivuja ole?

Ei

Samoin sanoo, että DKIM avainta ei edelleenkään ole, mutta tarviiko sitä sen kummemmin, jos se tulee iCloudin kautta, kuten vaikuttaa tekevän?

Ei

Entä tarviiko/kannattaako CF:ssä luoda SSL/TLS sertifikaatteja tai vastaavia, jos sitä käyttää DNS-palveluna oman domainin sähköposteille (jotka ovat iCloud custom domain palvelussa)?

Ei

Testatisko lähettää meiliä tuonne mail-tester palveluun, mitä se sanoi ?

Edit:

Mutta isoin ongelma, nyt esim. testiposti omalta domainilta omalle outlook.com osoittelle > meni suoraan roskapostikansioon!

Microsoftin roskapostisuodatus on todella agressiivinen, saattaa mennä roskapostiin pelkästään sen takia, että microsoft ei ole aiemmin nähnyt sähköposteja uudelta domainiltasi. Menikö tämä oma domain osoite nyt Outlookissa turvallisten lähettäjien listalle, minkä johdosta toinen testiposti ei enää päätynyt roskapostiin. Johonkin toiseen outlook/microsoft osoitteeseen lähetettäessä voi edelleen mennä roskapostiin.

 

[user9999]

Tuossa Cloudflaren ohje tuohon iCloud custom domainiin.

iCloud Custom Email Domains · Cloudflare Registrar docs

With iCloud Custom Email Domain , you can now purchase a custom domain right from iCloud Settings through Cloudflare and have it automatically set up …

developers.cloudflare.com

Kuva tuosta ohjeesta.

DMARC puuttuu, mutta sitähän Apple ei pyydä tekemään.

Set up an existing domain with iCloud Mail – Apple Support (UK)

To finish setting up your custom domain and email addresses with iCloud Mail, you'll need to update your MX, TXT and CNAME records with your domain registrar.

support.apple.com

 

[Paapaa]

Näissä kannattaa tosiaan muistaa, että liian tiukat asetukset voivat oikeasti aiheuttaa ongelmia. Eli hommaat custom domainin, asetat SPF:t, DKIM:t ja DMARC:t kuntoon ja lähetät postia vastaanottajalle B. Mutta B:n osoite onkin esim. iki-osoite, joka forwardoidaan automaattisesti osoitteeseen C. Tässä kohtaa C näkee, että viestin headerit eivät ole kunnossa, ja saattavat iskea sen A:n forwardoidun mailin asetuksista riippuen roskapostiin kun näyttää että joku lähettää postia A:n nimissä. Siksi ei ehkä kannata aloittaa kaikkein tiukimmista asetuksista. Ongelma on se, ettet ehkä tiedä, milloin se B on forwardoitu osoite eli milloin joku forwardoi sun mailisi ihan legitisti.

Emailimaailma ei ole täydellinen. Tässä Ikin kritiikkiä tekniikoihin:

Iki ja SPF [ikiWiki]

ikiwiki.iki.fi

DMARC and SPF considered harmful [ikiWiki]

ikiwiki.iki.fi

 

[user9999]

Ja kun noita DNS juttuja säätää niin kannattaa odotella rauhassa ennen kuin testaa muutoksen jälkeen mitään. Voi olla pitkiäkin viiveitä, että muutokset on päivittynyt joka paikkaa.
Seuraavaa ilmoitusta voi tulla iCloud custom domainissa.

 

[jad]

Ja kun noita DNS juttuja säätää niin kannattaa odotella rauhassa ennen kuin testaa muutoksen jälkeen mitään. Voi olla pitkiäkin viiveitä, että muutokset on päivittynyt joka paikkaa.
Seuraavaa ilmoitusta voi tulla iCloud custom domainissa.

Cloudflaren ollessa DNS palveluna, on TTL oletuksena 'Auto', mikä käytännössä tarkoittaa muutamaa minuuttia. Aika harvoin nykyään enää näkyy suuria TTL arvoja muissa kuin NS tietueissa. Joskus historiassahan suurella TTL:llä pyrittiin vähentämään nimipalvelimen kuormitusta.

 

[Obi-Lan]

SPF
- Kerrot maailmalle mitkä palvelimet lähettävät domainisi nimissä spostia. Eli kun lähetät postia, lähtevä palvelin pitää olla SPF:ssä ilmoitettu.
- IP osoitteita voi olla rajaton määrä, DNS lookupit pitäisi olla 5 tai alle
- lopullinen tulkinta ja spam pisteytys on kuitenkin vastaanottajan palvelimen tai palvelun käsissä
- SPF Query Tool voi tarkistaa syntaksin, mutta toki ei kerro jos vaikka olet määrittänyt palvelimet väärin

DKIM
- Käyttämäsi sähköpostipalvelin allekirjoittaa lähtevän viestin omalla avaimella
- Julkinen avain jaetaan DNS recordissa
- Vastaanottaja tarkistaa avaimen DNS kautta ja säätää pisteytystä jos kaikki täsmää
- Pilvipalvelut yleensä hoitavat tuon avainten luonnin automaattisesti ja antavat CNAME millä viitataan palvelun hallinnoimaan DNS recordiin

DMARC
- Ilmoittaa vastaanottajalle miten sen pitäisi suhtautua SPF ja DKIM tarkistuksiin, esim. molemmat pitää olla kunnossa tai muuten suositellaan viestin laittamista suoraan roskapostiin
- Sisältää myös raportointi featuren, missä lähettäjä voi ilmoittaa domainin omistajalle palvelimet mitkä lähettelevät domainin nimissä postia. Tätä taidettiin vähän vesittää GDPR myötä, nyt tulee ilmoitus vain IP osoitteista (jos vastaanottaja yleensä tekee tätä raportointia)

Ensisijaisesti katsoisin mitä iCloud neuvoo tekemään ja jättäisin Cloudflare ehdotukset huomioimatta.

 

[jad]

- IP osoitteita voi olla rajaton määrä, DNS lookupit pitäisi olla 5 tai alle

10 DNS kyselyä.

 

[Aladdin Sane]

Overview sivulla oikeassa alakulmassa on "Pause Cloudflare on site" tms. Tämä kytkee kaikki CF:n proxy ym. ominaisuudet pois päältä, mutta DNS edelleen toimii. Sinula kun käyttö on ainastaan sähköpostia varten, niin voit ihan hyvin pistää pauselle.

OK, mutta taisi vieläkin jäädä nuo kaikki valikot sinne edelleen tyrkylle, mutta proxyt menee pois päältä, jos on käytössä. Minulle ei proxya päällä.

Testatisko lähettää meiliä tuonne mail-tester palveluun, mitä se sanoi ?

Huomasin tuon testerin mutta en rohjennut kokeilla, jos on joku spämmiä varten osoitteita keräävä. Onko tuo siis kuitenkin ihan turvallinen testi?

Tähän mennessä olen itsekseni lukenut viestien headereita läpi, kun tuosakin nuo SPF, DKIM ja DMARC jutut ja niiden toiminta kyllä näkyy mutta nuo spammin scoret on kyllä välillä vähän vaikeita tulkita itse....

Microsoftin roskapostisuodatus on todella agressiivinen, saattaa mennä roskapostiin pelkästään sen takia, että microsoft ei ole aiemmin nähnyt sähköposteja uudelta domainiltasi. Menikö tämä oma domain osoite nyt Outlookissa turvallisten lähettäjien listalle, minkä johdosta toinen testiposti ei enää päätynyt roskapostiin. Johonkin toiseen outlook/microsoft osoitteeseen lähetettäessä voi edelleen mennä roskapostiin.

Hmmm, niinpä tosiaan voi olla, koska testasin sitä juuri tuolla tavalla kuin mainitsit, että siirtää roskapostiin menneen eka viestin saapuneisiin niin seuraava viesti tuli suoraan saapuneisiin, eli se whitelistaa sen tuolla tavalla. Näköjään iCloud iskee vastapalloon ja Outlookista > omalle domainille replyt meni siellä roskapostiksi. Samalla tempulla iCloud myös whitelistaa mutta tuo on kyllä aika hankala tietää, jos se koskee vain itseäni ja muille silti paukkuu roskapostiksi edelleen.

Olin lukevinani juuri domain reputation, eli uusi domain saattaa olla aika pitkään epäilyttävien listalla. Onhan tuo kyllä melko hankala, jos käytännössä sähköpostia varten hankittu domaini ei ole käyttökelpoinen pitkään aikaan ja sille pitää alkaa yrittää kerätä ensin tunnettavuttaa.

Olen nyt siemenksi laitellut viestejä edes takaisin omalta domainilta Outlook ja Gmail tileilleni ja yrittänyt tehdä jotain asiallista viestiä, ettei otsikottomat ja epäilyttävän lyhyet viestit herättäisi spammifilttereitä.

Onko tuossa domain reputationin ansaitsemisessa mitään oikotietä?

 

[Aladdin Sane]

Tuossa Cloudflaren ohje tuohon iCloud custom domainiin.

iCloud Custom Email Domains · Cloudflare Registrar docs

With iCloud Custom Email Domain , you can now purchase a custom domain right from iCloud Settings through Cloudflare and have it automatically set up …

developers.cloudflare.com

Kuva tuosta ohjeesta.

DMARC puuttuu, mutta sitähän Apple ei pyydä tekemään.

Set up an existing domain with iCloud Mail – Apple Support (UK)

To finish setting up your custom domain and email addresses with iCloud Mail, you'll need to update your MX, TXT and CNAME records with your domain registrar.

support.apple.com

On tuo ohje minulle tuttu ja tuo on jotakuinkin se minkä iCloud omaa domainia käyttöönotettaessa tekee automattisesti ja siitä ei ole koskaan ollutkaan kyse omassa tapauksessa, että ei olisi tiedossa mitä oletukset ovat. Tuossa kuvassa nuo TTL on väärät, oletuksena iCloud laittee 3600s (1h).

Mutta se homma itselläni onkin tämä, että haluaisin oman domainin olevan mahdollisimman hyvin suojattu, että se ei päädy johonkin spämmilistalle, joten kiristin heti alkuunsa tuon v=spf1 rivin lopussa olevan tilde all > -all asetukseen, eli tiukimpaan. Sen lisäksi olen laittanut DMARC rivin DNS-recordeihin kireimmällä reject asetuksella. Eikös se pitäisi niin tehdäkin, vaikka tuota DMARCia iCloud ei sinne oletuksena luo?

 

[Aladdin Sane]

Näissä kannattaa tosiaan muistaa, että liian tiukat asetukset voivat oikeasti aiheuttaa ongelmia. Eli hommaat custom domainin, asetat SPF:t, DKIM:t ja DMARC:t kuntoon ja lähetät postia vastaanottajalle B. Mutta B:n osoite onkin esim. iki-osoite, joka forwardoidaan automaattisesti osoitteeseen C. Tässä kohtaa C näkee, että viestin headerit eivät ole kunnossa, ja saattavat iskea sen A:n forwardoidun mailin asetuksista riippuen roskapostiin kun näyttää että joku lähettää postia A:n nimissä. Siksi ei ehkä kannata aloittaa kaikkein tiukimmista asetuksista. Ongelma on se, ettet ehkä tiedä, milloin se B on forwardoitu osoite eli milloin joku forwardoi sun mailisi ihan legitisti.

SPF
- Kerrot maailmalle mitkä palvelimet lähettävät domainisi nimissä spostia. Eli kun lähetät postia, lähtevä palvelin pitää olla SPF:ssä ilmoitettu.
- IP osoitteita voi olla rajaton määrä, DNS lookupit pitäisi olla 5 tai alle
- lopullinen tulkinta ja spam pisteytys on kuitenkin vastaanottajan palvelimen tai palvelun käsissä
- SPF Query Tool voi tarkistaa syntaksin, mutta toki ei kerro jos vaikka olet määrittänyt palvelimet väärin

DKIM
- Käyttämäsi sähköpostipalvelin allekirjoittaa lähtevän viestin omalla avaimella
- Julkinen avain jaetaan DNS recordissa
- Vastaanottaja tarkistaa avaimen DNS kautta ja säätää pisteytystä jos kaikki täsmää
- Pilvipalvelut yleensä hoitavat tuon avainten luonnin automaattisesti ja antavat CNAME millä viitataan palvelun hallinnoimaan DNS recordiin

DMARC
- Ilmoittaa vastaanottajalle miten sen pitäisi suhtautua SPF ja DKIM tarkistuksiin, esim. molemmat pitää olla kunnossa tai muuten suositellaan viestin laittamista suoraan roskapostiin
- Sisältää myös raportointi featuren, missä lähettäjä voi ilmoittaa domainin omistajalle palvelimet mitkä lähettelevät domainin nimissä postia. Tätä taidettiin vähän vesittää GDPR myötä, nyt tulee ilmoitus vain IP osoitteista (jos vastaanottaja yleensä tekee tätä raportointia)

Ensisijaisesti katsoisin mitä iCloud neuvoo tekemään ja jättäisin Cloudflare ehdotukset huomioimatta.

Olen jo pääpiirteittäin ymmärtänyt mitä nuo SPF, DKIM ja DMARC meinaa mutta onko nyt todellakin niin, että niitä ei kannattaisikaan käyttää tai ainakin laittaa löysimmälle? Eikö tuo nyt sitten anna sen mahdollisuuden, että joku(t) alkaakin lähetellä kasino ja viagra mainoksia sinun nimissäsi, kun ei ole kaikki estot päällä ja päädyt spämmifilttereiden mustalle listalle? Tästä on todella näköjään kahta päinvastaista koulukuntaa, että pitääkö nuo olla kireimmällä vai löysimmällä.

Ei ole itselläni ketään tuttavaa, jolla olisi IKI.fi osoitetta, niin ei sinänsä haittaa, jos se ei kireistä asetuksista tykkää mutta onhan tuollaista forwardointia olemassa paljon muillakin ymmärtääkseni ja yksittäiset saattaa omia viestejään ohjailla tarjoajalta toiselle mutta tuoko jää nyt sitten lähettäjän ongelmaksi, jos omat viestit eivät saavukaan tuon takia.

 

[Obi-Lan]

Olen jo pääpiirteittäin ymmärtänyt mitä nuo SPF, DKIM ja DMARC meinaa mutta onko nyt todellakin niin, että niitä ei kannattaisikaan käyttää tai ainakin laittaa löysimmälle? Eikö tuo nyt sitten anna sen mahdollisuuden, että joku(t) alkaakin lähetellä kasino ja viagra mainoksia sinun nimissäsi, kun ei ole kaikki estot päällä ja päädyt spämmifilttereiden mustalle listalle? Tästä on todella näköjään kahta päinvastaista koulukuntaa, että pitääkö nuo olla kireimmällä vai löysimmällä.

Se riippuu vähän. SPF on näistä vanhin, ehkä jo parhaiten tuettu ja helppo laittaa kun se ei vaadi palvelimelta mitään. Pitää vaan ymmärtää, että jos määrittää SPF ainoaksi palvelimeksi iCloudin SMTP palvelimen ja "-all" niin sitten ei voi käyttää esim. operaattorin SMTP palvelinta sähköpostin lähettämiseen koska SPF mukaan ne ei ole sallittuja lähettäjiä.

DKIM on jo vähän monimutkaisempi, eli palvelimen pitää allekirjoittaa viestit avaimella. Eli ensin palvelun pitää tukea sitä ja se yleensä tarvitsee laittaa päälle jostain. Ja tällöin DNS mikä viittaa julkiseen avaimeen pitää olla kunnossa, jos vastaanottaja näkee että se on allekirjoitettu mutta ei löydä lähettäjän julkista avainta niin siitä ei ole hyötyä, joku saattaa jopa nostaa spam scorea. Tällöinkin lähtevän sähköpostin pitää lähteä sen palvelun kautta.

DMARC on tuorein ja ehkä vähiten tuettu, toisaalta se ei taas vaadi palvelimelta mitään kunhan edelliset SPF ja DKIM ovat kunnossa tai jos palvelin ei tue DKIM niin sitten pitää olla vaatimatta sitä DMARCissa.

Pointti lähinnä, että kaikki pitää tehdä oikein tai omat postit on väärien sääntöjen johdosta vastaanottajalla roskapostissa. Jos kaikki on 100% varmuudella oikein niin tiukimmille vaan. Omat meilit on Zoho:ssa ja se antoi valmiit DNS recordid SPF ja DKIM. En jaksanut laittaa DMARCia ja viestit meni kaikkiin testattuihin vastaanottajiin läpi. Toki domain oli ollut jo olemassa tuossa kohtaa parisen vuotta.

iki.fi kai tekee sillei, että muuttavat vaan RCPT TO: kenttään määritetyn kohdelaatikon. (Korjatkaa jos olen väärässä). Tällöin vastaanottava palvelin näkee että viesti tulee iki.fi SMTP palvelimelta, mutta koska lähettäjänä on alkuperäinen, tarkistetaan lähettäjän domainin SPF mikä ei tule täsmäämään iki.fi SMTP palvelimeen. Teoriassa vastaanottavan palvelimen voisi confata esim. whitelistaamaan kaikki iki.fi palvelimien kautta tuleva liikenne, mutta Gmail, Outlook.com eivät ainakaan mahdollista tälläista ja todennäköisesti eivät koskaan tule.

 

[fin_modder]

Näillä asetuksilla ei ole mennyt omat postit pitkään aikaan mihinkään spämmiin. Domainini nimipalvelimet ovat tosiaan cloudflarella, mutta posti protonmaililla ja domain on ostettu shellit.org sivustolta.
Etuna tuossa protonmailissa on se että heillä on suoraan tuki salattuun postiin, hyvät IP:t (eli siis ei mustilla listoilla ja "pitkäaikaiset")

Type;TXT
Name; _dmarc.domain.fi
Content; v=DMARC1; p=reject; rua=mailto:dmarc@xxxx.uriports.com; ruf=mailto:dmarc@xxxx.uriports.com; fo=1:d:s
- Tällä kerrotaan että DMARC käytössä, ja epäonnistuneet menevät rejectiin. Rejectiä valvotaan uriports SAAS palvelulla, jotta eivät mene ihan täysin bittiavaruuteen.

Type; TXT
Name; domain.fi
Content; v=spf1 include:_spf.protonmail.ch mx ~all
- Kerrotaan että omaa mailiani ylläpitää protonmail, ja lisätään tietueeseen heidän kaikki _spf tietueet.

Type; TXT
Name; domain.fi
Content; protonmail-verification=xxxxxxxx
- Varmennetaan että omistan domainin protonmailille.

Type; MX (prio 10)
Name; domain.fi
Content; mail.protonmail.ch

Type; MX (prio 20)
Name; domain.fi
Content; mailsec.protonmail.ch
- Näillä kahdella kerrotaan primääri ja vara SMTP palvelimet, jotka voivat vastaanottaa sähköpostia.

Lisäksi monta pfsense DDNS lisäosalla automatisoituja muuttuvia IP:tä. Esim jos himan osoite vaihtuu -> pfsense päivittää Cloudflare API avaimella xxx.domain.fi DNS tietueen osoittamaan uuteen IP:n.

 

[jad]

Huomasin tuon testerin mutta en rohjennut kokeilla, jos on joku spämmiä varten osoitteita keräävä. Onko tuo siis kuitenkin ihan turvallinen testi?

On ihan pätevä. Eivät myy meiliosoitettasi millekään kasinokoijarille.

Olin lukevinani juuri domain reputation, eli uusi domain saattaa olla aika pitkään epäilyttävien listalla. Onhan tuo kyllä melko hankala, jos käytännössä sähköpostia varten hankittu domaini ei ole käyttökelpoinen pitkään aikaan ja sille pitää alkaa yrittää kerätä ensin tunnettavuttaa.

Omien kokemusten mukaan ainoastaan Microsoftin kanssa on joskus ollut ongelmia uusien domainien kanssa. Kaikkialle muualle on sähköpostit menneet hyvin perille, kunhan asetukset on kunnossa.

Onko tuossa domain reputationin ansaitsemisessa mitään oikotietä?

Ei ole, mutta ei tuosta kannata kauheata stressiäkään ottaa, tuo kuitenkin on vain yksi tekijä monen muun joukossa.

Sen lisäksi olen laittanut DMARC rivin DNS-recordeihin kireimmällä reject asetuksella. Eikös se pitäisi niin tehdäkin, vaikka tuota DMARCia iCloud ei sinne oletuksena luo?

Kyllä. Jos haluaa pelata varman päälle, niin policyksi none ja joku raportointipalvelu käyttöön joksikin aikaa. Kun näyttää siltä, että asetukset on kunnossa, niin sitten reject käyttöön. Tosi koska kyse on nyt varsin pienistä sähköpostimääristä ja yksityiskäyttöön tarkoitetusta meilistä, en tästäkään hirveästi stressiä ottaisi, suoraan rejectille vaan.

Type;TXT
Name; _dmarc.domain.fi
Content; v=DMARC1; p=reject; rua=mailto:dmarc@xxxx.uriports.com; ruf=mailto:dmarc@xxxx.uriports.com; fo=1:d:s
- Tällä kerrotaan että DMARC käytössä, ja epäonnistuneet menevät rejectiin. Rejectiä valvotaan uriports SAAS palvelulla, jotta eivät mene ihan täysin bittiavaruuteen

Kiitos tästä! Uriports vaikuttaa varsin pätevälle ja kohtuuhintaiselle palvelulle verrattuna dmarcian.com ja dmarcly.com:iin.

 

[Aladdin Sane]

Pitää vaan ymmärtää, että jos määrittää SPF ainoaksi palvelimeksi iCloudin SMTP palvelimen ja "-all" niin sitten ei voi käyttää esim. operaattorin SMTP palvelinta sähköpostin lähettämiseen koska SPF mukaan ne ei ole sallittuja lähettäjiä.

Mutta tuonhan voi kiertää kirjautumalla siihen oikeaan SMTP-palvelimeen.

Antaako edes juuri kukaan operaattori enää käyttää omaa STMP-palvelintaan muuta kuin heidän itsensä tarjoamien sähköpostitilien viestin lähetykseen? Itselläni ollut Telian sähköposti pääasiallisena tilinä ja en nyt muista tarkkaan mutta on kai siitä ainakin 10-15 vuotta aikaa, kun ne viimeisen kerran antoivat sen SMTP:n kautta lähettää muiden sähköpostien nimissä viestejä, joten joskus noihin aikoihin olen omien muiden tilien viestit lähettänyt kirjautumalla sen tarjoajan SMTP-palvelimeen.

iki.fi kai tekee sillei, että muuttavat vaan RCPT TO: kenttään määritetyn kohdelaatikon. (Korjatkaa jos olen väärässä). Tällöin vastaanottava palvelin näkee että viesti tulee iki.fi SMTP palvelimelta, mutta koska lähettäjänä on alkuperäinen, tarkistetaan lähettäjän domainin SPF mikä ei tule täsmäämään iki.fi SMTP palvelimeen. Teoriassa vastaanottavan palvelimen voisi confata esim. whitelistaamaan kaikki iki.fi palvelimien kautta tuleva liikenne, mutta Gmail, Outlook.com eivät ainakaan mahdollista tälläista ja todennäköisesti eivät koskaan tule.

Jos se tuolla periaatteella on toteutettu, niin eipä ihme, jos viestejä jää välille.

 

[Obi-Lan]

Mutta tuonhan voi kiertää kirjautumalla siihen oikeaan SMTP-palvelimeen.

Antaako edes juuri kukaan operaattori enää käyttää omaa STMP-palvelintaan muuta kuin heidän itsensä tarjoamien sähköpostitilien viestin lähetykseen? Itselläni ollut Telian sähköposti pääasiallisena tilinä ja en nyt muista tarkkaan mutta on kai siitä ainakin 10-15 vuotta aikaa, kun ne viimeisen kerran antoivat sen SMTP:n kautta lähettää muiden sähköpostien nimissä viestejä, joten joskus noihin aikoihin olen omien muiden tilien viestit lähettänyt kirjautumalla sen tarjoajan SMTP-palvelimeen.

Joo kaikilla vakavasti itsensä ottavilla palveluilla on omat palvelimet joiden kautta kannattaa lähettää. Toki mikään ei estä lisäilemästä sinne SPF muitakin palvelimia, paitsi toki sitten viesteihin ei tule DKIM allekirjoituksia.

Operaattoreilla on edelleen avoimet SMTP palvelimet joita voi käyttää pelkästään operaattorin omista liittymistä. Esim. Elisalla on smtp.kolumbus.fi ja Telialla mail.inet.fi käsittääkseni toimii anonyyminä porttiin 25. Tämä lienee sen takia, kun portti 25 muuten on blokattu kaikista kuluttajaliittymistä.

 

[Aladdin Sane]

Joo kaikilla vakavasti itsensä ottavilla palveluilla on omat palvelimet joiden kautta kannattaa lähettää. Toki mikään ei estä lisäilemästä sinne SPF muitakin palvelimia, paitsi toki sitten viesteihin ei tule DKIM allekirjoituksia.

Niinpä, ja eikö se ettei käyttäisi oman email palvelun tarjoajan SMTP:tä lähettämiseen riskeeraa senkin, että oma email osoite päätyy johonkin spämmilistalle? En nyt itse keksi mitään pätevää syytä olla käyttämättä oman emailin tarjoajan SMTP:tä milloinkaan.

Operaattoreilla on edelleen avoimet SMTP palvelimet joita voi käyttää pelkästään operaattorin omista liittymistä. Esim. Elisalla on smtp.kolumbus.fi ja Telialla mail.inet.fi käsittääkseni toimii anonyyminä porttiin 25. Tämä lienee sen takia, kun portti 25 muuten on blokattu kaikista kuluttajaliittymistä.

Ei ainakaan omalla kohdalla mail.inet.fi ole enää arviolta viimeiseen 10-15 vuoteen sallinut lähettää emailia muiden kuin heidän pp.inet.fi osoiteesta vaikka käyttö heidän liittymän kautta luonnollisesti. Tämä siis normi emaileille jotka on jonkun toisen palveluntarjoajan kautta, jolloin ei dns-asetuksia ole luonnollisesti itselle määritelty samaan tapaan kuin nyt omalla domainilla (en ole sillä enää edes kokeillut käyttää Telian SMTP:tä koska voin kirjautua iCloudin lähettävän postin palvelimeen omalta domainilta postaillessa).

 

[Aladdin Sane]

Näillä asetuksilla ei ole mennyt omat postit pitkään aikaan mihinkään spämmiin. Domainini nimipalvelimet ovat tosiaan cloudflarella, mutta posti protonmaililla ja domain on ostettu shellit.org sivustolta.
Etuna tuossa protonmailissa on se että heillä on suoraan tuki salattuun postiin, hyvät IP:t (eli siis ei mustilla listoilla ja "pitkäaikaiset")

Type;TXT
Name; _dmarc.domain.fi
Content; v=DMARC1; p=reject; rua=mailto:dmarc@xxxx.uriports.com; ruf=mailto:dmarc@xxxx.uriports.com; fo=1:d:s
- Tällä kerrotaan että DMARC käytössä, ja epäonnistuneet menevät rejectiin. Rejectiä valvotaan uriports SAAS palvelulla, jotta eivät mene ihan täysin bittiavaruuteen.

Type; TXT
Name; domain.fi
Content; v=spf1 include:_spf.protonmail.ch mx ~all
- Kerrotaan että omaa mailiani ylläpitää protonmail, ja lisätään tietueeseen heidän kaikki _spf tietueet.

Type; TXT
Name; domain.fi
Content; protonmail-verification=xxxxxxxx
- Varmennetaan että omistan domainin protonmailille.

Type; MX (prio 10)
Name; domain.fi
Content; mail.protonmail.ch

Type; MX (prio 20)
Name; domain.fi
Content; mailsec.protonmail.ch
- Näillä kahdella kerrotaan primääri ja vara SMTP palvelimet, jotka voivat vastaanottaa sähköpostia.

Lisäksi monta pfsense DDNS lisäosalla automatisoituja muuttuvia IP:tä. Esim jos himan osoite vaihtuu -> pfsense päivittää Cloudflare API avaimella xxx.domain.fi DNS tietueen osoittamaan uuteen IP:n.

Miten tuossa sinulla voi DMARC olla toimiva, kun DKIM määritystä ei ole lainkaan DNS-recordeissa?

Muuten nuo sinun käytössä olevat asetukset on melko lailla identtiset omieni kanssa paitsi, että minulla on DKIM sinne määriteltynä. Minulla tosin tuossa SPF:ssä on -all (ei tilde all). Eikä minulla ole tuota MX sitä ennen, mitä se tarkoittaa tuossa yhteydessä?

 

[Aladdin Sane]

Omien kokemusten mukaan ainoastaan Microsoftin kanssa on joskus ollut ongelmia uusien domainien kanssa. Kaikkialle muualle on sähköpostit menneet hyvin perille, kunhan asetukset on kunnossa.

Minulla taisi ihan eka testiposti omalle gmaille mennä myös roskapostiin mutta en kyllä tarkalleen, että mitä parametrit silloin oli käytössä DNS:n osalta. Nyt näillä nykyasetuksilla menee viestit sinne ihan ok.

Kyllä. Jos haluaa pelata varman päälle, niin policyksi none ja joku raportointipalvelu käyttöön joksikin aikaa. Kun näyttää siltä, että asetukset on kunnossa, niin sitten reject käyttöön. Tosi koska kyse on nyt varsin pienistä sähköpostimääristä ja yksityiskäyttöön tarkoitetusta meilistä, en tästäkään hirveästi stressiä ottaisi, suoraan rejectille vaan.

OK.

Osaatko sanoa mikähän tuo Cloudflaren generoima emaili osoite raporteille mahtaa olla? Se siis tuon alla olevan teki omaani ja siinä tuo *-merkitty on jokin 32 merkkinen. Minulla ei mitään hajua mihin nuo päätyy.


Listaan tähän nyt mitä minulla on tällä hetkellä Cloudflaren DNS-recordeissa. Ja selvennyksenä vielä kerran, että sähköpostipalvelu on iCloudissa.
Näyttääkö tuo siltä, että on kaikki oikein oletuksena, että itse lähetän mailit iCloud SMTP:n kautta aina?

CNAME sig1.domainkey sig1.dkim.******.**.at.icloudmailadmin.com (*=oma domain)

MX ******.** mx02.mail.icloud.com (*=oma domain)

MX ******.** mx01.mail.icloud.com (*=oma domain)

TXT _dmarc v=DMARC1; p=reject; pct=100; rua=mailto:***************************@dmarc-reports.cloudflare.net; ruf=mailto:*********************@dmarc-reports.cloudflare.net; fo=1; adkim=s; aspf=s; sp=reject (*=Cloudflaren generoima merkkisarja, ei mitään käryä minne nuo viestit edes menee)

TXT ******.** v=spf1 include:icloud.com -all (tästä muutin itse "all" edessä tildestä miinusmerkiksi!!)

TXT ******.** apple-domain=********** (tässä ******.**=oma domain ja lopussa oleva *=jokin Applen automaattisesti generoima merkkisarja).

TTL:t on kaikissa 1h paitsi DMARCin kohdalla AUTO.


Tämä oli se minkä iCloud oletuksena loi ensiksi.
CNAME sig1.domainkey sig1.dkim.******.**.at.icloudmailadmin.com (*=oma domain)

MX ******.** mx02.mail.icloud.com (*=oma domain)

MX ******.** mx01.mail.icloud.com (*=oma domain)

TXT ******.** v=spf1 include:icloud.com ~all

TXT ******.** apple-domain=********** (tässä ******.**=oma domain ja lopussa oleva *=jokin Applen automaattisesti generoima merkkisarja).

 

[jad]

Osaatko sanoa mikähän tuo Cloudflaren generoima emaili osoite raporteille mahtaa olla?

Kun kytket CF:ssä DMARC Managementin päälle, se luo sinulle (domainille) yksilöllisen reporting- sähköpostiosoitteen ja CF sittentulkkaa saapuneer raportit tilastoiksi sinne DMARC Management osioon. Samaan tapaan kuin tuossa yllä @fin_modder:n käyttämä urireports.com palvelu. Noita DMARC raportteja kun ei ole tarkoitettu ihmisen luettavaksi, niin turha sinne on mitään omaa sähköpostiosoitetta laittaa.

TTL:t on kaikissa 1h paitsi DMARCin kohdalla AUTO.

Itse olen aina CF:ssä käyttänyt Auto- asetusta TTL:nä. Eihän tuolla toimntaan ole vaikutusta, mutta leviääpä muutokset maailmalle nopeammin jos jotain tulee muutettua.

 

[Algron28]

Niinpä, ja eikö se ettei käyttäisi oman email palvelun tarjoajan SMTP:tä lähettämiseen riskeeraa senkin, että oma email osoite päätyy johonkin spämmilistalle? En nyt itse keksi mitään pätevää syytä olla käyttämättä oman emailin tarjoajan SMTP:tä milloinkaan.


Ei ainakaan omalla kohdalla mail.inet.fi ole enää arviolta viimeiseen 10-15 vuoteen sallinut lähettää emailia muiden kuin heidän pp.inet.fi osoiteesta vaikka käyttö heidän liittymän kautta luonnollisesti. Tämä siis normi emaileille jotka on jonkun toisen palveluntarjoajan kautta, jolloin ei dns-asetuksia ole luonnollisesti itselle määritelty samaan tapaan kuin nyt omalla domainilla (en ole sillä enää edes kokeillut käyttää Telian SMTP:tä koska voin kirjautua iCloudin lähettävän postin palvelimeen omalta domainilta postaillessa).

Kyllä ainakin itsellä on toiminut mail.inet.fi kun tuo on käytössä erilaisissa laitteissa hälytys sähköpostien väylänä. Noissahan lähettäjä on ihan tuulesta temmattu.

 

[Aladdin Sane]

Kun kytket CF:ssä DMARC Managementin päälle, se luo sinulle (domainille) yksilöllisen reporting- sähköpostiosoitteen ja CF sittentulkkaa saapuneer raportit tilastoiksi sinne DMARC Management osioon. Samaan tapaan kuin tuossa yllä @fin_modder:n käyttämä urireports.com palvelu. Noita DMARC raportteja kun ei ole tarkoitettu ihmisen luettavaksi, niin turha sinne on mitään omaa sähköpostiosoitetta laittaa.

OK, vähän tuollaista arvailinkin, että tuo on joku uudelleenohjaus. Ei olisi tullut mieleenkään tuonne omaa oikeata sähköpostiosoitetta antaa, kun sehän näkyy kaikille, kun tietää millä sen voi sieltä kaivaa. Jännä, että tuo Cloudflaren wizard riippuen mistä valikosta sen ajaa, niin joko ehdottaa tuota "uudelleenohjausosoitetta" tai omaa oikeaa osoitetta.

Näyttikö tuo minun käytössä oleva DNS-konffaus nyt ihan passelilta sinusta, että tuota ei kannattaisi alkaa löysäämään tai palauttamaan iCloudin oletukselle? Eli nyt siellä pitäisi olla SPF päällä (ja joka huolii viestini vain iCloudin SMTP:ltä lähetettynä käsittääkseni), DKIM jonka ohjaa iCloudin hanskattavaksi ja lopuksi DMARC näille. Ainakin Gmail kuittaa, että nuo kaikki 3 on PASS kun omalle testitilille lähettää viestin.

Itse olen aina CF:ssä käyttänyt Auto- asetusta TTL:nä. Eihän tuolla toimntaan ole vaikutusta, mutta leviääpä muutokset maailmalle nopeammin jos jotain tulee muutettua.

OK, hyvä tietää. Annan olla tuolla oletuksella.

 

[Aladdin Sane]

Kyllä ainakin itsellä on toiminut mail.inet.fi kun tuo on käytössä erilaisissa laitteissa hälytys sähköpostien väylänä. Noissahan lähettäjä on ihan tuulesta temmattu.

Onpa outoa, mistä lie sitten johtui, että heitti toimimasta minulla. Kauan sitten oli itselläkin aina käytössä ISP:n SMTP kaikille muillekin sähköposteille. Ei tosin ole tullut enää itse kokeiltuakaan sitä tuon jälkeen, kun konffaan (tai kun sähköpostiohjelman wizardilla ottaa tilin käyttöön) käyttämään kyseisen sähköpostiosoitteen domainin SMTP:tä. Vähän turhan helpoksi lähettäjän sähköpostiosoitteen väärentäminen on edelleen kyllä tehty, kun kerran vieläkin sallii lähetyksen mistä tahansa osoitteesta...

 

[fin_modder]

Miten tuossa sinulla voi DMARC olla toimiva, kun DKIM määritystä ei ole lainkaan DNS-recordeissa?

Muuten nuo sinun käytössä olevat asetukset on melko lailla identtiset omieni kanssa paitsi, että minulla on DKIM sinne määriteltynä. Minulla tosin tuossa SPF:ssä on -all (ei tilde all). Eikä minulla ole tuota MX sitä ennen, mitä se tarkoittaa tuossa yhteydessä?

Moi,

DNS cnamessa on
protonmail._domainkey.domain.fi -> protonmail.domainkey.xxxx.domains.proton.ch

Unohtui näköjään omasta viestistä.

 

[Aladdin Sane]

Tutkailin hieman mitä spämmifiltterit omasta domainista tykkää.
Jotain häikkää SPF:n kanssa joltain osin näköjään on: SPF_HELO_NONE SPF: HELO does not publish an SPF Record. Mitähän tuolla DNS-recordeissa vielä pitäisi olla, että tuosta pääsee eroon?
Tämä on nyt DNS-recordeissani: TXT ******.** v=spf1 include:icloud.com -all (*=oma domain).
Tässä viestissäni näkyy kaikki DNS-asetukseni listattuna: https://bbs.io-tech.fi/threads/doma...velut-asetukset-jne.9118/page-5#post-12529368

Toiseksi uusi domain on melkoinen ongelma, 1.5 pistettä miinusta spämmifiltteriin tulee pelkästään siitä, että on alle 7 vrk vanha domain, eli vahvasti spämmiä tuolla perusteella pelkästään.

 

[jad]

Tutkailin hieman mitä spämmifiltterit omasta domainista tykkää.
Jotain häikkää SPF:n kanssa joltain osin näköjään on: SPF_HELO_NONE SPF: HELO does not publish an SPF Record. Mitähän tuolla DNS-recordeissa vielä pitäisi olla, että tuosta pääsee eroon?

Tähän kaivataan hieman lisää tietoa ennen kun voi sanoa mitään. Miten testasit ? Millä työkalulla ?

 

[Aladdin Sane]

Tähän kaivataan hieman lisää tietoa ennen kun voi sanoa mitään. Miten testasit ? Millä työkalulla ?

Se oli joku näistä testereistä, mitä googlettaessa löysin mutta hitto kun ei tullut otettua ylös, että mikä niistä, mutta se testi mittasi Spamassasin tulosta. Kirjasin vain virheilmoitukset. Joka tapauksessa se "HELO" virhe, jonka tuossa mainitsin on aika lähellä identtinen mitä tässä ketjussa on kuvassa ympyröitynä jollain toisella: https://stackoverflow.com/questions...-helo-publish-an-spf-record-spf-helo-none-spf

En ihan vain tuosta hoksannut, että miten tuo pitäisi iCloud custom domainin kanssa määritellä, että tulisi kuntoon. Sanooko tuo sinulle mitään?

 

[jad]

Se oli joku näistä testereistä, mitä googlettaessa löysin mutta hitto kun ei tullut otettua ylös, että mikä niistä, mutta se testi mittasi Spamassasin tulosta. Kirjasin vain virheilmoitukset. Joka tapauksessa se "HELO" virhe, jonka tuossa mainitsin on aika lähellä identtinen mitä tässä ketjussa on kuvassa ympyröitynä jollain toisella: Email DNS Setup: How do I make HELO publish an SPF record? SPF_HELO_NONE - SPF: HELO does not publish an SPF Record

En ihan vain tuosta hoksannut, että miten tuo pitäisi iCloud custom domainin kanssa määritellä, että tulisi kuntoon. Sanooko tuo sinulle mitään?

Tuohon et itse voi vaikuttaa. Kyse on SMTPprotokollan mukaisesta kättelystä, jonka iCloudin palvelin tekee lähettäessään sähkpostiasi eteenpäin.
SMTP on tekstipohjainen protokolla ja sähkpostin lähetyksessä ensimmäinen asia mitä lähettävä palvelin kertoo vastaanottajalle on:

HELO <lähettävän palvelimen nimi/domain>

Jos sinulla olisi oma sähköpostipalvelin niin tuo kättely alkaisi näin:

HELO omadomain.com

Mutta koska kyseessä on iCloud jolla on suuri määrä postia lähettäviä palvelimia, joilla todennäköisesti on domainnimenä jotain "qwer-321-asdf-123-asdf.eu.icloud.com" tyylistä, eikä näillä teknisillä domainnimillä ikinä lähetetä sähköpostia, ei näille myöskään ole määritelty SFP tietueita.

Ja kuten tuossa stackoverflown kuvassakin, tuosta puuttuvasta SPF:stä spamassasin sakotttaa 0,001 pistettä, mikä on täysin mitätön ja lienee olemassa lähinnä jotain diagnostiikkaa varten.

EDIT: mail-tester.com:iin gmail osoitteesta lähetettäessä tulee luonnollisestikin sama SPF_HELO_NONE

 

[Aladdin Sane]

Tuohon et itse voi vaikuttaa. Kyse on SMTPprotokollan mukaisesta kättelystä, jonka iCloudin palvelin tekee lähettäessään sähkpostiasi eteenpäin.
SMTP on tekstipohjainen protokolla ja sähkpostin lähetyksessä ensimmäinen asia mitä lähettävä palvelin kertoo vastaanottajalle on:

HELO <lähettävän palvelimen nimi/domain>

Jos sinulla olisi oma sähköpostipalvelin niin tuo kättely alkaisi näin:

HELO omadomain.com

Mutta koska kyseessä on iCloud jolla on suuri määrä postia lähettäviä palvelimia, joilla todennäköisesti on domainnimenä jotain "qwer-321-asdf-123-asdf.eu.icloud.com" tyylistä, eikä näillä teknisillä domainnimillä ikinä lähetetä sähköpostia, ei näille myöskään ole määritelty SFP tietueita.

Ja kuten tuossa stackoverflown kuvassakin, tuosta puuttuvasta SPF:stä spamassasin sakotttaa 0,001 pistettä, mikä on täysin mitätön ja lienee olemassa lähinnä jotain diagnostiikkaa varten.

EDIT: mail-tester.com:iin gmail osoitteesta lähetettäessä tulee luonnollisestikin sama SPF_HELO_NONE

OK. Jotenkin ajatuksissani luin tuon -0,1:ksi mutta sehän onkin aivan marginaalinen 0,001.
SInänsä jännä, että varsinainen SPF oli kyllä testin mukaan kunnossa, se oli vain tuo "HELO" juttu mistä pikku miinus mutta tosiaan eipä tuolle sitten tarvi mitään tehdä.

Ajelin testejä vielä omille Gmail ja Outlook tileille, ja Gmailiin menee edelleen hienosti läpi ja se myös viestin tietoja katsoessa kuittaa, että DKIM, SPF and DMARC kaikki on PASS. Mutta Outlook taas pisti postini suoraan roskapostiksi, vaikka olin jo joku päivä aiemmin tuon saman tempun jälkeen siirtänyt roskapostista saapuneisiin ja tarkistanut, että uusi viesti heti sen jälkeen meni saapuneisiin mutta ei ollut pitkäaikainen korjaus. Tällä kertaa laitoin kokeeksi tuon raportoi "ei roskapostia", katsotaan mitä tuo parin päivän päästä tekee. Mikähän tuolla Outlookissa kaihertaa? Samaten tuossa perheenjäsen laittoi kokeeksi omaan työpostiin viestin ja sekin meni siellä roskapostiksi... Onko tuo domainin ikä niin suuri tekijä sitten lopulta?

Onkohan tästä listaa miten Spamassasin ja vastaavat antaa miinupisteitä domainin iän perusteella, että missä vaiheessa sen vaikutus on 0 vai voi olla jopa positiivinen? Alle 7 vrk domain ainakin oli -1,5 pistettä.

Oikein mitään muuta vikaa en onnistu löytämään tuosta, paitsi jostain syystä ajoin Blacklist tarkistusta vielä niin kaikki paitsi yksi näytti vihreää. Sellainen kuin Hostkarma on sitä mieltä, että oma domain on "keltainen". Mikähän tuon tekee? Oma domain on ihan uusi, ei ole siis ollut kellään aiemmin käytössään ja sillä ei ole sikailtu mitenkään. Vetääkö tuo ihan domainin iän mukaan keltaiseksi vai tekeekö tuossa se iCloud välissä, että on epäilyttävä sen mielestä?


Katselin myös Cloudflaren raportteja, ja nyt oli DMARCista tullut jo eka. Se kertoo, että Apple INC on "unapproved" ja että siitä olisi Google.com raportoinut. Silti samalla se näyttää tälle, että DMARC Pass 100%, SPF aligned 100%, DKIM aligned 100%, eli kaikkihan pitäisi olla kunnossa? Mutta silti Google raportoinut!?!? Tuossa antaa itselleni vaihtoehdoksi "Mark as approved", oletanko oikein, että se kannattaa merkata approved? Samaisen työkalun Approved kohdan listalla ei näy mitään, mikä on kyllä myös vähän outoa mielestäni, siis ainoastaan siella unapproved kohdassa on tuo yksi.

 

[jad]

Mikähän tuolla Outlookissa kaihertaa? Samaten tuossa perheenjäsen laittoi kokeeksi omaan työpostiin viestin ja sekin meni siellä roskapostiksi... Onko tuo domainin ikä niin suuri tekijä sitten lopulta?

Outlookissa kaihertaa Microsoft Oliko tuo työposti myös Microsoftilla ?

Sapmassasinin säännöistä:

describe   FROM_FMBLA_NEWDOM    From domain was registered in last 7 days
score      FROM_FMBLA_NEWDOM    1.5 # limit

describe   FROM_FMBLA_NEWDOM14  From domain was registered in last 7-14 days
score      FROM_FMBLA_NEWDOM14  1.0 # limit

describe   FROM_FMBLA_NEWDOM28  From domain was registered in last 14-28 days
score      FROM_FMBLA_NEWDOM28  0.8 # limit

Eli 28 päivää vanha domain ei enää saa spam-pisteitä. Todennäköisesti jotain samankaltaista on Microsoft- posteissa ja aika korjaa ongelman.

Oikein mitään muuta vikaa en onnistu löytämään tuosta, paitsi jostain syystä ajoin Blacklist tarkistusta vielä niin kaikki paitsi yksi näytti vihreää. Sellainen kuin Hostkarma on sitä mieltä, että oma domain on "keltainen". Mikähän tuon tekee?

Types of Listings

Yellow Listing - For Google, Outlook, Hotmail, Yahoo - IP contains no useful information.
Domain Age - If the host name is familiar or not. Can be used to catch spammers using newly registered domains

Katselin myös Cloudflaren raportteja, ja nyt oli DMARCista tullut jo eka. Se kertoo, että Apple INC on "unapproved" ja että siitä olisi Google.com raportoinut. Silti samalla se näyttää tälle, että DMARC Pass 100%, SPF aligned 100%, DKIM aligned 100%, eli kaikkihan pitäisi olla kunnossa? Mutta silti Google raportoinut!?!? Tuossa antaa itselleni vaihtoehdoksi "Mark as approved", oletanko oikein, että se kannattaa merkata approved? Samaisen työkalun Approved kohdan listalla ei näy mitään, mikä on kyllä myös vähän outoa mielestäni, siis ainoastaan siella unapproved kohdassa on tuo yksi.

DMARC raporteissa on dataa myös toimivista konfiguraatioista. Eli Google on raportoinut ottaneensa domainistasi vastaan sähköposteja ja niistä 100% on ollut kunnossa. Tuolla Cloudflaren Approved/Unapproved ei ole mitään toimintaan vaikuttavaa merkitystä.
Se vaikuttaa vain noihin CF:n tilastointeihin ja käppyröihin. Ja tämän takia se Approved on oletuksena tyhjä, kun ei CF voi tietää mistä kaikkialta sinä sähköposteja lähetät omalla domainillasi.

 

[Aladdin Sane]

Outlookissa kaihertaa Microsoft Oliko tuo työposti myös Microsoftilla ?

Tuosta ei ole tarkemmin tietoa, kenen systeemeissä työposti pyörii eikä osoitteen nimestä sen kummemmin sitä näe.
Tuo mikkisofta kyllä jaksaa aina yllättää, on ihan vitusti tullut itselle vanhaan omaan emailiin roskapostia @outlook.comista.

Sapmassasinin säännöistä:

describe   FROM_FMBLA_NEWDOM    From domain was registered in last 7 days
score      FROM_FMBLA_NEWDOM    1.5 # limit

describe   FROM_FMBLA_NEWDOM14  From domain was registered in last 7-14 days
score      FROM_FMBLA_NEWDOM14  1.0 # limit

describe   FROM_FMBLA_NEWDOM28  From domain was registered in last 14-28 days
score      FROM_FMBLA_NEWDOM28  0.8 # limit

Eli 28 päivää vanha domain ei enää saa spam-pisteitä. Todennäköisesti jotain samankaltaista on Microsoft- posteissa ja aika korjaa ongelman.

OK, eli about kuukausi niin on kunnossa tuoltakin osin. Ei onneksi mennyt tämäkään viime tippaan, kun tuo oma Telian sähköposti jää pois ensi kuun loppupuolella.

DMARC raporteissa on dataa myös toimivista konfiguraatioista. Eli Google on raportoinut ottaneensa domainistasi vastaan sähköposteja ja niistä 100% on ollut kunnossa. Tuolla Cloudflaren Approved/Unapproved ei ole mitään toimintaan vaikuttavaa merkitystä.
Se vaikuttaa vain noihin CF:n tilastointeihin ja käppyröihin. Ja tämän takia se Approved on oletuksena tyhjä, kun ei CF voi tietää mistä kaikkialta sinä sähköposteja lähetät omalla domainillasi.

OK, eli Googlen puolelta kaikki on hyväksytty. Hyvä homma siltä osin. Eli nuo voi itselleen halutessaan kirjata approved niin tulee tilastoissa oikeaan paikkaan.

 

[fin_modder]

Tämä outlook ongelma on ihan normaalia, tykkäävät heittää spämmiin posteja ihan vaan sen takia että "tekoäly" keksi niin.
Mikään SPF tai muukaan asia ei korjaa tätä.
Eli vaikka viestisi olisi teknisesti lähetetty oikein, outlook merkkaa sen spämmiksi, tai pahimmassa tapauksessa poistaa suoraan ilman mitään ilmoitusta -> Outlook.com is silently discarding email messages

Googlesta voi katsoa esim hakusanoilla outlook mail going to spam site:news.ycombinator.com tai outlook mail going to spam site:old.reddit.com, löytyy tuhansia artikkeleita ja kommentteja siitä kuinka jopa Outlookin omia viestejä merkataan spämmiksi.

Silti esim oma google sekä outlook tilini saa enemmän spämmiä kuin omalla domainilla protonmail ikinä .

 

[jad]

Tuosta ei ole tarkemmin tietoa, kenen systeemeissä työposti pyörii eikä osoitteen nimestä sen kummemmin sitä näe.

Vaikkapa tällä MX Lookup Tool - Check your DNS MX Records online - MxToolbox työnantajan domain hakuun. Mikäli MX:nä on <domain>.mail.protection.outlook.com niin käytössä on Microsoft postit. Ja muussa tapauksessa voi sherlokoida esim. MX:n ip-osoitteen perusteella operaattoria jos haluaa sevitellä.

 

[Aladdin Sane]

DMARC raporteissa on dataa myös toimivista konfiguraatioista. Eli Google on raportoinut ottaneensa domainistasi vastaan sähköposteja ja niistä 100% on ollut kunnossa. Tuolla Cloudflaren Approved/Unapproved ei ole mitään toimintaan vaikuttavaa merkitystä.
Se vaikuttaa vain noihin CF:n tilastointeihin ja käppyröihin. Ja tämän takia se Approved on oletuksena tyhjä, kun ei CF voi tietää mistä kaikkialta sinä sähköposteja lähetät omalla domainillasi.

Kävin uudemman kerran ihmettelemässä tätä DMARC "unapproved" kohtaa ja nyt siellä oli toinen samanlainen Google.com raportoima, jossa kaikki oli hyväksytty. Ajattelin laittaa nyt sinne "approved" listalle mutta kun tuota alkaa tehdä Cloudflare ilmoittaa tällaista "
Mark as approved
If this is a trusted source, you can mark it as approved and the source will be added to the SPF record automatically."
Ja tuossa oli pitkä lista ip-osoitteita (yli 10). Siis meinaako tuo lisätä nuo todellakin omiin DNS recordeihin, jos sen tekee, vai mihin se nuo lisää? En vielä rohjennut kokeilla mitä tapahtuu.

EDIT:
Tästä löytyi jotain ohjetta Cloudlfarelta.
Manage sources · Cloudflare DMARC Management docs
Tulkitsenko oikein, että nuo kaikki IP:t pitäisi todellakin liittää omiin DNS-recordeihin, ja oikeastaan vasta sitten, kun kaikki mahdolliset sallittujen lähettäjien IP:t on omissa DNS-recordeissa niin _vasta sitten" DMARC policy olisi syytä laittaa quarantine tai reject tilaan? Minulla nuo on olleet jo nyt reject tilassa.
Mitenhän tähän pitäisi suhtautua?

Tarkistin vielä tuon listan IP:stä, niin se ehdottaisi lisättäväksi 19 kpl omiin SPF recordeihin, siis ihanko oikeasti se lisäisi ne kaikki omiin DNS-recordeihin SPF kohtaan vai meneekö nuo johonkin ihan muualle?
Voiko se olla, että DNS-recordeissa pitäisi olla tämän tyylinen lista mitä täällä antaa : https://securitytrails.com/ , kun laittaa hakukenttään iCloud.com?
Tuossa aika lailla samanlainen määrä IP:tä mutta siinä ei iCloud.com ole nimellä listattuna lainkaan!?!?. Nythän minulla on tuo DNS:n SPF rivi vain näin: TXT ******.** v=spf1 include:icloud.com -all (*=oma domain nimi. Tästä muutin itse "all" edessä tildestä miinusmerkiksi!!).

 

[Aladdin Sane]

Vaikkapa tällä MX Lookup Tool - Check your DNS MX Records online - MxToolbox työnantajan domain hakuun. Mikäli MX:nä on <domain>.mail.protection.outlook.com niin käytössä on Microsoft postit. Ja muussa tapauksessa voi sherlokoida esim. MX:n ip-osoitteen perusteella operaattoria jos haluaa sevitellä.

Outlook se sielläkin näyttää hääräilevän, eipä se sitten ollut ihme.

 

[jad]

Mark as approved
If this is a trusted source, you can mark it as approved and the source will be added to the SPF record automatically."
Ja tuossa oli pitkä lista ip-osoitteita (yli 10). Siis meinaako tuo lisätä nuo todellakin omiin DNS recordeihin, jos sen tekee, vai mihin se nuo lisää? En vielä rohjennut kokeilla mitä tapahtuu.

Tuo CF:n DMARC työkalu tosiaan on vielä beta vaiheessa. Näköjään se ei tällä hetkellä tunnista sitä, että nuo iCloud:n ip-osoitteet jo on SPF:ssä include:icloud.com:n ansiosta. En itsekään ole vielä kovin kauaa tuota käyttänyt, mutta aiemmin kun olen klikannut lähettäjän luotetuksi, on ip-osoitteiden lista siinä approve- dialogissa ollut tyhjä, eikä CF ole lisännyt mitään SPF:ään.

Nyt kun kokeilin yhdellä domainilla lisätä Microsoftin approved- listalle, CF listasi pitkän listan ip-osoitteita ja approven jälkeen CF lisäsi SPF:ään include:_spfcf1.example.com include:_spfcf2.example.com include:_spfcf3.example.com (numeroon 6 asti)
sekä nuo samat _spfcf1 - 6 TXT tietueet, joissa sitten listattuna ne kaikki Microsoftin ip-osoitteet. Tämä oli täysin turha operaatio, sillä alkuperäisessä spf:ssä jo oli include:example-com.mail.protection.outlook.com joka nuo samat ip:t jo sisältää. Eli hieman tuo nyt bugittaa.

Tulkitsenko oikein, että nuo kaikki IP:t pitäisi todellakin liittää omiin DNS-recordeihin, ja oikeastaan vasta sitten, kun kaikki mahdolliset sallittujen lähettäjien IP:t on omissa DNS-recordeissa niin _vasta sitten" DMARC policy olisi syytä laittaa quarantine tai reject tilaan? Minulla nuo on olleet jo nyt reject tilassa.
Mitenhän tähän pitäisi suhtautua?

include:icloud.com kattaa koko ip-listan. Voit hyin pistää DMARC:n jo quarantinelle tai rejectille, koska ei sillä sinun domainillasi lähtetä sähköposteja muuta kun iCloudin kautta. CF:n ohjeistus on siksi noin, että isommassa organisaatiossa sähköposteja voidaan lähetellä mitä erilaisimmista palveluista (CRM,ERP,...) ja siksi on parempi ensin laittaa policy nonelle ja kerätä dataa. Ja vasta sitten kun kaikki mahdolliset sähköpostin lähettäjät on tunnistettu ja lisätty SPF:ään, niin vaihtaa policyn rejectille tai quarantinelle.

 

[Aladdin Sane]

Nyt kun kokeilin yhdellä domainilla lisätä Microsoftin approved- listalle, CF listasi pitkän listan ip-osoitteita ja approven jälkeen CF lisäsi SPF:ään include:_spfcf1.example.com include:_spfcf2.example.com include:_spfcf3.example.com (numeroon 6 asti)
sekä nuo samat _spfcf1 - 6 TXT tietueet, joissa sitten listattuna ne kaikki Microsoftin ip-osoitteet. Tämä oli täysin turha operaatio, sillä alkuperäisessä spf:ssä jo oli include:example-com.mail.protection.outlook.com joka nuo samat ip:t jo sisältää. Eli hieman tuo nyt bugittaa.


include:icloud.com kattaa koko ip-listan. Voit hyin pistää DMARC:n jo quarantinelle tai rejectille, koska ei sillä sinun domainillasi lähtetä sähköposteja muuta kun iCloudin kautta. CF:n ohjeistus on siksi noin, että isommassa organisaatiossa sähköposteja voidaan lähetellä mitä erilaisimmista palveluista (CRM,ERP,...) ja siksi on parempi ensin laittaa policy nonelle ja kerätä dataa. Ja vasta sitten kun kaikki mahdolliset sähköpostin lähettäjät on tunnistettu ja lisätty SPF:ään, niin vaihtaa policyn rejectille tai quarantinelle.

Jees, kiitti taas jälleen kerran avusta.
Vähän tuota ounastelinkin, että luulisi sen iCloudin itsensä luoma asetus olla riittävä, olisi kai ne sen ip-listan muuten jo sieltä laittaneet automaatilla, jos niin kuuluisi laittaa.

Mutta mitähän tuolla CF:ssä sitten kannattaisi tehdä? Ilmeisesti approved-listalle mitään ei voi nyt lisätä ilman, että se luo uusia tietueita DNS:ään? Antaako vain olla tekemättä mitään vai lisääkö ja sitten muokkaa DNS:n käsin takaisin entiseen? Ei kyllä hulluna huvittaisi turhaan mulkata noita, kun taitavat olla nyt juuri oikein (tuo DMARC ollut jo yli viikon "reject" valinnalla). Muutenkin on tuo CF:n sanamuoto jännä, kun tuosta saa sen käsityksen, että tuolla olisi merkitystä ja syytä tehdä mitä se ehdottaa. Mutta betahan se todellakin on, eikä liene ihan virallista versiota tarjolla?