bloghoved sidsel jensen

BIMI up Scotty

Her i mail-land har der i denne uge været en del fokus på “Brand Indicators for Message Identification” eller forkortet BIMI. Det skyldtes at Google meldte ud, at de starter en limited trial i Gmail. Tidligere har det primært været Yahoo! Mail, der har forsøgt sig.

Det er ikke nemt for folk at identificere f.eks. spoofet mail og phishing - “Er denne her mail nu også fra Netflix/Paypal eller ej”? og BIMI er derfor sat i verden udfra en tanke om at det skal være nemt visuelt at identificere oprindelsen af en mail - og BIMIs primære feature er visningen af et firma logo ved siden af mailen - en “avatar”. Derudover bygger den ovenpå DMARC (som igen kræver SPF og DKIM). Så man skal have en fuldt udrullet DMARC i form af p=quarantine eller p=reject - som giver dig spoofing beskyttelsen.

Hvordan virker BIMI:

0) Sørg for at have et ordentligt .svg logo
1) Du skal have SPF, DKIM og DMARC sat op og ikke noget med pct<100 i dine DMARC tags.
2) Du tilføjer en ekstra TXT DNS record og kalder den f.eks. default._bimi. Den skal indeholde 2 tags v=BIMI1 og l= (ikke et i men et lowercase L) https link til en svg fil af dit logo
3) Du kan også tilføje et 3. optional tag a= som er et link til trust authority - for at validere domæne ejerskabet

Det ser så sådan her ud:

default._bimi.brand.com IN TXT "v=BIMI1; l=https://subdomain.brand.com/image/logo.svg; a=https://subdomain.brand.com/vmc/logo.pem;"

og her er netop et af problemerne med BIMI - det bringer i den grad Certificate Authorities ind i varmen - for nogen skal jo lave en validering af, at du har ret til benytte lige præcis DET logo. Uden at være alt for ond, kan man sige at der ihvertfald har været et par sager hvor de har udstedt ceritifikater til de forkerte entities….Gmail har i deres trial teamet op med Entrust Datacard and DigiCert.

og hvad så med abuse-delen spørger du sikkert dig selv - Det er jo aldrig hørt før, at nogen opretter lookalike domæner og misbruger…eller noget ahem. Jeg havde en længere Twitter snak med Jim Fenton (RFC forfatter til rfc8689 - SMTP Require TLS option), som tørt påpegede, at det kunne da godt være, at jeg syntes at lookalike domæner var svære at håndtere - men hvad så med små subtile ændringer i et logo? For mens en domæne-ejer godt kan få taget et lookalike domæne ned eller få det listet som “untrustworthy”, hvad gør man så med et “ligner-næsten-logo” som er hosted i et helt andet retsområde?

og hvad så med Privacy? Vi kender kender alle til de små tracker-pixels. Vil visningen af logoet ikke give “inbox tracking”. Svaret er umiddelbart nej - tanken er man opsætter en proxy og en cache lokalt. Dvs. logo hentes kun til cachen og fra cachen til inboxen - som i “fetch once - show many”. Men den strategi virker typisk ikke for MUAs.

...men hvad så med alle IMAP klienterne (MUAs)? Det er helt tydeligt at BIMI primært er tænkt til Webmail løsninger, hvor det er nemmere at skræddersy visningen af $bigcorps logo. Lige pt. er det vist kun Thunderbird, der har noget support for visning af logoer, så der er lang vej endnu. Men faktum er at størstedelen af mail idag læses fra folks telefoner og en meget meget stor del af mail læses gennem IMAP klienter, så måske er næste skridt en standardiseret form for visning af avatars på tværs af MUAs? For der er helt sikkert en del “marketeers” der klapper i deres hænder over muligheden for bedre “brand-placement”.

Den anden side af dette handler om det rent menneskelige - hvad sker der hvis vi begynder at træne folk til at stole på logoet fremfor deres sunde fornuft i forhold til afsender adresser? Kig bare på hvor DÅRLIGE folk er til at gennemskue unicode confusables. Jeg tror ikke den problemstilling bliver nemmere med små nedskalerede logoer. Jeg er umiddelbart bange for, at vi får skabt flere problemer, end vi løser med BIMI. Essentielt er BIMI “exclusive-by-principle” - hele pointen er at kun få logo’er vises, men når man kommer fra et land der primært består af SMV’er så synes jeg umiddelbart at det er et trist udgangspunkt og jeg så rigtig gerne en anden løsningsmodel end BIMI.

Hvis jeg skal sige en pæn ting om BIMI, så må det være at det måske kan være medvirkende til at drive adaptions raten på DMARC opad og den kunne vitterligt godt bruge et boost op af.

Lige nu er BIMI ikke en standard. Rygtet vil vide at der er så betragtelig meget kontrovers om denne foreslåede standard at IETF har valgt IKKE at lægge den ind i deres IETF standards track eller aktiviteter - så derfor er den lige nu “kun” en industri-sammenslutning.

Man kan læse mere om BIMI på https://bimigroup.org/all-about-bimi/

Hvad tænker I om BIMI?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Benny Amorsen

DMARC er til brug for transaktions-domæner som ikke bruges til almindelig person-til-person mail.

Se f.eks. https://mailarchive.ietf.org/arch/msg/dmarc/GNN4iO5FxpaxhlAEoZ8iI0arE4U/

"Nogen" har så besluttet at aktivere DMARC for almindelige domæner også. Det betyder så at deres brugere ikke kan sende mails til mailinglister eller gennem mail-forward.

Heldigvis er "nogen" stort set begrænset til Yahoo/AOL. De havde ikke styr på deres serversikkerhed, og derfor bliver deres mailadresser i stor stil misbrugt. Omkostningerne ved at håndtere indbruddene forsøger de så at vælte over på alle os andre ved at sætte en DMARC-politik. De andre store mail-udbydere bruger stort set ikke DMARC.

Gmail mv. ignorerer også p=quarantine eller p=reject hvis de har andre grunde til at tro at mailen er legitim. Dvs. en DMARC-politik er ikke specielt effektiv i praksis.

  • 1
  • 5
#2 Claus Eriksen

Som du skriver lyder det jo meget fint - hvis man kun bruger webmail.

Ordentlig udbredelse af DMARC vil derimod være en super god ting (ja, mailinglists er en udfordring, men kan løses) - undrer mig lidt at det ikke er lykkedes at få noget fokus på det når div. firmaer er røget i CEO-fraud. Der hører man desværre kun hvor "dygtige" de har været med backups, selvom rigtig mange af tilfældene kunne have været forhindret med DMARC.

... og please - drop den der elendige "quarantine" policy :-) none eller reject, intet andet.

  • 1
  • 1
#3 Sidsel Jensen Blogger

Jeg tror det skib er sejlet for længe siden - i forhold til at begrænse DMARC til transaktions domæner og da det pt. er bedste sikring mod spoofing, så er det et værktøj vi er nød til at sprede ud - indtil vi har noget bedre at tilbyde i værktøjskassen.

ARC løser problemet i forhold til mailinglister og det fungerer rigtigt fint. Det kan du læse mere om her: http://arc-spec.org/ - at der så er nogen der er så fjollede, så de nøjes med at sætte SPF og DMARC op og glemmer DKIM i stakken og derved får forwards til at fejle, det må de selv rode med.

Mener du seriøst at det kun er Yahoo!/AOL e-mail addresser der bliver misbrugt? Det er en illusion jeg gerne vil bringe dig ud af - alle de andre store udbydere har præcis samme problem. Så længe en service er gratis, er der nogen der vil misbruge den.

DMARC kan ikke stå alene - men effektiv det er den. Google anbefaler bla. DMARC for bedre deliverability i forhold til nyhedsbreve (https://support.google.com/mail/answer/81126?hl=en#authentication), så de ikke ender i spam-folderen.

D. 1. juli skulle staten være færdig med at implementere de tekniske minimumkrav for statslige myndigheder i Danmark der bl.a. inkluderer DMARC - meeeeen der er vist et par stykker der ikke helt er nået i mål endnu...(ref. https://dmarc.dk/).

  • 7
  • 1
#4 Benny Amorsen

ARC er en løsning på absolut ingenting. Det har 0% penetration og der er ingen tegn på at det ændrer sig. ARC er en måde alligevel at tillade "spoofede" mails selvom DMARC siger man ikke må. Det har ingen chance for at virke.

Og ja, man er nødt til at lave en DMARC-record for at kunne regne med at ens mail når frem i vore dage. Det er helt fint, det er rimeligt nemt at sætte DKIM og SPF op. Man skal bare huske at sætte p=none så ens mail ikke ender i spamfoldere eller bliver smidt væk.

Heldigvis er der ingen risiko for at p=reject bliver populært. Der er alt for mange som benytter mail-forwarding til at det holder. Jeg satte for en måneds tid siden p=reject på mit domæne, men det fik jeg hurtigt lært at lade være med, efter at jeg fik rapporterne ind om hvem jeg ikke længere kunne sende til.

(Mailforwarding til Office 365 var en af de helt store syndere. Så kunne jeg ikke kommunikere med visse webshops.)

  • 1
  • 3
#5 Christian Schmidt Blogger

Det bliver let historien om EV-certifikater om igen. Før i tiden var disse nødvendige for at få en “grøn hængelås”, men i dag har de ikke længere megen relevans.

Det vil givetvis nedbringe mængden af fusk, at logoer skal være registreret som varemærke, og at SVG-filen skal verificeres af en certifikatudsteder, alene fordi det er dyrt og besværligt. Men dette vil også afholde mange legitime brugere fra at adoptere standarden, især mindre virksomheder.

Det er måske ikke nødvendigvis dårligt ud fra et sikkerhedsmæssigt perspektiv. Store virksomheder er trods alt mere udsatte for phishing end små. Men omvendt er det ikke særlig “demokratisk”, at kun store virksomheder optræder med et fint logo, mens mindre virksomheder optræder uprofessionelt med et grimt standardikon, og at adgangsbilletten til det fine selskab er at betale en dummebøde til en certifikatudsteder.

Mon ikke at kravet om certificering med tiden bliver udfaset til fordel for heuristikker baseret på opsamlet adfært, a la spamreputation. Eksempel: En mailudbyder først viser et logo, når der er modtaget minimum X mails til mindst Y brugere over mindst Z måneder, hvor højst P procent af disse mails er blevet markeret på spam. Det burde være til at implementere for mailudbydere med blot et moderat antal kunder.

  • 5
  • 0
Log ind eller Opret konto for at kommentere