Poniższy tekst oryginalnie był moim komentarzem do postu na temat systemu antyspamowego Mujica, ale uznałem, że pomysł może nie jest taki zły i warto go sobie zostawić pod ręką.
Byłoby o niebo wygodniej, gdyby serwer wysyłający pocztę podpisywał nagłówki swoim kluczem PGP i udostępniał w strefie DNS klucz publiczny (jako pole TXT), umożliwiający sprawdzenie, czy podpis jest prawidłowy.
Teraz mamy trzy możliwe sytuacje odbierania poczty:
- list pochodzi od nadawcy, którego MX nie posiada publicznego klucza - list zostaje sprawdzony normalnie, za pomocą spamassassina i trafia do kolejki
- list pochodzi od nadawcy, którego MX posiada publiczny klucz, a list jest prawidłowo podpisany przez serwer - list trafia do kolejki bez sprawdzania
- list pochodzi od nadawcy, którego MX posiada publiczny klucz, ale list nie jest podpisany prawidłowo lub nie jest podpisany wcale - list zostaje odrzucony przed przyjęciem
Łatwe w konfiguracji (wystarczy skopiować klucz publiczny na wszystkie maszyny służące za MX w danej sieci) i łatwo zapobiegnie wysyłaniu spamu z fikcyjnych kont typu user@hotmail.com (zakładając, że taki Hotmail by to zainstalował). Przy okazji skuteczniejsze od SPF, gdzie spora część adminów dla wygody wpisała sobie all.
Ciekawe, kiedyś przy piwie wymyśliliśmy podobny sposób. :-)
Właśnie wymyśliłeś http://en.wikipedia.org/wiki/Domainkeys
A to co Tomek Nidecki próbuje wymyślić to połączenie zasad działania greylistingu dla adresów IP w systemem RBLi (nota bene takie whitelisty działają w Internecie).
O pomyśle tej wspomnianej firmy nawet słowa nie powiem, bo ręce mi opadły jak usłyszałem o ich “innowacyjności”. Ech…
pjf:
No nie, bo DomainKeys podpisuje treść wiadomości, a nie nagłówki.
Patrys: OIDP, DKIM (czyli wersja rozwojowa DomainKeys) podpisuje także wybrane nagłówki.
PJF: Dokładniej, to ja chcę połączyć więcej mechanizmów na etapie sesji tak, żeby zwiększyć skuteczność, zmniejszyć opóźnienia i false positives. No, ale to temat mojej pracy magisterskiej 8D.