A DKIM-ről...

Beszéljünk egy kicsit a hüvelyg az email feladó hitelesítésről!
Kezdetben volt ugye a... nem, nem volt semmi! Komolyan! Aztán jött az SPF, ami IP címhez kötötte a feladót,
ez egészen addig jó, amíg nem forwardolod a levelet tovább. Erre kínált ugye elvileg megoldást a DKIM.

Na de hogy is működik a DKIM? készít egy aszimmetrikus kulcsú digitális aláírást (kezdetben RSA) a levél bizonyos elemeire:
- body hash (sha1 vagy sha256 hash a levél tartalmára, ez kerül a 'bh' paraméterben a dkim headerbe)
- kiválasztott headerek  (pl.: From/to/Date)
Azt azért érezték a DKIM kitalálói is, hogy ez így neccess lesz, mert az SMTP/MTA működéséből kifolyólag nem feltétlen
marad végig bit-pontos a levél amíg áthalad a szervereken, pl. változhatnak a whitespacek, a sorvége jelölések (CRLF vs LF),
lehet header (un/re)folding (hosszú header sorokat több sorba tördel/összerak), hozzáadhat plusz headereket stb.

Erre találták ki a Canonicalization-t, ami külön állítható a header és body részekre, simple vagy relaxed módra.
Utóbbi az összes whitespacet 1-1db space-re cseréli, törli a sorvégi whitespaceket és a levél végén az üres sorokat.
Ezzel a tartalma/értelme nem változik a levélnek, de valamennyire kivédi a transfer közbeni formátum átalakulásokat.

összedobtam pythonban egy egyszerű dkim implementációt, részben a dkimpy-re és erre alapozva: Verifying a DKIM-Signature by hand  és elkezdtem több 10ezres levél foldereken futtatni tesztelés céljából. és meglepően sok volt a hiba! De miert?
Az addig remek, hogy a dkim relaxed header processing szépen kiszedi a newline-okat, de ezt a body esetén nem végzi el, pedig mime-multipart esetén (ha van pl. csatolt file, vagy akár csak text+html) a body részben is vannak mime headerek, amit ugyanúgy megbirizgálhatnak a szerverek, szűrők.
pl. az MS Exchange a levél továbbítása közben itt az utf-8-at idézőjelbe rakta, mert csak. Szerinte így szebb, jobb stb:)
    Content-type: text/html; charset="utf-8"
és ezzel már el is rontotta a DKIM-et...
másik példa a Kaspersky KLMS, ami beszúrt egy plusz headert a csatolt pdf-nél a body-ba, az elsőt meg szétbontotta 2 sorba:

Content-Type: application/octet-stream;
 name="napilista.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment
X-KLMS-antivirus-status: Encrypted, skipped

De olyannal is találkoztam, hogy a base64 part a levélben nem volt sorokra bontva, hanem egy nagyon hosszú sorban ment az egész. Persze az MTA ezt egyből szétdarabolta 998 karakteres sorokra, valamennyire jogosan az RFC-nek megfelelve, de ezzel hazavágta a dkim-et.

Az is triviális dkim-gyilkos, ha a különböző spamszűrők (Spamassassin stb) és víruskergetők a Subject-be írnak bele ezt-azt.
és a levlisták sem kímélik a body-t, mert muszáj a levél végéhez hozzairniuk 1-2 sort hogy ilyen-olyan levlista jajjdejó.

Hozzászólások

Szerinte így szebb, jobb stb

A DKIM-nek ki kellett volna térnie a kanonikus alaknál erre is.

Ugyanis ez teljesen szabványos:

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

   are completely equivalent.

 

Az a probléma itt, hogy a DKIM kanonikus formára hozú algoritmusa nem jól definiált.

Szerkesztve: 2024. 07. 25., cs – 20:44

Bár nem csináltam ilyet, és csak hirtelen ötlet:

- kivenni a levél meghatározott részeiből mindent ami nem egy általánosan/szabvanyosan használt rész ( az, hogy mi az általánosan használt, azt valahol definialnam: pl Content-xxxxx kezdetű sor, boundary… stb)

-miután kivettem mindent ami egyedi lehet, akkor az egészből csinálnék egy karakter halmazt úgy, hogy kivenném az összes spacet, tabot, új sort, lehet még a pontokat és a kötőjeleket is

- ez képezne a kodolas alapjat

nem vagyok grammar naci, de ez kiszurta a szemem: aszimmetrikus.

Én pont emiatt sem használom a DKIM-t saját szerveren. Egyszerűen értelmetlen.

Ezzel tisztában vagyok.

Én az emailre úgy tekintek, mint nem garantált üzenetkézbesítési szolgáltatás. 100+1 oka lehet, amiért az email nem ér célba. Már eleve az se garantált, hogy a címzett elolvassa, ha megkapja. Ilyenkor szoktam emlékeztető emaileket küldeni vagy megkeresni az illetőt másik csatornán (telefon, Linkedin stb.).