Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Nieuwe SPF nodig?

181 views
Skip to first unread message

Oscar

unread,
Dec 15, 2021, 6:34:45 AM12/15/21
to
Ik heb een eigen domain waarbij de MX rechtstreeks naar mijn vaste IP wijst.
Om DUL blacklist-ellende te voorkomen, relay ik al mijn uitgaande mail via
smtp.xs4all.nl. Omdat ik soms denk slim te zijn, maar eerlijk gezegd de
ontwikkelingen niet goed genoeg volg, heb ik ooit een TXT record toegevoegd aan
mijn DNS met daarin:

"v=spf1 a mx ip4:194.109.24.0/24 ip6:2001:888:0:108::/64 ip6:2001:888:0:125::/64 -all"

Leek me wel verstandig, want dan wordt het moeilijker om mijn domain te
misbruiken in spamruns. Volgens mij heeft dit ook een hoop backscatter
tegengehouden. Maar ik dwaal af.

Nu merkte ik dat mijn mail niet aan kwam. En ik merkte dat de bounces in mijn
beheerbox terecht kwamen. Dat laatste is erg mooi, waarschijnlijk mogelijk
gemaakt doordat ik me tegenwoordig moet authenticeren bij de smarthost.

De reden van de stagnatie was nu direct duidelijk:

This is the mail system at host ewsoutbound.kpnmail.nl.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

<$RECIPIENT> failed: host mx10.se.isp-net.nl (82.215.18.99) said:
550 195.121.94.183 is not allowed to send mail from $DOMAIN.nu. Please see
the SPF record, with scope mfrom, identity $LUSER, and ip 195.121.94.183
(in reply to EOD command)

Dus is nu de vraag: wat is nu een veilige waarde voor mijn SPF record?
--
[J|O|R] <- .signature.gz

Oscar

unread,
Dec 15, 2021, 7:19:31 AM12/15/21
to
In article <spcjsj$5mm$1...@gioia.aioe.org>, Oscar <jornws...@xs4all.nl> wrote:
>Ik heb een eigen domain waarbij de MX rechtstreeks naar mijn vaste IP wijst.
>Om DUL blacklist-ellende te voorkomen, relay ik al mijn uitgaande mail via
>smtp.xs4all.nl. Omdat ik soms denk slim te zijn, maar eerlijk gezegd de
>ontwikkelingen niet goed genoeg volg, heb ik ooit een TXT record toegevoegd aan
>mijn DNS met daarin:
>
> "v=spf1 a mx ip4:194.109.24.0/24 ip6:2001:888:0:108::/64 ip6:2001:888:0:125::/64 -all"
[...]
>Dus is nu de vraag: wat is nu een veilige waarde voor mijn SPF record?

Kan ik gewoon de spf van xs4all.nl overnemen?

"v=spf1 include:spf-for-dmarc.xs4all.nl include:spf.ews.kpnxchange.com ~all"

Ik raak een beetje in de war van "spf-for-dmarc". Moet ik voor dmarc iets doen?

/me gaat even wat googlen. "Wat is DMARC"

Jan-Pieter Cornet

unread,
Dec 15, 2021, 8:08:11 AM12/15/21
to
On 15-12-21 12:34, Oscar wrote:
> Ik heb een eigen domain waarbij de MX rechtstreeks naar mijn vaste IP wijst.
> Om DUL blacklist-ellende te voorkomen, relay ik al mijn uitgaande mail via
> smtp.xs4all.nl. Omdat ik soms denk slim te zijn, maar eerlijk gezegd de
> ontwikkelingen niet goed genoeg volg, heb ik ooit een TXT record toegevoegd aan
> mijn DNS met daarin:
>
> "v=spf1 a mx ip4:194.109.24.0/24 ip6:2001:888:0:108::/64 ip6:2001:888:0:125::/64 -all"

Mja, dat gaat nu stuk, nu smtp.xs4all.nl naar KPN infra wijst.

Ik zou die IP adressen weghalen en daar neerzetten:

"v=spf1 a mx include:spf-considered-harmful.xs4all.nl ~all"

Dat SPF record omvat de xs4all uitgaande IP ranges, en de KPN uitgaande IP ranges.

En ~all ipv -all omdat dat praktisch gezien hetzelfde is. Als je echt wilt dat fake mail gereject
wordt, dan zou ik helemaal niet vertrouwen op SPF, maar alleen op DMARC en DKIM, of eventueel
een heel gelimiteerd SPF record met alleen "v=spf1 a ?all" er in of zo.

Er zijn niet zo veel partijen die ook echt blokkeren op SPF.

> Nu merkte ik dat mijn mail niet aan kwam. En ik merkte dat de bounces in mijn
> beheerbox terecht kwamen. Dat laatste is erg mooi, waarschijnlijk mogelijk
> gemaakt doordat ik me tegenwoordig moet authenticeren bij de smarthost.

Yep, da's ook nieuw vanwege de KPN SMTP server. Is idd wel netjes, bounces altijd in je inbox.

--
Jan-Pieter Cornet
Any sufficiently advanced incompetence is indistinguishable from malice
- Grey's Law

Oscar

unread,
Dec 15, 2021, 9:41:13 AM12/15/21
to
In article <61b9e8b9$0$28727$e4fe...@usenet.xs4all.nl>,
Jan-Pieter Cornet <joh...@xs4all.nl> wrote:
> "v=spf1 a mx include:spf-considered-harmful.xs4all.nl ~all"

Dank je!

Mooi ook hoe jullie nog altijd een beetje mogen spelen met namen. Doet me
denken aan de tijd van tisnix en twasnix. <snif>

Wel jammer dat er op poort 443 niet wat uitleg staat...


>Er zijn niet zo veel partijen die ook echt blokkeren op SPF.

In mijn geval was het precies 1 teveel. ;-)


>> Nu merkte ik dat mijn mail niet aan kwam. En ik merkte dat de bounces in mijn
>> beheerbox terecht kwamen. Dat laatste is erg mooi, waarschijnlijk mogelijk
>> gemaakt doordat ik me tegenwoordig moet authenticeren bij de smarthost.
>Yep, da's ook nieuw vanwege de KPN SMTP server. Is idd wel netjes, bounces altijd in je inbox.

Toch nog een heel klein lichtpuntje.

Jan-Pieter Cornet

unread,
Dec 16, 2021, 8:55:03 AM12/16/21
to
On 15-12-21 13:19, Oscar wrote:
> Kan ik gewoon de spf van xs4all.nl overnemen?
>
> "v=spf1 include:spf-for-dmarc.xs4all.nl include:spf.ews.kpnxchange.com ~all"
>
> Ik raak een beetje in de war van "spf-for-dmarc". Moet ik voor dmarc iets doen?
>
> /me gaat even wat googlen. "Wat is DMARC"

Mail authenticatie, ik neem aan dat google je t wel kon vertellen. Hier nog wat achtergrond: https://blog.xs4all.nl/xs4all-en-ing-samen-valse-e-mails-te-lijf/

... we waren de eerste in europa die DMARC volledig supporten, voor ontvangers (en nog steeds 1 van de weinige partijen die reporting en rejections goed doen).

Maar... nee, je moet niet spf-for-dmarc gebruiken als je domein niet in de "doet DMARC" configuratie bij xs4all staat (zoals xs4all.nl en xs4all.net). Het sluit namelijk een paar uitgaande IPs uit van SPF authentication, zodat alleen goed geauthenticeerde berichten met een DMARC seal uitgestuurd worden.

Magoed... beetje wassen neus nu de KPN mail servers er ook bij staan, en die ook gewoon mail uitsturen voor t xs4all.nl domein, zonder rekening te houden met wie wie is.

Oscar

unread,
Dec 16, 2021, 9:20:21 AM12/16/21
to
In article <61bb426d$0$9995$e4fe...@usenet.xs4all.nl>,
Jan-Pieter Cornet <joh...@xs4all.nl> wrote:
>Magoed...

Sterkte met het verlies.

Harmen van der Wal

unread,
Dec 16, 2021, 12:08:04 PM12/16/21
to
Jan-Pieter Cornet <joh...@xs4all.nl> writes:
> ... we waren de eerste in europa die DMARC volledig supporten, voor
> ontvangers (en nog steeds 1 van de weinige partijen die reporting en
> rejections goed doen).

De _enige_ DMARC rapporten die ik tot nu toe überhaupt mocht ontvangen,
kwamen van xs4all :) Hartelijk dank daarvoor!

(Nou verstuur ik weliswaar heel weinig email, maar toch.)

--
(setq message-signature (lambda () ; Harmen van der Wal
(end-of-buffer) ; http://harmen.vanderwal.eu
(insert "\n-- \n")
(insert-file "~/.signature")))

Jan-Pieter Cornet

unread,
Dec 16, 2021, 5:05:02 PM12/16/21
to
On 16-12-21 15:20, Oscar wrote:
> In article <61bb426d$0$9995$e4fe...@usenet.xs4all.nl>,
> Jan-Pieter Cornet <joh...@xs4all.nl> wrote:
>> Magoed...
>
> Sterkte met het verlies.

"Frozen" maar weer es opzetten met kerst.

Arnold

unread,
Dec 17, 2021, 3:00:45 AM12/17/21
to
Op 17-12-2021 om 07:25 schreef Eveline:
> Jan-Pieter Cornet schreef:
>> On 16-12-21 15:20, Oscar wrote:
>>> In article <61bb426d$0$9995$e4fe...@usenet.xs4all.nl>,
>>> Jan-Pieter Cornet <joh...@xs4all.nl> wrote:
>>>> Magoed...
>>>
>>> Sterkte met het verlies.
>>
>> "Frozen" maar weer es opzetten met kerst.
>
> Het nummer van Madonna, of de tekenfilm? En op welke manier is dat hier
> passend?

laat het los, laat het gaan.....

Arnold.

Rob

unread,
Dec 17, 2021, 7:35:37 AM12/17/21
to
Harmen van der Wal <nos...@invalid.invalid> wrote:
> Jan-Pieter Cornet <joh...@xs4all.nl> writes:
>> ... we waren de eerste in europa die DMARC volledig supporten, voor
>> ontvangers (en nog steeds 1 van de weinige partijen die reporting en
>> rejections goed doen).
>
> De _enige_ DMARC rapporten die ik tot nu toe überhaupt mocht ontvangen,
> kwamen van xs4all :) Hartelijk dank daarvoor!
>
> (Nou verstuur ik weliswaar heel weinig email, maar toch.)

DMARC rapporten krijg je niet van mail die je verstuurt, maar van mail
die ANDEREN versturen met jouw domein als afzender. Het enige geval wat
daarbij aan jouw eigen mail gerelateerd is, is als mensen een forward
ingesteld hebben staan die jouw mail doorstuurt naar een andere provider,
en die provider stuurt DMARC rapporten. Gmail bijvoorbeeld, of Outlook.com.
Je krijgt dan vaak rapporten dat er mail ontvangen is waarvan de SPF
niet klopte maar de DKIM wel. Of, als het doorsturende systeem erg
kapot is, ook dat DKIM niet klopte.

Als je domein voor joe-jobs (vervalste afzender) misbruikt wordt dan
krijg je veel meer van die rapporten, maar dat zijn vaak korte bursts
of je hebt er helemaal geen last van op je prive domein.

Harmen van der Wal

unread,
Dec 17, 2021, 9:08:05 AM12/17/21
to
Rob <nom...@example.com> writes:

> DMARC rapporten krijg je niet van mail die je verstuurt, maar van mail
> die ANDEREN versturen met jouw domein als afzender.

Nou, ik dacht dat ook als je de mail zelf verstuurd hebt (dus met goeie
DKIM signature en/of SPF bron), dat je dan toch daarvan wel
zgn. aggregate reports kan ontvangen. En xs4all stuurt die dus. (En ik
zelf trouwens ook.)

Rob

unread,
Dec 17, 2021, 11:14:52 AM12/17/21
to
Harmen van der Wal <nos...@invalid.invalid> wrote:
> Rob <nom...@example.com> writes:
>
>> DMARC rapporten krijg je niet van mail die je verstuurt, maar van mail
>> die ANDEREN versturen met jouw domein als afzender.
>
> Nou, ik dacht dat ook als je de mail zelf verstuurd hebt (dus met goeie
> DKIM signature en/of SPF bron), dat je dan toch daarvan wel
> zgn. aggregate reports kan ontvangen. En xs4all stuurt die dus. (En ik
> zelf trouwens ook.)

Eh ja dat klopt, ik was even in de war tussen de "ruf" en "rua" instelling.
Ik heb zelf hier alleen "ruf" maar op het werk ook "rua" ingesteld en
dan krijg je inderdaad reports van al je mail.

Roger

unread,
Dec 17, 2021, 2:01:41 PM12/17/21
to
Hadden ze dit onderscheid ook maar gemaakt bij TLSRPT (RFC 8460)! In een vroege
draft stonden zowel "rua" als "ruf", maar alleen "rua" heeft de RFC gehaald (geen
idee waarom). Ik heb uiteindelijk maar een filter router gemaakt in Exim die
reports zonder failures richting bitbucket dirigeert.

Groeten,
-Roger

Rob

unread,
Dec 18, 2021, 4:01:50 AM12/18/21
to
Het probleem zal wellicht geweest zijn "wat is een failure"?
Bijv bij DMARC krijg je met rua ook alle gevallen binnen waarin DKIM
OF SPF een fout gaf maar een van beiden dus OK was en het mailtje uiteindelijk
wel geaccepteerd is. Is dat een failure of niet? Volgens DMARC kennelijk
niet want daar wordt geen "ruf" rapport voor gestuurd. Maar wellicht
zien sommigen dat toch anders.

Roger

unread,
Dec 18, 2021, 5:38:50 AM12/18/21
to
On 2021/12/18 10:01, Rob wrote:
> Roger <nosuc...@example.com> wrote:
>> On 2021/12/17 17:14, Rob wrote:
>>> Harmen van der Wal <nos...@invalid.invalid> wrote:
>>>> Rob <nom...@example.com> writes:
>>>>
>>>>> DMARC rapporten krijg je niet van mail die je verstuurt, maar van mail
>>>>> die ANDEREN versturen met jouw domein als afzender.
>>>>
>>>> Nou, ik dacht dat ook als je de mail zelf verstuurd hebt (dus met goeie
>>>> DKIM signature en/of SPF bron), dat je dan toch daarvan wel
>>>> zgn. aggregate reports kan ontvangen. En xs4all stuurt die dus. (En ik
>>>> zelf trouwens ook.)
>>>
>>> Eh ja dat klopt, ik was even in de war tussen de "ruf" en "rua" instelling.
>>> Ik heb zelf hier alleen "ruf" maar op het werk ook "rua" ingesteld en
>>> dan krijg je inderdaad reports van al je mail.
>>
>> Hadden ze dit onderscheid ook maar gemaakt bij TLSRPT (RFC 8460)! In een vroege
>> draft stonden zowel "rua" als "ruf", maar alleen "rua" heeft de RFC gehaald (geen
>> idee waarom). Ik heb uiteindelijk maar een filter router gemaakt in Exim die
>> reports zonder failures richting bitbucket dirigeert.
>
> Het probleem zal wellicht geweest zijn "wat is een failure"?

Ik weet niet of dat het probleem was. Ik krijg nu vrijwel dagelijks reports
van Google en/of Microsoft waarin zowel total-successful-session-count als
total-failure-session-count nul is. Kennelijk zijn successful en failure wel
voldoende gedefinieerde begrippen. Als TLSRPT ook "ruf" zou kennen, dan lijkt
mij "total-failure-session-count != 0" de triviale conditie voor het al dan
niet verzenden van een report.

> Bijv bij DMARC krijg je met rua ook alle gevallen binnen waarin DKIM
> OF SPF een fout gaf maar een van beiden dus OK was en het mailtje uiteindelijk
> wel geaccepteerd is. Is dat een failure of niet? Volgens DMARC kennelijk
> niet want daar wordt geen "ruf" rapport voor gestuurd. Maar wellicht
> zien sommigen dat toch anders.

Dat kun je bij DMARC in geval van "ruf" zelf kiezen met de "fo" tag (al is
het niet verplicht voor report generators om hier rekening mee te houden;
YMMV). Het gedrag dat jij beschrijft is wel de default.

Groeten,
-Roger

Roger

unread,
Dec 18, 2021, 7:42:17 AM12/18/21
to
On 2021/12/18 11:38, Roger wrote:
> On 2021/12/18 10:01, Rob wrote:
>> Roger <nosuc...@example.com> wrote:
>>> On 2021/12/17 17:14, Rob wrote:
>>>> Harmen van der Wal <nos...@invalid.invalid> wrote:
>>>>> Rob <nom...@example.com> writes:
>>>>>
>>>>>> DMARC rapporten krijg je niet van mail die je verstuurt, maar van mail
>>>>>> die ANDEREN versturen met jouw domein als afzender.
>>>>>
>>>>> Nou, ik dacht dat ook als je de mail zelf verstuurd hebt (dus met goeie
>>>>> DKIM signature en/of SPF bron), dat je dan toch daarvan wel
>>>>> zgn. aggregate reports kan ontvangen. En xs4all stuurt die dus. (En ik
>>>>> zelf trouwens ook.)
>>>>
>>>> Eh ja dat klopt, ik was even in de war tussen de "ruf" en "rua" instelling.
>>>> Ik heb zelf hier alleen "ruf" maar op het werk ook "rua" ingesteld en
>>>> dan krijg je inderdaad reports van al je mail.
>>>
>>> Hadden ze dit onderscheid ook maar gemaakt bij TLSRPT (RFC 8460)! In een vroege
>>> draft stonden zowel "rua" als "ruf", maar alleen "rua" heeft de RFC gehaald (geen
>>> idee waarom). Ik heb uiteindelijk maar een filter router gemaakt in Exim die
>>> reports zonder failures richting bitbucket dirigeert.
>>
>> Het probleem zal wellicht geweest zijn "wat is een failure"?
>
> Ik weet niet of dat het probleem was. Ik krijg nu vrijwel dagelijks reports
> van Google en/of Microsoft waarin zowel total-successful-session-count als
> total-failure-session-count nul is.

Iets te snel geschreven... De eerste is uiteraard niet nul (anders komt er geen
report), maar de tweede wel. Ik heb voor zover ik mij kan herinneren nog geen
report gekregen met "total-failure-session-count != 0".
0 new messages