Sinn und Unsinn von DKIM
Alexander Johannes
nachdem der DKIM-Support von Exim ja seit ein paar Releases stabil ist,
habe ich mich mal drangesetzt, selbst zu signieren und natürlich auch
Signaturen zu prüfen.
Das Signieren ist nicht weiter schwierig aufzusetzen. Spannend war
allein die Frage, ob sich der Domainname im DKIM-Signature-Header auf
den Domainnamen im From-Header oder im Envelope-Sender bezieht (Diese
sind in meinem Fall fast immer unterschiedlich). Nach meiner
Interpretation muss man den From-Header betrachten, ohne jedoch eine
definitive Aussage darüber gefunden zu haben.
Falls Interesse an der konkreten Konfiguration besteht, kann ich die
gerne veröffentlichen.
Spannend finde ich eher das Überprüfen der Signaturen. Die meisten
Anleitungen gehen von statischen Fall aus und prüfen nur, wenn die Mail
von Paypal, Google oder eBay kommt, oder eine Signatur enthält. Damit
fallen die Mails aller anderen Domains durchs Raster, die laut Policy
signiert sein müssten, es aber nicht sind (also in der Regel Fakes).
Die nächste Überraschung war dann, dass offenbar nicht mal jeder
Domainkey-Verwender eine Policy veröffentlicht¹. Was soll ich also mit
einer unsignierten gmail.com-Mail anfangen, wenn mir Google nicht mal
seine Policy mitteilt?
Bevor ich also einen Policy-Check für unsignierte E-Mails implementiere,
stelle ich erst einmal die Frage: „Lohnt sich das überhaupt?“ Welche
Erfahrungen habt ihr mit DKIM gesammelt?
Alex
¹) % host -t txt _domainkey.gmail.com.
_domainkey.gmail.com has no TXT record
% host -t txt _domainkey.ebay.com.
_domainkey.ebay.com descriptive text "t=y\; o=~\; n=http://pages.ebay.com/securitycenter"
% host -t txt _domainkey.paypal.com.
_domainkey.paypal.com descriptive text "o=-"
Juergen P. Meier
> nachdem der DKIM-Support von Exim ja seit ein paar Releases stabil ist,
> Signaturen zu prï¿œfen.
Soweit so schoen. Ich habe mir letztens meine Rosenbuesche im Garten
zurueckgeschnitten.
> Das Signieren ist nicht weiter schwierig aufzusetzen. Spannend war
> allein die Frage, ob sich der Domainname im DKIM-Signature-Header auf
> den Domainnamen im From-Header oder im Envelope-Sender bezieht (Diese
> sind in meinem Fall fast immer unterschiedlich). Nach meiner
Es interessiert zwar niemanden, worauf sich diese Beziehen, sie
sollten aber der Idee nach natuerlich den Domainpart des
Envelope-Senders matchen. Bei einem Mismatch ist naemlich die ganze
Signatur fuern Arsch (sprich: Ungueltig).
> Interpretation muss man den From-Header betrachten, ohne jedoch eine
> definitive Aussage darï¿œber gefunden zu haben.
Aeh, darauf basiert DKIM ganz grundsaetzlich: das Signieren der
Absender-Domain.
> Falls Interesse an der konkreten Konfiguration besteht, kann ich die
> gerne verï¿œffentlichen.
Nicht wirklich.
> Spannend finde ich eher das ï¿œberprï¿œfen der Signaturen. Die meisten
> Anleitungen gehen von statischen Fall aus und prï¿œfen nur, wenn die Mail
> von Paypal, Google oder eBay kommt, oder eine Signatur enthï¿œlt. Damit
Alles andere ist naemlich reichlich sinnfrei, insbesondere wenn es um
die Klassifizierung Spam vs. Ham geht. Erklaerung folgt unten.
> fallen die Mails aller anderen Domains durchs Raster, die laut Policy
> signiert sein mï¿œssten, es aber nicht sind (also in der Regel Fakes).
> Die nï¿œchste ï¿œberraschung war dann, dass offenbar nicht mal jeder
> Domainkey-Verwender eine Policy verￜffentlichtￜ. Was soll ich also mit
Oder sich - insbesondere bei nichttrivialer geschaeftskritischer
E-Mail - nicht an seine eigene Policy haelt. Schuld ist natuerlich
immer der Admin, der DKIM-Verifikation als zwingend eingestellt hat.
> einer unsignierten gmail.com-Mail anfangen, wenn mir Google nicht mal
> seine Policy mitteilt?
Keine Policy ist eben genau das: Keine Policy. D.h. DKIM-Signaturen
sind rein optional. Genauso musst du das bei der Pruefung behandeln:
Enthaelt eine E-Mail von einem Google-Acccount also eine gueltige
DKIM-Signatur sagt dir das effektiv exakt genau so viel wie wenn sie
keine gueltige DKIM-Signatur oder gar keine enthaelt.
> Bevor ich also einen Policy-Check fï¿œr unsignierte E-Mails implementiere,
> stelle ich erst einmal die Frage: ?Lohnt sich das ï¿œberhaupt?? Welche
Nein.
> Erfahrungen habt ihr mit DKIM gesammelt?
Es ist nettes optionales Spielzeug und erhoeht den Unterhaltungswert
von Maillogs sowie die Energiekosten (!Green IT), mit den bekannten
Ausnahmen, fuer die man DKIM aber auch garnicht braeuchte.
Zusaetzlich gelten alle Nachteile von SPF (ohne die Vorteile) analog.
So, und nun zur Erklaerng der voellig fehlenden Eignung von DKIM zur
Spam-Bekaempfung:
DKIM geht davon aus, dass Spammer sich selbst keine beliebigen Domains
beschaffen koennen oder wollen, sondern bekannte Domains dritter
misbrauchen - dabei aber *keinen* Zugriff auf deren Infrastruktur oder
die von Kunden haben.
Das waere ungefaehr so, als ob man davon ausgehen wuerde, dass
Einbrecher sich brav an Vorschriften halten wuerden, und an der Tuere
ein Schild anbringt: Einbrechen Verboten!
Dummerweise haben aber die meisten Spammer:
a) eigene Domains (Verislime verschenkt sie z.B. zum spam^Wausprobieren)
b) passende Zertifikate (dito) die nach den ueblichen CA-Seeds gueltig
sind
und damit alles, was man braucht um DKIM-Filter nicht zu verarschen,
sondern oftmals dank ihnen SPAM an anderen Filtern vorbei zu schieben
(DKIM-Signtur good = cant be spam -> Deliver!!!1). BTSTMT.
Und die anderen Spammer, die dafuer zu faul/dumm sind, haben idR:
c) Zugriff auf Accountdaten valider Nutzer der grossen Betreiber mit
DKIM-Policy, und damit zugang zur Infrastruktur und zu valide
signiertem Spam
d) Zugriff auf Clients von Kunden solcher Betreiber (Botnetz-Zombies),
rest siehe c).
Als Ergebnis wirst du mit einem DKIM-Filternden Mailsystem relativ
schnell merken, dass DKIM zur Spam-Bekaempfung ungefaehr so gut
taugt, wie ein Verbot von Fluessigkeitsbehaeltern >100ml im
Handbepaeck mit effizienter Terrorbekaempfung im Flugverkehr.
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Andreas Metzler
> nachdem der DKIM-Support von Exim ja seit ein paar Releases stabil ist,
> habe ich mich mal drangesetzt, selbst zu signieren und natürlich auch
> Signaturen zu prüfen.
> Das Signieren ist nicht weiter schwierig aufzusetzen. Spannend war
> allein die Frage, ob sich der Domainname im DKIM-Signature-Header auf
> den Domainnamen im From-Header oder im Envelope-Sender bezieht (Diese
> sind in meinem Fall fast immer unterschiedlich). Nach meiner
> Interpretation muss man den From-Header betrachten, ohne jedoch eine
> definitive Aussage darüber gefunden zu haben.
[...]
Hallo,
Der Wert unter d= gibt die Identitat des Unterzeichners an, d.h. unter
welchem DNS Eintrag ich den öffentlichen Schlüssel zur Verifizierung
der Signatur finde. Der From-header wird mitsigniert, der Umschlag
nicht. DKIM ist eben so eine Art kryptografisch gesicherter Received
Header.
In Verbindung mit ADSP kann man fordern, dass Mails mit From:-header über
Server y laufen müssen (da nur er signiert), aber das geht leicht
schief. Denke nur mal an eine Mailingliste, die den Betreff ändert.
[...]
> % host -t txt _domainkey.paypal.com.
> _domainkey.paypal.com descriptive text "o=-"
Das ist der Header für Domainkeys, nicht DKIM.
ametzler@argenau:~$ host -t txt _adsp._domainkey.paypal.com.
_adsp._domainkey.paypal.com descriptive text "dkim=discardable"
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Alexander Johannes
>Alexander Johannes <al...@nirgal.de>:
>> nachdem der DKIM-Support von Exim ja seit ein paar Releases stabil ist,
>> habe ich mich mal drangesetzt, selbst zu signieren und natürlich auch
>> Signaturen zu prüfen.
>Soweit so schoen. Ich habe mir letztens meine Rosenbuesche im Garten
>zurueckgeschnitten.
Da kannst du ja gleich bei mir weitermachen :^)
>> Das Signieren ist nicht weiter schwierig aufzusetzen. Spannend war
>> allein die Frage, ob sich der Domainname im DKIM-Signature-Header auf
>> den Domainnamen im From-Header oder im Envelope-Sender bezieht (Diese
>> sind in meinem Fall fast immer unterschiedlich). Nach meiner
>Es interessiert zwar niemanden, worauf sich diese Beziehen, sie
>sollten aber der Idee nach natuerlich den Domainpart des
>Envelope-Senders matchen. Bei einem Mismatch ist naemlich die ganze
>Signatur fuern Arsch (sprich: Ungueltig).
Danke für die Klarstellung
>> fallen die Mails aller anderen Domains durchs Raster, die laut Policy
>> signiert sein müssten, es aber nicht sind (also in der Regel Fakes).
>> Die nächste Überraschung war dann, dass offenbar nicht mal jeder
>> Domainkey-Verwender eine Policy veröffentlicht¹. Was soll ich also mit
>Oder sich - insbesondere bei nichttrivialer geschaeftskritischer
>E-Mail - nicht an seine eigene Policy haelt. Schuld ist natuerlich
>immer der Admin, der DKIM-Verifikation als zwingend eingestellt hat.
So gesehen schießt man sich mit DKIM-Signierten Mails eher ins Aus, als
wenn man den ganzen Quatsch links liegen lässt.
>> Erfahrungen habt ihr mit DKIM gesammelt?
>So, und nun zur Erklaerng der voellig fehlenden Eignung von DKIM zur
>Spam-Bekaempfung:
>DKIM geht davon aus, dass Spammer sich selbst keine beliebigen Domains
>beschaffen koennen oder wollen, sondern bekannte Domains dritter
>misbrauchen - dabei aber *keinen* Zugriff auf deren Infrastruktur oder
>die von Kunden haben.
Ich habe einfach mal die Prüfung für Mails aktiviert, die noch durch den
Spamfilter kamen (gut trainierter Bogofilter). Hier sind dann etwa 10%
des Spams mit valider DKIM-Signatur versehen. Das Sample ist klein, aber
die Tendenz bestätigt deine Aussage, dass DKIM zur Spam-Abwehr sinnlos
ist.
>HTH,
Tut es...
Alex
Alexander Johannes
>Der Wert unter d= gibt die Identitat des Unterzeichners an, d.h. unter
>welchem DNS Eintrag ich den �ffentlichen Schl�ssel zur Verifizierung
>der Signatur finde. Der From-header wird mitsigniert, der Umschlag
>nicht. DKIM ist eben so eine Art kryptografisch gesicherter Received
>Header.
Also muss der Wert unter d= weder auf die Domain im From, noch im
Envelope-Sender matchen?
>In Verbindung mit ADSP kann man fordern, dass Mails mit From:-header �ber
>Server y laufen m�ssen (da nur er signiert), aber das geht leicht
>schief. Denke nur mal an eine Mailingliste, die den Betreff �ndert.
Sp�testens bei Mailinglisten erscheint mir DKIM dann sowieso nicht mehr
robust genug.
>[...]
>> % host -t txt _domainkey.paypal.com.
>> _domainkey.paypal.com descriptive text "o=-"
>Das ist der Header f�r Domainkeys, nicht DKIM.
OK. Aber ich bin wohl nicht der erste, der die beiden Standards nicht
auseinander halten kann.
Alex
l...@shlink.de
> * Alexander Johannes <al...@nirgal.de> schrieb:
>> Das Sample ist klein, aber die Tendenz bestätigt deine Aussage,
>> dass DKIM zur Spam-Abwehr sinnlos ist.
>
> die Arbeit von Abuse-Abteilungen. Schwarze Schafe unter den Kunden
> könnten leichter dingfest gemacht werden.
DKIM macht m.E. Sinn z.B. bei einer positiven Bewertung (non-Spam).
Andreas Metzler
> - Do, 10 Feb 2011 - >>> - Andreas Metzler - schrieb:
>>Der Wert unter d= gibt die Identitat des Unterzeichners an, d.h. unter
>>welchem DNS Eintrag ich den öffentlichen Schlüssel zur Verifizierung
>>der Signatur finde. Der From-header wird mitsigniert, der Umschlag
>>nicht. DKIM ist eben so eine Art kryptografisch gesicherter Received
>>Header.
> Also muss der Wert unter d= weder auf die Domain im From, noch im
> Envelope-Sender matchen?
[...]
Ja, typischerweise ist es aber wohl schon der Fall. Eines der Beispiele
im RFC ist eine mailingliste die alle durchlaufenden Mails signiert,
da wird das envelope from übereinstimmen. Oder man kann über ADSP
festlegen, dass alle mails mit entsprechendem From header eine gültige
Signatur haben müssen. Denkbar ist aber auch, dass ein Smarthost alle
durchlaufenden Mails nach SMTP AUTH signiert.
lg Andreas
Juergen P. Meier
>> dass DKIM zur Spam-Abwehr sinnlos ist.
>
> die Arbeit von Abuse-Abteilungen. Schwarze Schafe unter den Kunden
Hast du schon mal versucht, dich ob eine Spam-Mail von einer
Verislign Test-Domain, signiert mit einem Verisign Test-Zertifikat,
bei Verisign zu beschweren?
Mach das mal. Das ist lustig.
> Klar, irgendwelche Techniken, die ohne Sinn und Verstand eingesetzt
> werden, bringen nichts. Es sollte schon Klarheit ï¿œber die
> angestrebten und technisch erreichbaren Ziele bestehen.
Ach. Ein Hauptgrund, DKIM in seiner angedachten Form weitgehend zu ignorieren.
Aehnlich wie STARTTLS bei SMTP kann man es aber misbrauchen um eine
feste 1:1 Beziehung zu einem bestimmten Kommunikationspartner zu
sichern, wenn beide Seiten eine entsprechende Policy fahren *und* die
Disziplin haben, keine Ausnahmen zu machen (z.B. weil der Server
kaputt gegangen ist, der Schluessel verloren wurde/das HSM defekt ist,
der Admin verpennt hat, das Zwertifikat zu verlaengern etc.pp. - all
das Uebliche halt)
Juergen P. Meier
Spammer duerfen auch DKIM nutzen, und tun dies auch fleissig mit gueltigen
Signaturen.
Das ist ein Tatsache, die du selbst ueberpruefen kannst, an dem Spam,
den du so bekommst.
Peter J. Holzer
><l...@shlink.de> <l...@shlink.de>:
>> Heiko Schlenker <hsc...@gmx.de> wrote:
>>> * Alexander Johannes <al...@nirgal.de> schrieb:
>>>> Das Sample ist klein, aber die Tendenz bestätigt deine Aussage,
>>>> dass DKIM zur Spam-Abwehr sinnlos ist.
>>>
>>> Sooo sinnlos ist's auch wieder nicht. Es erleichert möglicherweise
>>> die Arbeit von Abuse-Abteilungen. Schwarze Schafe unter den Kunden
>>> könnten leichter dingfest gemacht werden.
>>
>> DKIM macht m.E. Sinn z.B. bei einer positiven Bewertung (non-Spam).
>
> Spammer duerfen auch DKIM nutzen, und tun dies auch fleissig mit gueltigen
> Signaturen.
Natürlich. Kein vernünftiger Mensch hätte je erwartet, dass sie das
nicht könnten. Darum geht es nicht.
Verfahren wie SPF, DKIM, etc. dienen dazu, eine verifizierbare
Verbindung zwischen einer E-Mail und der Absenderadresse (bzw. dem darin
enthaltenen Domainnamen) herzustellen. Das erschwert manche Arten der
Adressfälschung und vor allem macht es Reputation Services auf Basis des
Domainnamens möglich. Ohne solche Verfahren ist das einzige
nicht-fälschbare Merkmal die IP-Adresse des SMTP-Clients.
Google hat gute Erfahrungen damit gemacht, den Verifikationsstatus als
zusätzliches Merkmal zur Absenderadresse dazuzunehmen.
(<hjp-u...@hjp.at>, verified) und (<hjp-u...@hjp.at>, unverified)
werden für Spam-Klassifizierungszwecke einfach als unterschiedliche
Absender gewertet. Keine der beiden Adressen hat a-priori eine höhere
Spam-Wahrscheinlichkeit. Aber wenn (<hjp-u...@hjp.at>, unverified)
häufig zum Spammen benutzt wird, dann wird dadurch die Reputation von
(<hjp-u...@hjp.at>, verified) nicht negativ beeinflusst. Wenn aber
ein Spammer Spammer selbst eine verifizierbare Adresse verwendet, dann
beziehen sich Spam-Reports natürlich auf diese Adresse und die
Reputation wird entsprechend schlechter.
> Das ist ein Tatsache, die du selbst ueberpruefen kannst, an dem Spam,
> den du so bekommst.
Ein gutes Drittel des Spams, den mein MX noch hereinlässt, kommt von
Yahoo. Der ist auch schön brav von Yahoo DKIM-signiert.
hp
Juergen P. Meier
> On 2011-02-12 07:39, Juergen P. Meier <nospa...@jors.net> wrote:
>><l...@shlink.de> <l...@shlink.de>:
>>> Heiko Schlenker <hsc...@gmx.de> wrote:
>>>> * Alexander Johannes <al...@nirgal.de> schrieb:
>>>>> Das Sample ist klein, aber die Tendenz bestätigt deine Aussage,
>>>>> dass DKIM zur Spam-Abwehr sinnlos ist.
>>>>
>>>> Sooo sinnlos ist's auch wieder nicht. Es erleichert möglicherweise
>>>> die Arbeit von Abuse-Abteilungen. Schwarze Schafe unter den Kunden
>>>> könnten leichter dingfest gemacht werden.
>>>
>>> DKIM macht m.E. Sinn z.B. bei einer positiven Bewertung (non-Spam).
>>
>> Spammer duerfen auch DKIM nutzen, und tun dies auch fleissig mit gueltigen
>> Signaturen.
>
> Natürlich. Kein vernünftiger Mensch hätte je erwartet, dass sie das
> nicht könnten. Darum geht es nicht.
Hmm, aber das behaupten die Erfinder von DKIM.
> Verfahren wie SPF, DKIM, etc. dienen dazu, eine verifizierbare
> Verbindung zwischen einer E-Mail und der Absenderadresse (bzw. dem darin
Nein. SPF dient einzig dazu, Benutzern einer Domain die Freiheit zu
nehmen, unabhaengig Mail-Infrastrukturen zu nutzen und ihren Mailverkehr
auch in Absender-Richtung zu kontrollieren.
Mit verifizierten Verbindungen hat das ueberhaupt nichts zu tun.
DKIM dient einzig dazu, zu belegen, dass der Absender im Besitz eines
von einer komerziellen CA signierten Zertifikates und zudem beim
Ausstellen desselben auch "nachweisen" konnte (z.B. per Fax) die
Verfuegungsgewalt ueber die Domain zu haben. Nicht mehr und nicht
weniger.
Das einzige verfahren im Umfeld E-Mail, dass Verbindungen verifiziert,
ist TLS. Jedoch keine Ende-zu-Ende verbindung.
> enthaltenen Domainnamen) herzustellen. Das erschwert manche Arten der
> Adressfälschung und vor allem macht es Reputation Services auf Basis des
> Domainnamens möglich. Ohne solche Verfahren ist das einzige
> nicht-fälschbare Merkmal die IP-Adresse des SMTP-Clients.
Bezueglich DKIM kann man diesen Rueckschluss ziehen - unter voelliger
Ignoranz der Realitaet zumindest. Mit SPF hat dies jedoch nichts zu
tun.
>> Das ist ein Tatsache, die du selbst ueberpruefen kannst, an dem Spam,
>> den du so bekommst.
>
> Ein gutes Drittel des Spams, den mein MX noch hereinlässt, kommt von
> Yahoo. Der ist auch schön brav von Yahoo DKIM-signiert.
Ach. Siehst du, ich lasse solchen Spam nicht rein, trotz glaenzender
DKIM-Signaturen.
Claus Aßmann
> Peter J. Holzer <hjp-u...@hjp.at>:
> > On 2011-02-12 07:39, Juergen P. Meier <nospa...@jors.net> wrote:
> >><l...@shlink.de> <l...@shlink.de>:
> >> Spammer duerfen auch DKIM nutzen, und tun dies auch fleissig mit gueltigen
> >> Signaturen.
> > Natürlich. Kein vernünftiger Mensch hätte je erwartet, dass sie das
> > nicht könnten. Darum geht es nicht.
> Hmm, aber das behaupten die Erfinder von DKIM.
Zitat? URL? ...?
> DKIM dient einzig dazu, zu belegen, dass der Absender im Besitz eines
> von einer komerziellen CA signierten Zertifikates und zudem beim
Vielleicht solltest Du mal die Dokumente zu DKIM lesen,
das koennte evtl. helfen.
Kleiner Hinweis:
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;