SPF en smtp.xs4all.nl

Jeroen Feelders

unread,

Jun 20, 2012, 2:56:15 AM6/20/12

to

Ik gebruik de smtp-server van xs4all.nl (SSL met login) om mail van mijn
eigen domein (feelders.com) te versturen. Dit ging altijd goed. Zojuist
kreeg ik een foutmelding voor een verstuurd mailtje terug dat de SPF die
ik op feelders.com had ingesteld (mx:xs4all.nl/24) niet goed ging. De
afzender zou mail1.bemta5.messagelabs.com zijn. Maakt xs4all sinds kort
gebruik van messagelabs om mail te versturen? Dan moet ik die natuurlijk
opnemen in mijn SPF.

Jeroen

Rob

unread,

Jun 20, 2012, 3:04:01 AM6/20/12

to

Ik denk eerder dat je mail nog ergens geforward is.

Sommige mensen laten hun mail forwarden en gaan dan op het ontvangende
systeem evengoed SPF checken. Dat werkt natuurlijk niet.

Miquel van Smoorenburg

unread,

Jun 20, 2012, 4:52:49 AM6/20/12

to

In article <4fe17412$0$6923$e4fe...@news.xs4all.nl>,

Nee, dat doet xs4all niet. Verder valt er niks over te zeggen
zonder de foutmelding te zien.

Mike.

Operator

unread,

Jun 20, 2012, 5:10:11 AM6/20/12

to

In article <4fe17412$0$6923$e4fe...@news.xs4all.nl>,

Nee. SPF moet je uit zetten.
Dan werkt alles weer.

Rob van der Putten

unread,

Jun 20, 2012, 7:29:41 AM6/20/12

to

Hoi

Als mail die binnkomt op messagelabs word doorgestuurd naar iemand die
een SPF check doet, krijg je dit.

SPF moet je gewoon niet combineren met forwards.

Vr.Gr,
Rob
--
Calories suck. Use Joules instead.

Jeroen Feelders

unread,

Jun 20, 2012, 11:49:49 AM6/20/12

to

Zie
http://www.openspf.org/Why?id=jer...@feelders.com&ip=195.245.231.130&receiver=spfquery

Op 20-06-12 10:52, Miquel van Smoorenburg schreef:

Miquel van Smoorenburg

unread,

Jun 20, 2012, 11:55:03 AM6/20/12

to

In article <4fe1f121$0$6880$e4fe...@news.xs4all.nl>,
Jeroen Feelders <jer...@feelders.com> wrote:
>Zie
>http://www.openspf.org/Why?id=jer...@feelders.com&ip=195.245.231.130&receiver=spfquery

het enige wat hiermee te zeggen is, is dat blijkbaar "iets"
mail heeft verstuurd via mail1.bemta5.messagelabs.com (195.245.231.130)
met in de envelope-from jer...@feelders.com.

Wat dat "iets" is is niets te zeggen zonder de headers van
het bericht te zien.

Mike.

Jeroen Feelders

unread,

Jun 20, 2012, 2:41:45 PM6/20/12

to

Message-ID: <4FE16DCD...@feelders.com>
Disposition-Notification-To: Jeroen Feelders <jer...@feelders.com>
Date: Wed, 20 Jun 2012 08:29:33 +0200
From: Jeroen Feelders <jer...@feelders.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614
Thunderbird/13.0.1
MIME-Version: 1.0
To: in...@sunweb.nl
Subject: Vragen over reserveringsnummer 1567025
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Op 20-06-12 17:55, Miquel van Smoorenburg schreef:

Sylvester

unread,

Jun 20, 2012, 2:46:18 PM6/20/12

to

Op 20-06-12 20:41, Jeroen Feelders schreef:

Hier staat hoe je de volledige headers kunt raadplegen/lezen:

http://www.xs4all.nl/klant/helpdesk/email/spam/headerslezen.php

Rob

unread,

Jun 20, 2012, 2:53:08 PM6/20/12

to

Jeroen Feelders <jer...@feelders.com> wrote:
> Message-ID: <4FE16DCD...@feelders.com>
> Disposition-Notification-To: Jeroen Feelders <jer...@feelders.com>
> Date: Wed, 20 Jun 2012 08:29:33 +0200
> From: Jeroen Feelders <jer...@feelders.com>
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614
> Thunderbird/13.0.1
> MIME-Version: 1.0
> To: in...@sunweb.nl
> Subject: Vragen over reserveringsnummer 1567025
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit

sunweb.nl heeft inderdaad messagelabs als MX server staan.
die filteren de mail en sturen het weer door naar de eigen server
van sunweb. en die is kennelijk fout geconfigureerd... in een
dergelijke situatie moet je namelijk GEEN SPF gebruiken.

de fout ligt dus niet bij jou of bij XS4ALL maar bij de sunweb IT
afdeling.

Osiris

unread,

Jun 20, 2012, 3:48:09 PM6/20/12

to

Óf een bekende forwarder uit je headers slopen, wat prima kan in Postfix
met de `header_checks`-optie. Doe ik ook met XS4ALL's forwarder (bsmtp)
en kan alsnog checken op SPF, doordat de tussenstap er niet meer in
staat. En da's natuurlijk mogelijk, omdat de headers van XS4ALL
simpelweg bekend zijn.

Osiris

unread,

Jun 20, 2012, 3:48:21 PM6/20/12

to

Jeroen Feelders

unread,

Jun 21, 2012, 12:17:05 AM6/21/12

to

OK, bedankt voor je onderzoek en je uitleg!

Jeroen

Op 20-06-12 20:53, Rob schreef:

Rob

unread,

Jun 21, 2012, 1:34:48 AM6/21/12

to

Uiteraard zijn de headers van XS4ALL in deze niet relevant.
Het probleem zit bij de combinatie messagelabs en sunweb.

Osiris

unread,

Jun 21, 2012, 3:57:14 PM6/21/12

to

Excuus, ik bedoelde 't niet met betrekking tot deze casus, maar in het
algemeen bij 'forwarders', zoals ook XS4ALL doet met hun bSMTP.

Indien het 'einddoel' (welke immers ook de SPF-check doet) zich bewust
is van de forwarding, dan kan hij, zoals ik uitlegde, daar naar handelen.

Jan-Pieter Cornet

unread,

Jul 3, 2012, 10:19:08 AM7/3/12

to

In article <slrnju470k...@xs8.xs4all.nl>,
Rob <nom...@example.com> wrote:
>Jeroen Feelders <jer...@feelders.com> wrote:
>> From: Jeroen Feelders <jer...@feelders.com>
[...]

>sunweb.nl heeft inderdaad messagelabs als MX server staan.
>die filteren de mail en sturen het weer door naar de eigen server
>van sunweb. en die is kennelijk fout geconfigureerd... in een
>dergelijke situatie moet je namelijk GEEN SPF gebruiken.
>
>de fout ligt dus niet bij jou of bij XS4ALL maar bij de sunweb IT
>afdeling.

Een klein beetje wel. Je gebruikt namelijk "-all" in je SPF record, en
dat is vragen om problemen, precies het soort problemen waar je hierover
post.

Ik raad je aan om ~all te gebruiken (softfail). SPF is evil. Het is niet
voor niets dat we de officiele xs4all spf policy publiceren op
spf-considered-harmful.xs4all.nl (mochten we dat overigens wijzigen, dan
wijzigen we dat TXT/SPF record, en roepen dat niet noodzakelijk overal
van te voren rond. Wil je echt SPF gebruiken dan kun je beter dat record
includen.)

--
Jan-Pieter Cornet <joh...@xs4all.nl>
"People are continuously reinventing the flat tyre".

Rob

unread,

Jul 3, 2012, 11:52:07 AM7/3/12

to

Ik vind dat nogal onzinnig. SPF is prima voor bepaalde doeleinden, zoals
bijvoorbeeld het beschermen van je domein tegen misbruik door spoofers,
phishers, e.d.

Als je zelf iets gaat doen wat de bron van de mail loskoppelt van het
afzender domain, zoals het forwarden van mail of gebruiken van zo'n
spam scanning service die je mail doorstuurt, dan ben je ook zelf
verantwoordelijk voor de correcte inzet van SPF.

Daarnaast zijn er nog wel eens wat kleine probleempjes doordat bedrijven
SPF aanzetten en dat dan vergeten, en vervolgens hun mail configuratie
gaan verbouwen (misschien is dit in Sunweb's geval ook wel de oorzaak),
maar gemiddeld zie ik maar heel weinig problemen met SPF.

En dat terwijl we softfail behandelen als fail in de puntenwaardering voor
spam.

Roger Hünen

unread,

Jul 3, 2012, 1:28:59 PM7/3/12

to

On 2012/07/03 17:52, Rob wrote:
> Als je zelf iets gaat doen wat de bron van de mail loskoppelt van het
> afzender domain, zoals het forwarden van mail of gebruiken van zo'n
> spam scanning service die je mail doorstuurt, dan ben je ook zelf
> verantwoordelijk voor de correcte inzet van SPF.

Dan sta je toch voor een uitdaging. Stel je forwardt op de mailserver van
domain1 alle mail voor account1@domain1 naar account2@domain2. In dat geval
zou je de ontvangende server van domain2 zo moeten configureren dat deze
door domain1 geforwarde mail accepteert (aanpassen van de SPF-records van
de originele sender domains is uiteraard geen optie).

Maar dat heeft twee bezwaren:
- je weet vaak niet wie domain1 is omdat gebruikers zelf forwards instellen
voor accounts in hun domain1
- je wordt voor je spambeststrijding deels afhankelijk van domain1; vraag
is of je dat acceptabel vindt

Mijn ervaring is dat mail forwarding en SPF maar moeilijk samen gaan.

> Daarnaast zijn er nog wel eens wat kleine probleempjes doordat bedrijven
> SPF aanzetten en dat dan vergeten, en vervolgens hun mail configuratie
> gaan verbouwen

Breek me de bek niet open...

> (misschien is dit in Sunweb's geval ook wel de oorzaak), maar gemiddeld zie
> ik maar heel weinig problemen met SPF.

Mee eens. Beheerders die SPF aanzetten voor hun domein weten in het algemeen
wat ze doen. En zij die dat niet weten, weten vaak niet eens wat SPF is en
zullen het dus ook niet aanzetten :) Waar het nog mis kan gaan is uiteraard
bij een wisseling van de beheerwacht (gebrekkige documentatie, etc.).

Groeten,
-Roger

Rob

unread,

Jul 3, 2012, 1:41:17 PM7/3/12

to

Roger Hünen <rhu...@xs4all.nl> wrote:
> On 2012/07/03 17:52, Rob wrote:
>> Als je zelf iets gaat doen wat de bron van de mail loskoppelt van het
>> afzender domain, zoals het forwarden van mail of gebruiken van zo'n
>> spam scanning service die je mail doorstuurt, dan ben je ook zelf
>> verantwoordelijk voor de correcte inzet van SPF.
>
> Dan sta je toch voor een uitdaging. Stel je forwardt op de mailserver van
> domain1 alle mail voor account1@domain1 naar account2@domain2. In dat geval
> zou je de ontvangende server van domain2 zo moeten configureren dat deze
> door domain1 geforwarde mail accepteert (aanpassen van de SPF-records van
> de originele sender domains is uiteraard geen optie).

Uiteraard.
Je kunt geen mail forwarden naar domains die je niet onder controle hebt.
Maar dat vind ik niet zo'n probleem.

> Maar dat heeft twee bezwaren:
> - je weet vaak niet wie domain1 is omdat gebruikers zelf forwards instellen
> voor accounts in hun domain1
> - je wordt voor je spambeststrijding deels afhankelijk van domain1; vraag
> is of je dat acceptabel vindt

Spam kun je zowizo alleen effectief bestrijden op de eerste server die
het ontvangt. Een compromis kan nog zijn om naar de headers te kijken
die die server toevoegt, maar dan moet die server wel te vertrouwen zijn.

Jan-Pieter Cornet

unread,

Jul 4, 2012, 5:59:23 PM7/4/12

to

In article <slrnjv6597...@xs8.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Ik vind dat nogal onzinnig. SPF is prima voor bepaalde doeleinden, zoals
>bijvoorbeeld het beschermen van je domein tegen misbruik door spoofers,
>phishers, e.d.

Eh, nee. Historie heeft geleerd dat het daar juist NIET voor geschikt
is. SPF is alleen geschikt als onderdeel van een whitelist.

DMARC is juist een tool die bedoelt is om je domein egen misbruik door
spoofers en phishers te beschermen ;)

>Als je zelf iets gaat doen wat de bron van de mail loskoppelt van het
>afzender domain, zoals het forwarden van mail of gebruiken van zo'n
>spam scanning service die je mail doorstuurt, dan ben je ook zelf
>verantwoordelijk voor de correcte inzet van SPF.

Probleem is dat de verzender dat vrijwel nooit controleert. Het
forwarden van mail gebeurd door de ontvanger.

>En dat terwijl we softfail behandelen als fail in de puntenwaardering voor
>spam.

Ah! Daar zijn we het tenminste over eens, dat doen we bij XS4ALL ook
(beide geven 0.01 punten ;)

Rob

unread,

Jul 5, 2012, 3:31:14 AM7/5/12

to

Jan-Pieter Cornet <joh...@xs4all.net> wrote:
> In article <slrnjv6597...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Ik vind dat nogal onzinnig. SPF is prima voor bepaalde doeleinden, zoals
>>bijvoorbeeld het beschermen van je domein tegen misbruik door spoofers,
>>phishers, e.d.
>
> Eh, nee. Historie heeft geleerd dat het daar juist NIET voor geschikt
> is. SPF is alleen geschikt als onderdeel van een whitelist.

EH?
Als ik phishing van allerlei banken keurig hun SPF puntjes zie krijgen
en daardoor in het spamfilter komen, waarom is het daar dan niet geschikt
voor?

> DMARC is juist een tool die bedoelt is om je domein egen misbruik door
> spoofers en phishers te beschermen ;)

DMARC is alleen maar weer een laagje bovenop SPF.

>>Als je zelf iets gaat doen wat de bron van de mail loskoppelt van het
>>afzender domain, zoals het forwarden van mail of gebruiken van zo'n
>>spam scanning service die je mail doorstuurt, dan ben je ook zelf
>>verantwoordelijk voor de correcte inzet van SPF.
>
> Probleem is dat de verzender dat vrijwel nooit controleert. Het
> forwarden van mail gebeurd door de ontvanger.

Dat maakt ook niet uit. Degene die mail forward is er verantwoordelijk
voor dat op de plek waar hij de mail heen forward de SPF correct
afgehandeld wordt. Dus ofwel niet, ofwel op de juiste header line.
De verzender hoeft daar verder niks aan te doen.

>>En dat terwijl we softfail behandelen als fail in de puntenwaardering voor
>>spam.
>
> Ah! Daar zijn we het tenminste over eens, dat doen we bij XS4ALL ook
> (beide geven 0.01 punten ;)

Bij ons 2.2
Werkt prima.