Onderwerp: Microsoft drukt Sender ID door met behulp van Hotmail

Wij hebben het ondertussen ook al aangezet.
Het kan opzich allemaal geen kwaad.

Origineel geplaatst door electric
Wij hebben het ondertussen ook al aangezet.
Het kan opzich allemaal geen kwaad.

DAAR lopen de meningen nogal over uiteen.

Ooohhhh! Nu snap ik waarom me emails opeens niet meer aankwamen

Origineel geplaatst door Dillard

Al met al leuk bedacht (door het SPF record te controleren kan de ontvangende mailserver zien welke de server de mail mag versturen), maar hoe moeten we dat in Nederland regelen met alle SMTP-blocks bij de Access Providers waardoor klanten gedwongen zijn om smtp-out.accessprovider.nl te gebruiken? Moeten onze klanten al die SMTP-adressen (van al hun emailgebruikers) in hun DNS gaan opnemen ?

Dat gaat natuurlijk niet werken en dat wordt door onze klanten dan weer bij ons neergelegd

Als de medewerkers van een klant achter veel SMTP servers zitten, dan liggen er zeker een aantal problemen op de loer. Daarom hebben ze 'all' met nog wat zooi erbij uitgevonden.

Teveel txt records (SPF records bestaan immers niet) zouden tot problemen kunnen gaan leiden.
Denk maar aan fallback mx.. dat is met SPF en senderid dus exit. De afzender moet dus alle fallback mx servers in zijn txt records op laten nemen om fallback mx te laten werken... Dat wordt lachen.

Uiteindelijk lossen spf en senderid niet echt iets op. Spam wordt niet gestopt. Aangezien veel gebruikers stom genoeg zijn om op alle HTML mail te klikken wordt ook phishing niet gestopt.
Hooguit joe-jobs.. die worden er mogelijk door gestopt...

Ik vraag mezelf af of ms e.e.a. door durft te zetten als de acceptatie van spf/senderid zo laag blijft.

Wij ook, aangezien ze geprobeerd hebben spam te versturen onder onze naam. Gezien en direct een SPF record aangemaakt.

Origineel geplaatst door TimmiT.nl
Wij ook, aangezien ze geprobeerd hebben spam te versturen onder onze naam. Gezien en direct een SPF record aangemaakt.

En wat lost dat precies op?

Die spam wordt alleen geweigerd als de ontvangende mailserver keihard de verbinding weigert. Dat durft nog niemand aan!

Ik ken het niet, maar als het een slecht protocol is en Microsoft probeert het nog eens extra door te drukken, dan is dat voor mij alleen nog maar een extra reden om het niet te gebruiken.

Wij gebruiken het op het moment in ieder geval niet.

Misschien moet er een nieuw protocol ontwikkeld worden om te zorgen dat alles anders gaat. Een soort e-mail v2. Die na een tijdje de huidige e-mail moet vervangen. Want extra toevoegingen zoals deze SPF zullen denk ik nooit helemaal werken, omdat het niet door iedereen gebruikt zal worden.

Origineel geplaatst door crazycoder

En wat lost dat precies op?

Die spam wordt alleen geweigerd als de ontvangende mailserver keihard de verbinding weigert. Dat durft nog niemand aan!

Op de mail server waar we onze eigen mail op ontvangen (en een klein aantal klanten) wordt de connectie afgebroken als het SPF record niet matched.
Van 2005-06-01 tot nu zijn daardoor 191 mails geweigerd.

Origineel geplaatst door royen99

Op de mail server waar we onze eigen mail op ontvangen (en een klein aantal klanten) wordt de connectie afgebroken als het SPF record niet matched.
Van 2005-06-01 tot nu zijn daardoor 191 mails geweigerd.

Jouw server, jouw feestje..

Wel leuk voor jullie zelf of jullie klanten als ze of jullie daardoor handel missen! Ik neem aan dat een ieder hiervan op de hoogte is en ermee instemt..
Afijn, moet je ook helemaal zelf weten..

Misschien moet ik mijn statement bijstellen en zeggen dat een enkeling dat doet.. Zelfs hotmail merkt ze alleen nog maar aan als 'mogelijk spam'.

Als er 191 mailtjes geweigerd zijn, hoeveel zijn er dan in die tijd wel door de test gekomen?

Naar mijn mening is het keihard weigeren van een connectie gebaseerd op SPF in een productieomgeving vooralsnog niet verstandig. Maar zoals ik zeg.. jouw server.. jouw feestje...

Origineel geplaatst door royen99


Op de mail server waar we onze eigen mail op ontvangen (en een klein aantal klanten) wordt de connectie afgebroken als het SPF record niet matched.
Van 2005-06-01 tot nu zijn daardoor 191 mails geweigerd.

Handig met forwards...

voor mij is 't dus wel een probleem. Een website op een server van me verstuurd bevestigingsmailtjes naar hotmail adressen. Adressen die door bezoekers van de site gebruikt worden. Deze komen dus niet meer aan.. ik moet dus wel me dsn records aan gaan passen

btw.. door ?all te gebruiken wordt toch de hele lading gedekt? of denk ik nu te simpel.. ?all betekend toch dat mail overal vandaan kan komen?

Oorspronkelijk geplaatst door crazycoder

Als de medewerkers van een klant achter veel SMTP servers zitten, dan liggen er zeker een aantal problemen op de loer. Daarom hebben ze 'all' met nog wat zooi erbij uitgevonden.

Teveel txt records (SPF records bestaan immers niet) zouden tot problemen kunnen gaan leiden.
Denk maar aan fallback mx.. dat is met SPF en senderid dus exit. De afzender moet dus alle fallback mx servers in zijn txt records op laten nemen om fallback mx te laten werken... Dat wordt lachen.

Volgens mij heb je er niet veel kaas van gegeten. Sowieso heeft een SMTP server meestal hooguit 1 of 2 fallback mx, en dat werkt prima samen met SPF zolang je zorgt dat de IPs (of hostnames) van de fallback mx in de SPF record vermeld staan. Deze hoeven niet op een afgezonderde txt regel, alles komt in 1 regel te staan.

Oorspronkelijk geplaatst door crazycoder

Uiteindelijk lossen spf en senderid niet echt iets op. Spam wordt niet gestopt. Aangezien veel gebruikers stom genoeg zijn om op alle HTML mail te klikken wordt ook phishing niet gestopt.
Hooguit joe-jobs.. die worden er mogelijk door gestopt...

Dit bevestigt mijn eerdere veronderstelling dat je niet helemaal snapt wat het doel van SPF records zijn. Kort samengevat verifieren SPF records vanaf welke servers (IP addressen) mail voor een bepaald domein verstuurd mogen worden. Bijvoorbeeld kan een SPF record aangeven dat mail voor @domein.com enkel vanaf IPs 1.2.3.4 en 1.3.3.8 verzonden mogen worden. Stel dat er dan een mail verstuurd wordt van @domein.com vanaf 2.3.4.5 dan wordt deze email geweigerd. Het doel hiervan lijkt me duidelijk, spambots versturen namelijk vrijwel altijd emails van domeinen welke niet aan hen toebehoren (meestal gewoon random adressen).

Voorkomt het phishing? In de meeste gevallen wel. Draagt het bij aan spampreventie? Ja. Is het een totaaloplossing tegen spam? Nee, maar zo lang het een positieve bijdrage levert is het in ieder geval zeker niet nutteloos.

Is het weigeren van email omdat er geen SPF record bestaat voor een bepaald domein verstandig? Nee, naar mijn mening niet, zo lang dit geen algemene standaard is.

Is het weigeren van email verstandig als er WEL een SPF record bestaat, en het remote mailserver IP komt niet overeen met de toegestane IPs in de SPF record? Ja.

Oorspronkelijk geplaatst door Apoc

Volgens mij heb je er niet veel kaas van gegeten. Sowieso heeft een SMTP server meestal hooguit 1 of 2 fallback mx, en dat werkt prima samen met SPF zolang je zorgt dat de IPs (of hostnames) van de fallback mx in de SPF record vermeld staan. Deze hoeven niet op een afgezonderde txt regel, alles komt in 1 regel te staan.

Pffffffffffffffffffffffffff... Jij zit er zelf naast.

Als je het goed wil doen check je op je fallback mx of de server mag verzenden. Vervolgens whitelist je de fallback van de checks op de mailserver waar de popbox uiteindelijk draait.

Oorspronkelijk geplaatst door Apoc

Is het weigeren van email verstandig als er WEL een SPF record bestaat, en het remote mailserver IP komt niet overeen met de toegestane IPs in de SPF record? Ja.

Nogmaals, phishing en spam worden niet voorkomen. Is ook niet het doel.

Het voorkomt het vervalsen van de afzender. Ik kan dus prima een phishing email sturen vanaf ik@mijnphisingsite als de verzenden mailserver vermeld staat in het record zal het, zelfs als je heel strikt controleer, de e-mail binnenkrijgen.
Een email verzonden van security@neem_een_bank zal, als de houder van die domeinnaam een txt record SPF toe heeft gevoegd niet binnenkomen.

Kortom, het voorkomt spam en phising niet. Maar wel dat het afzenderadres wordt vervalst. Als jij iets anders denk ben jij zelf degene die niet snapt hoe het in elkaar steekt.

Ignorance is bliss, zullen we maar weer zeggen Je spreekt jezelf daarnaast ook nog eens tegen:

Oorspronkelijk geplaatst door crazycoder

Een email verzonden van security@neem_een_bank zal, als de houder van die domeinnaam een txt record SPF toe heeft gevoegd niet binnenkomen.

Kortom, het voorkomt spam en phising niet. Maar wel dat het afzenderadres wordt vervalst. Als jij iets anders denk ben jij zelf degene die niet snapt hoe het in elkaar steekt.

Je zegt eerst dat het het vervalsen van de afzender voorkomt. Daarna stel je dat het geen phishing voorkomt. Dit is tegenstrijdig. Waarom? Bij vrijwel alle phishing emails wordt het adres van de afzender vervalst. Als jij een phishing email van paypal.com wilt versturen, laat je het lijken dat het emailtje van paypal.com afkomt.


Daarnaast, gaat het weldegelijk spam tegen, mits het domein van de afzender een SPF record heeft. Stel jij stuurt nu een emailtje van @solidhost.com, en de ontvanger gebruikt SPF filtering, dan zal dat emailtje niet aankomen, omdat wij een SPF record hebben waarin de toegestane mailservers voor solidhost.com vermeld staan.

Hoe voorkomt dat spam? Vrijwel alle spam gebruikt vervalste afzender adressen. Stel dat een spammer de domeinnaam solidhost.com als afzender gebruikt, en stuurt een spam bericht naar een mailserver die SPF filtering gebruikt, dan zal die email niet aankomen.

Hotmail heeft al zware klappen gekregen met de opkomst van GMAIL, en ik vrees een beetje dat wat in de openingspost staat wel eens de doodsteek zal kunnen zijn. Zoals hier al gezegd staat de techniek achter het Sender ID nog lang niet op punt en in mijn opinie is het dan ook niet echt aan te raden nu al een dergelijk drastische maatregel aan te kondigen. Wat men wil bereiken is goed, maar de manier waarop en vooral de technologie waarmee is voorlopig niet echt aan te raden.

Verder denk ik dat je hotmail / msn gewoon moet zien als een emailadres voor een live messenger en niet als emailadres om effectief emails mee te versturen. Het is leuk voor de jongere kroost, maar daar blijft het wel bij denk ik.