Hmmm, ei se tarjoa kuin sitä missä lukee, että beta....
Heetkonen menitkö sä klikaamaan DNS --> Email --> DMARC Management?
Follow along with the video below to see how to install our site as a web app on your home screen.
Huomio: This feature may not be available in some browsers.
Hmmm, ei se tarjoa kuin sitä missä lukee, että beta....
Mutta onko siellä ihan loppupäässä tuo X-suspected spam ja true jossain, kun etsit sen pitkän litania joukosta?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?
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"?Ei löydy ...
Miten hemmetissä tuon proxyn saa päälle? Tuonne kun luo käsin recordia, niin ei se anna vaihtoehtoa edes sellaiselle?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.
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!?!?!
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?Ä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
Onks kokemuksia tuosta Cyber Panelista?
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?
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.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!
Meinasin sanoa saman, vähän ikävemmillä sanoilla.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).
Mitä tarkoitat tällä?Jos Cloudflarea käyttää vain DNS palveluun, voi koko palvelun laittaa pauselle. Onnistuu overview sivulta.
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)?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 .
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.Mitä tarkoitat tällä?
EiJoo, 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?
EiSamoin sanoo, että DKIM avainta ei edelleenkään ole, mutta tarviiko sitä sen kummemmin, jos se tulee iCloudin kautta, kuten vaikuttaa tekevän?
EiEntä 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)?
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.Mutta isoin ongelma, nyt esim. testiposti omalta domainilta omalle outlook.com osoittelle > meni suoraan roskapostikansioon!
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.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.
10 DNS kyselyä.- IP osoitteita voi olla rajaton määrä, DNS lookupit pitäisi olla 5 tai alle
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ä.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.
Huomasin tuon testerin mutta en rohjennut kokeilla, jos on joku spämmiä varten osoitteita keräävä. Onko tuo siis kuitenkin ihan turvallinen testi?Testatisko lähettää meiliä tuonne mail-tester palveluun, mitä se sanoi ?
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.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.
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).Tuossa Cloudflaren ohje tuohon iCloud custom domainiin.
Kuva tuosta ohjeesta.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 with your iCloud Mail account. It’s great if you want to create a custom email domain for you or your family, such as @examplefamily.com.developers.cloudflare.com
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
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.
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ä.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ä.
On ihan pätevä. Eivät myy meiliosoitettasi millekään kasinokoijarille.Huomasin tuon testerin mutta en rohjennut kokeilla, jos on joku spämmiä varten osoitteita keräävä. Onko tuo siis kuitenkin ihan turvallinen testi?
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.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.
Ei ole, mutta ei tuosta kannata kauheata stressiäkään ottaa, tuo kuitenkin on vain yksi tekijä monen muun joukossa.Onko tuossa domain reputationin ansaitsemisessa mitään oikotietä?
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.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?
Kiitos tästä! Uriports vaikuttaa varsin pätevälle ja kohtuuhintaiselle palvelulle verrattuna dmarcian.com ja dmarcly.com:iin.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
Mutta tuonhan voi kiertää kirjautumalla siihen oikeaan SMTP-palvelimeen.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ä.
Jos se tuolla periaatteella on toteutettu, niin eipä ihme, jos viestejä jää välille.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.
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.
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.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.
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).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ä.
Miten tuossa sinulla voi DMARC olla toimiva, kun DKIM määritystä ei ole lainkaan DNS-recordeissa?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.
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.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.
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.
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.Osaatko sanoa mikähän tuo Cloudflaren generoima emaili osoite raporteille mahtaa olla?
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.TTL:t on kaikissa 1h paitsi DMARCin kohdalla AUTO.
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.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).
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.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, hyvä tietää. Annan olla tuolla oletuksella.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.
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...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.
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ä?
Tähän kaivataan hieman lisää tietoa ennen kun voi sanoa mitään. Miten testasit ? Millä työkalulla ?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?
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-spfTähän kaivataan hieman lisää tietoa ennen kun voi sanoa mitään. Miten testasit ? Millä työkalulla ?
Tuohon et itse voi vaikuttaa. Kyse on SMTPprotokollan mukaisesta kättelystä, jonka iCloudin palvelin tekee lähettäessään sähkpostiasi eteenpäin.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?
HELO <lähettävän palvelimen nimi/domain>
HELO omadomain.com
OK. Jotenkin ajatuksissani luin tuon -0,1:ksi mutta sehän onkin aivan marginaalinen 0,001.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:
Jos sinulla olisi oma sähköpostipalvelin niin tuo kättely alkaisi näin:Koodi:HELO <lähettävän palvelimen nimi/domain>
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.Koodi:HELO omadomain.com
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
Outlookissa kaihertaa Microsoft Oliko tuo työposti myös Microsoftilla ?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?
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
Types of ListingsOikein 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?
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
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ä.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.
Tuosta ei ole tarkemmin tietoa, kenen systeemeissä työposti pyörii eikä osoitteen nimestä sen kummemmin sitä näe.Outlookissa kaihertaa Microsoft Oliko tuo työposti myös Microsoftilla ?
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.Sapmassasinin säännöistä:
Eli 28 päivää vanha domain ei enää saa spam-pisteitä. Todennäköisesti jotain samankaltaista on Microsoft- posteissa ja aika korjaa ongelman.Koodi: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
OK, eli Googlen puolelta kaikki on hyväksytty. Hyvä homma siltä osin. Eli nuo voi itselleen halutessaan kirjata approved niin tulee tilastoissa oikeaan paikkaan.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.
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ä.Tuosta ei ole tarkemmin tietoa, kenen systeemeissä työposti pyörii eikä osoitteen nimestä sen kummemmin sitä näe.
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 "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.
Outlook se sielläkin näyttää hääräilevän, eipä se sitten ollut ihme.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ä.
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ä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.
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.include:_spfcf1.example.com include:_spfcf2.example.com include:_spfcf3.example.com
(numeroon 6 asti)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.Jees, kiitti taas jälleen kerran avusta.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:ääninclude:_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 oliinclude: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.