[disc] Sender ID*

[Verwijderd]

Okeej, m'n eerste post op GoT ooit, geloof ik! (En meteen ook m'n eerste eerste post.. hmm..)

Ook ik werd helemaal gestoord van die spam/virus mails. Maar nu ik een goed filter heb zitten, worden de meeste toch geblocked. Heel fijn, maar das natuurlijk niet de oplossing.
Microsoft werkt nu aan een (in mijn eigen ogen brakke) oplossing, Sender Id. Ik heb niet echt veel gelezen over dat idee, maar het lijkt me een suffe oplossing (volgens mij werkt 't met een centrale server???)..

Maar waar ik wel denk dat ze gelijk in hebben, is dat 't allemaal draait om authenticatie.

Ik had zelf 't volgende bedacht, schiet maar op m'n idee.. dat is de reden dat ik 't hier plaats.

In 't kort:
1) Iedere gebruiker (email houder) krijgt een extra map bij z'n mailbox: 'SentItemsCheckSums', ofzo. Wanneer diegene een email verstuurd, wordt er een MD5 checksum berekend, die in die (publieke!) mailmap komt.. Ook in het mailltje zelf komt een header met daarin die checksum.
2) Het mailtje komt aan bij de mailbox van de ontvanger. Die pluist de email uit en vindt de checksum. A.d.h. van de checksum kan hij vervolgens detecteren of het mailtje ook echt komt van de plaats waarvan 'ie verstuurd is (hij checkt de 'SentItemsCheckSums' van de verstuurder).

Klopt 't: meeltje komt in z'n inbox, klopt 't niet, kan het eruit gefilterd worden.

Om de post niet te lang te maken, zal ik 't hierbij laten.

Schiet maar!

[elevator]

Sender ID werkt niet met een centrale server, maar werkt met het opnemen van extra informatie in een DNS server. Zie bv: http://www.microsoft.com/...rivacy/spam_senderid.mspx

Even korte samenvatting van die site:

The steps in the process are:

1. The Sender sends an e-mail message to the Receiver.

2. The Receiver's inbound mail server receives the mail.

3. The Receiver's server checks for the SPF record of the sending domain published in the Domain Name System (DNS) record.

4. The inbound e-mail server determines if the sending e-mail server's IP address matches the IP address that is published in the DNS record.

Zoals je ziet heeft het weinig met een extra centrale server te maken - die DNS server is toch al van vitaal belang in de praktijk voor mailaflevering.

Jouw systeem heeft als nadeel dat in een corporate omgeving de 'sent'-checksums ook centraal opgeslagen moeten worden - wat dus (grote) client aanpassingen vereist, terwijl bij het Sender ID het afdoende is om enkel de server kant aan te pakken, en dat is een stuk beter controleerbaar omdat de serverkant beheerd wordt door kundige mensen

[Verwijderd]

Ah.. das idd beter. Hoewel 't wel een aanpassing in 't DNS vereist.

Bij mijn ideetje was er idd een aanpassing nodig bij de client (of eigenlijk bij de mailserver). De server zou dan een extra header toe kunnen voegen ofzo, waar de client dan weer op zou kunnen filteren.

[Verwijderd]

Sender ID zorgt dus alleen voor ip -> name check?? (dus als 't ip gespoofed wordt, dan is 't valid?).. Hmm.. ik zal 't eerst eens doorlezen

[lordgandalf]

Ik vindt sender id opzich een goed idee alleen de manier waarop onze redmond vrienden het willen implementeren niet.
hun verwachten namelijk dat een bedrijf een licentie neemt op Sender ID en zich houwt aan hun regeltjes
Dit houdt onder andere in dat het perse een closed source product moet worden aangezien de meeste mail servers op een *nix os draaien en dit vaak open source implimentaties zijn is dit voor hun geen optie.
Dus als microsoft hun eisen niet aanpast dan zie ik het gedoomed te mislukken.
waarschijnlijk gaat het eerder Sender Policy Framework ofwel SPF worden dit is ongeveer gelijk aan Sender ID alleen iets minder uitgebreid en zonder de microsoft regeltjes

nieuws bericht over sender id:
nieuws: Open-sourcegemeenschap sceptisch over Sender ID

info over hoe spf werkt:
http://spf.pobox.com/howworks.html

[ Voor 7% gewijzigd door lordgandalf op 01-09-2004 12:38 ]

[Verwijderd]

sender-id gaat kapot als je een bericht forward.
de envelope sender ben je dan niet zelf, maar de originele afzender.
De mailserver waar naar jij stuurt checkt dan spf record voor de originele envelope sender, vind dan lijst met ips/mx/a/ect waar jouw mailbak niet tussen staat.
Gevolg, je bericht wordt gefilterd/gebanned/getagged als mogelijke spam.

Zo zijn er wel meer voorbeelden van de brakheid van sender-id/spf.
Plus zoals al eerder genoemd gaat niemand meewerken aan de license van microsoft, dus zal ook sender-id sneuvelen.

[lordgandalf]

das idd een probleem maar daar zal ook wel een oplossing voor gevonden worden neem ik aan teminste voor spf.
vindt het slecht van microsoft dat ze voor een aangepaste standaard geld durven te vragen teminste dat is het in mijn ogen.
Sender ID is gewoon een aangepaste spf versie niet meer en niet minder.

[Verwijderd]

Verwijderd schreef op 01 september 2004 @ 12:02:
In 't kort:
1) Iedere gebruiker (email houder) krijgt een extra map bij z'n mailbox: 'SentItemsCheckSums', ofzo. Wanneer diegene een email verstuurd, wordt er een MD5 checksum berekend, die in die (publieke!) mailmap komt.. Ook in het mailltje zelf komt een header met daarin die checksum.

Maar waar komt die publieke map en hoe komt de ontvanger daarin? Als je voor elke mail een checksum centraal (of gedistribueerd, maar iig algemeen toegankelijk) moet opslaan, is dat heel veel!

Waarom niet gewoon PGP signatures? Dan hoef je alleen de public keys op te slaan, da's 1 per email adres i.p.v. 1 per mailtje.

PGP is al geimplementeerd in heel veel mail clients (of kan via add-ons toegevoegd worden), en het vereist geen veranderingen aan de servers.

Overigens is authenticicatie geen garantie tegen spam; het maakt alleen white/grey/black-listing makkelijker.

[Brahiewahiewa]

AdminHenk flamede op 01 september 2004 @ 12:46:
sender-id gaat kapot als je een bericht forward.
de envelope sender ben je dan niet zelf, maar de originele afzender.
De mailserver waar naar jij stuurt checkt dan spf record voor de originele envelope sender, vind dan lijst met ips/mx/a/ect waar jouw mailbak niet tussen staat.
Gevolg, je bericht wordt gefilterd/gebanned/getagged als mogelijke spam.

Zo zijn er wel meer voorbeelden van de brakheid van sender-id/spf.
Plus zoals al eerder genoemd gaat niemand meewerken aan de license van microsoft, dus zal ook sender-id sneuvelen.

't Is van Microsoft dus het moet wel brak zijn, hè?
Volges mijn is vooral je mail client brak als-ie het sender-ID van de originele afzender handhaaft, in geval van een forward.

[blaataaps]

Brahiewahiewa schreef op 03 september 2004 @ 21:42:
[...]

Volges mijn is vooral je mail client brak als-ie het sender-ID van de originele afzender handhaaft, in geval van een forward.

Onzin. Bij veel forwards komt niet eens een client kijken, en de meeste forwards laten de From: en To: headers intact, en dat zal met spf dus niet meer werken.
Hetzelfde geldt voor mailinglists, op zich ook een manier van forwarden, die zullen ook ten onrechte een spf-failed score krijgen.
Daar komt nog bij dat voor zover ik weet spf bedoelt is voor de hostname die genoemd wordt in de "mail from:" die een mailserver roept, en niet voor de From: header, zodat je bij mijn weten gewoon veel clients ook nog kunt foppen.

[ Voor 4% gewijzigd door blaataaps op 03-09-2004 21:50 ]

[Brahiewahiewa]

blaataaps schreef op 03 september 2004 @ 21:50:
[...]de meeste forwards laten de From: en To: headers intact

dat zeg ik: da's brak

Hetzelfde geldt voor mailinglists

inderdaad, ook brak

"brak" is in dezen natuurlijk een flame, maar het gaat mij erom aan te geven dat je nieuwe functionaliteit (SPF) niet voor brak moet uitmaken omdat het met bestaande software niet werkt. Zo kun je iedere vorm van spam bestrijding afdoen als brak; 's geen constructieve opstelling

Daar komt nog bij dat voor zover ik weet spf bedoelt is voor de hostname die genoemd wordt in de "mail from:" die een mailserver roept, en niet voor de From: header, zodat je bij mijn weten gewoon veel clients ook nog kunt foppen.

Lees RFC2822 nog even na op wat er met "envelope" bedoeld wordt