AOL accepteert Sender ID na aanpassing Microsoft

AOL heeft na aanpassingen van Microsoft aan Sender ID besloten om de antispamtechnologie toch te gaan gebruiken. Eerder besloot het bedrijf de specificatie aan de kant te schuiven, wat betreft de controle op inkomende e-mails, en voorlopig alleen SPF te gaan gebruiken. Beide technieken controleren via DNS of de server vanaf welke een mail verzonden is, hoort bij de vermelde afzender van het bericht. Dit moet voorkomen dat spammers zich als afzender kunnen voordoen als een betrouwbare partij. Microsoft heeft zijn specificatie voor Sender ID zo aangepast dat er volledige compatibiliteit is met SPF en de tienduizenden domeinen die deze standaard reeds voor verificatie gebruiken.

AOL zegt dat juist dit het punt was waarop Sender ID in eerste instantie is afgewezen. Het bedrijf was al ver gevorderd met het ontwikkelen en implementeren van verificatie met SPF. Microsoft wordt door AOL gezien als belangrijke partner in de bestrijding van spam, waarvoor nog veel werk verzet zou moeten worden. De Internet Engineering Task Force (IETF), die Sender ID eerder afwees als standaard, heeft de gewijzigde versie van de specificatie inmiddels ook binnen. Een belangrijk punt van afwijzing werd gevormd door de licentievoorwaarden die Microsoft aan Sender ID heeft gekoppeld. Deze zijn in de nieuwe versie ongewijzigd, waardoor de vraag rijst of de specificatie deze keer wel geaccepteerd wordt door IETF.

Reacties (13)

[swampy]

het zijn nogsteeds verschillende systemen... met verschillende licenties..

Open source zal bijvoorbeeld de microsoft methode niet kunnen gebruiken.

maar inderdaad dat microsoft SPF ondersteund is een goed iets...

[Verwijderd]

Mooi!
Begrijp ik het goed dat je nu maar één aanpassing moet doen op je domain om beide technieken te ondersteunen?
Heeft iemand enig idee wat je eigenlijk moet doen als domaineigenaar?

[procede]

Wow! Microsoft heeft meegegeven!

Serieus: Wel een goede zet, met meerdere standaarden schiet niemand wat op.

[Mac_Cain13]

Ja, Microsoft heeft megegeven op technisch vlak, maar waar veel mensen over struikelden was juist de licentie. Deze is ongewijzigt gebleven en ik denk (en hoop) dan ook niet dat het IETF deze keer de specificatie wel zal accepteren.
Ook de andere partijen die het Sender ID eerder om deze reden weigerden zullen waarschijnlijk bij hun standpunt blijven. Microsoft zal dan toch eerst op licentie gebied mee moeten geven en het niet op deze manier nog eens proberen.

[siknu]

Sommige mensen hebben nog een dail-up accountje naast hun breedband van een andere provider bijvoorbeeld omdat ze hun bekende e-mail adres niet kwijt willen. Die versturen hun mail dus met de smtp van hun huidige breedband provider. Ook verstuur ik de mail van mijn domeinen vanaf de smtp van mijn breedband provider zodat ik de smtp van mijn server niet onnodig belast en ivm datalimiet. Die mail zal dus allemaal als spam aangemerkt worden volgens het senderid als ik het goed aanneem aangezien die mail dus niet afkomstig is van de smtp van de eigen provider. Je kan de smtp servers echter meestal alleen bereiken als je ook verbinding maakt met de betreffende provider. Hierdoor zullen dus velen gedupeerd worden terwijl hun intenties juist zijn. Een slechte zaak, tenzij de smtp servers aangepast worden zodat ze bereikbaar zijn van ip's buiten de range van de provider zelf en men afgerekend wordt op login en pass bijvoorbeeld. Echter een dergelijke aanpassing zie ik niet zo snel gebeuren.

[FaalHaas]

De kracht van SPF is, dat je als domein eigenaar kan aangeven welke mailservers op voor jouw domain mail mogen handelen.

Stel jij bent de eigenaar van maildomein.nl, maar jij wil je mail versturen via Chello, of een andere 3e rangs provider, dan neem jij in jouw DNS een SPF record op. In dit SPF record geeft jij aan dat chello.nl op jouw domeinnaam mail mag versturen.

Vervolgens routeer jij je mail via Chello, als dan niet authenticated (afhankelijk van de instellingen van jouw provider).

De ontavngende server krijgt dan van mx1.chello.nl mail aangeboden met als afzender [e-mail]. Een eenvoudige query op de DNS van maildomein.nl geeft aan dat chello.nl een trusted relay is.

Klaar.

[EricV]

Veel SMTP-servers ondersteunen al een user/pass login. Daarnaast heb je ook nog altijd POP before SMTP. Dan wordt mail vanaf jouw IP geaccepteerd binnen 5 minuten nadat je vanaf dat IP je mail via POP/IMAP heb gecheckt. Als je dit elke 5 minuten automatisch laat doen heb je nooit een probleem.

[MadEgg]

Toch wel. Mijn mail wordt namelijk automatisch van de POP-server van mijn provider gehaald door mijn mail-servertje, met, je raad het al, een ander publiek IP adres dan mijn desktop-computer. Vervolgens maak ik een IMAPS verbinding met mijn servertje om mijn mail te lezen. Als ik dan een e-mail bericht stuur, gaat dit rechstreeks via de SMTP-server van mijn provider. Aangezien ik niet vanaf mijn desktop-computer verbinding heb gemaakt met de POP-server van mijn provider zal deze dus met een SMTP after POP opstelling mijn mailtje wijzigen.

Het systeem rammelt sowieso, met zoveel verschillende opstellingen die bestaan. Ik vind inloggen op de SMTP-server en eventueel een e-mail limiet(1000 emails per maand gratis, daarboven 0,01 cent per bericht, zal voor de normale gebruiker geen probleem zijn) nog altijd de beste oplossing voor spam.

[migel]

Wat voor mail-servertje gebruik je daar dan voor?? Ben al een tijdje op zoek naar zo'n feature nl.

[MadEgg]

Gentoo Linux-server met fetchmail om de post op te halen, postfix om uitgaande mail te versturen via de webinterface, dovecot-imap server om de mail op m'n desktop-computer op te halen en apache2/php/squirrelmail om op afstand m'n mail te kunnen bekijken.

[Verwijderd]

Ik hoop vooral dat Sender ID net zo'n stille dood sterft als Passport.net
En dat AOL's toegift vooral een gesture blijkt, naar de hotmail-accounts toe.

Want zeg nou eerlijk; wat is de meerwaarde van Sender-ID nog, als deze 100% compatible is met SPF? Die langzame check-achteraf? De XML-uitbreiding? hmm..

Precies dezelfde nachtmerrie als die passports. Ook nooit aan meegedaan; véél te log.