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ó.
- arpi_esp blogja
- A hozzászóláshoz be kell jelentkezni
- 786 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
igen, igazabol az osszes headert (beleertve azokat is, amik a body reszben a mime multipart blokkok elejen vannak!) normalizalni kene... es akkor meg mindig lehetnek olyan problemak, hogy az MTA pl. atkodolja iso8859-2-rol utf8-ra...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
nem vagyok grammar naci, de ez kiszurta a szemem: aszimmetrikus.
- A hozzászóláshoz be kell jelentkezni
thx, fixed
- A hozzászóláshoz be kell jelentkezni
Én pont emiatt sem használom a DKIM-t saját szerveren. Egyszerűen értelmetlen.
- A hozzászóláshoz be kell jelentkezni
Ellenőrzésre vagy küldésre nem?
- A hozzászóláshoz be kell jelentkezni
Nem. Mivel elég könnyen hibás lehet az aláírás, ezért értelmetlen szerintem.
Ha tényleges hitelesítésre és/vagy titkosításra van szükségem, akkor maradnak a hagyományos módszerek: s/mime, e-akta/es3, asic konténer.
- A hozzászóláshoz be kell jelentkezni
Melyikre nem? Egyikre sem? Google megkapja a leveleidet?
- A hozzászóláshoz be kell jelentkezni
Egyikre sem használom. Eddig még senki sem panaszkodott - se Google-t, se MS365-t használó személyek.
Hozzáteszem, hogy a szerveremen viszonylag kevés levél megy át (napi < 50), így lehet, hogy ez is közrejátszik benne.
- A hozzászóláshoz be kell jelentkezni
Dkim nélkül a gmail hajlamos spambe rakni.
- A hozzászóláshoz be kell jelentkezni
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.).
- A hozzászóláshoz be kell jelentkezni
Lehet kerni kezbesitesi es olvasasi igazolast.
- A hozzászóláshoz be kell jelentkezni
Egyrészt a fogadó félen múlik, hogy ezt visszaküldi-e automatikusan vagy sem. Én például sose küldöm vissza.
- A hozzászóláshoz be kell jelentkezni
Olvasasit en sem. A masikat a szerver kuldi.
- A hozzászóláshoz be kell jelentkezni