SPF-record hosting provider mixen met Google Mail

[Wolf3D]

Voor een bepaalde website loop ik tegen het probleem aan dat alle e-mails die de website stuurt naar een e-mailadres van hetzelfde domein nooit aankomt. Na enig onderzoek kwam ik uit op de SPF-record. Deze is in het verleden ingesteld voor Google (G Suite), waardoor deze ingesteld stond op:

v=spf1 mx a ptr ip4:[IP-ADRES]/32 include:aspmx.googlemail.com ~all

Na contact met de (nieuwe) hostingprovider (Yourhosting) en na mijn uitleg van het probleem met de e-mail welke nooit aankwam kreeg ik te horen dat ik de SPF-record moest wijzigen naar:

v=spf1 redirect=_spf.hostcontrol.com

Nu moet ik deze twee records volgens mij mixen, maar voordat ik dingen kapot maak wil ik hier even controleren of dit klopt:

v=spf1 ip4:[IP-ADRES]/32 include:aspmx.googlemail.com ~all redirect=_spf.hostcontrol.com

Volgens deze tool http://www.kitterman.com/spf/validate.html, is het SPF record in ieder geval valide, maar ik vraag me af of doet wat het zou moeten doen? Na enige research heb ik gevonden dat de redirect altijd achteraan moet, maar gezien dit alles vrij nieuw terrein is voor me toch nog even een dubbelcheck hier of ik het goede aan het doen ben.

Misschien nog wat relevante communicatie tussen mij en Yourhosting:
Yourhosting: u moet de a mx en de ptr gedeelte er uit halen
Yourhosting: en bij de google stukje, onze hostcontrol er aan toevoegen (de hostname die in de e-mail staat).
Ik: Ik dacht dat die MX records juist wel nodig waren (Allow servers listed as MX to send email for this domain). Die instellingen moest ik juist voor Google instellen.
Yourhosting: klopt maar onze MX servers zijn NIET onze uitgaande mailservers

Dus uit alle informatie en Google bronnen kom ik tot de hierboven eerder genoemde regel:
v=spf1 ip4:[IP-ADRES]/32 include:aspmx.googlemail.com ~all redirect=_spf.hostcontrol.com

Correct?

[Qwerty-273]

De website van Scott is inderdaad voor SPF een zeer goede bron. Zijn jullie volledig over naar Yourhosting? Of loopt een deel van de mail nog via Google? Als je volledig overbent, heeft het natuurlijk geen nut meer om het Google deel nog in je SPF te laten zitten.

Verder de bekende valkuilen http://www.openspf.org/FAQ/Common_mistakes

Ook als je een redirect doet, heeft het weinig nut om in de eerste een softfail op all te doen. Zeker niet wanneer de SPF voor _spf.hostcontrol.com gewoon "dom" is. Want dat is "v=spf1 +all", wat dus inhoud dat wat je ook probeert te excluden, het door je redirect nutteloos wordt want die zet het naar pass all........

[Wolf3D]

Thanks voor je antwoord!
Eigenlijk loopt alles juist via Google. POP en IMAP van Yourhosting wordt dus NIET gebruikt. Aangezien de MX-records zijn ingesteld zoals door Google zelf aangegeven (https://support.google.com/a/answer/33915?hl=nl), dacht ik dat ALLE mail afhandeling door Google gedaan werd en ook de Yourhosting server Google gebruikt voor het versturen van de e-mail. Ik maak dus ergens een denkfout...

Eerlijk gezegd snap ik ook niet meer precies wat ik aan het doen ben. Die SPF-records bepalen welke servers namens de domeinnaam e-mail mogen verzenden, als ik het goed begrijp. Maar als de Yourhosting server zelf geen e-mail verstuurt maar Google gebruikt, waarom volstaat dan niet alleen de SPF-record van Google (1e SPF record in mijn openingspost).

[CyBeR]

Wolf3D schreef op dinsdag 08 november 2016 @ 23:54:

Yourhosting: en bij de google stukje, onze hostcontrol er aan toevoegen (de hostname die in de e-mail staat).

Als include ja. Met redirect geef je het beheer geheel over aan een ander record.

Ik: Ik dacht dat die MX records juist wel nodig waren (Allow servers listed as MX to send email for this domain). Die instellingen moest ik juist voor Google instellen.
Yourhosting: klopt maar onze MX servers zijn NIET onze uitgaande mailservers

Google's mx servers worden ook niet uitgaand gebruikt. Je hebt aan de includes genoeg.

Dus uit alle informatie en Google bronnen kom ik tot de hierboven eerder genoemde regel:
v=spf1 ip4:[IP-ADRES]/32 include:aspmx.googlemail.com ~all redirect=_spf.hostcontrol.com

Correct?

Nee.

v=spf1 ip4:ipadres include:aspmx.googlemail.com ~all

En als je zeker bent dat dat klopt, zet 'm dan later naar "-all", zo help je spam voorkomen.

Edit: ik zie nu pas dat die _spf.hostcontrol.com gewoon "v=spf1 +all" is, en niks meer. Dat is dus compleet kansloos, laat maar gewoon weg want daar kun je niks mee. Stap over naar een partij die wél weten wat ze doen.

Voor wat betreft het niet ontvangen van mail: zorg dat mail service bij yourhosting uit staat. Waarschijnlijk vindt de server die je gebruikt om te verzenden dat 'ie ook verantwoordelijk is voor het ontvangen, en dan gaat 't niet naar google toe.

[ Voor 17% gewijzigd door CyBeR op 09-11-2016 11:30 ]

[gekkie]

Aanname is dat die website met mailproblemen gehost is bij yourhosting ?
En het domein en DNS ook ?

Waarschijnlijk haalt yourhosting intern trucjes uit met routen / spf checks voor domeinen waarover ze denken controle te hebben. Waarbij hun configuratie er dus onterecht van uitgaat dat alles bij hun draait. Heb een variant ook al eens aan de hand gehad bij een hoster. Mail werd ergens anders gehost, maar hun smtp server keek niet naar DNS records voor hun bekende domeinen.
Gevolg was dat andere klanten van hun die wel gebruik maakten van hun smtpserver ons niet konden bereiken, want de smtp server probeerde het lokaal te houden.

[Qwerty-273]

Even ter verduidelijking, "v=spf1 +all" betekend dus dat je elke IP address "toestaat" om namens jouw domain e-mail te versturen. Wat wel lekker makkelijk is voor je hoster, want die hoeven dan niks bij te houden als ze iets creatiefs veranderen. Maar maakt het bedoelde gebruik van SPF natuurlijk nutteloos.

En nu ik er nog wat dieper overdenk doet je ~all een softfail (op alles wat tot dan toe niet overeenkwam) die niet wordt rechtgetrokken door de +all in je redirect.

Bij twee testen via Kitterman's website:

Mail sent from this IP address: 9.9.9.9
Mail from (Sender): [e-mail]
Mail checked using this SPF policy: v=spf1 ip4:3.3.3.3/32 include:aspmx.googlemail.com ~all redirect=_spf.hostcontrol.com
Results - softfail domain owner discourages use of this host

Mail sent from this IP address: 9.9.9.9
Mail from (Sender): [e-mail]
Mail checked using this SPF policy: v=spf1 ip4:3.3.3.3/32 include:aspmx.googlemail.com redirect=_spf.hostcontrol.com
Results - PASS sender SPF authorized

Wolf3D schreef op woensdag 09 november 2016 @ 11:20:
Maar als de Yourhosting server zelf geen e-mail verstuurt maar Google gebruikt, waarom volstaat dan niet alleen de SPF-record van Google (1e SPF record in mijn openingspost).

Dat is dan een vraag hoe de website mail verstuurd, wordt dat dan inderdaad via een smarthost van Google gedaan? Of wordt het door de webserver bij Yourhosting direct uitverstuurd naar de MTA's van de ontvangers?

[ Voor 19% gewijzigd door Qwerty-273 op 09-11-2016 11:56 ]

[CyBeR]

Qwerty-273 schreef op woensdag 09 november 2016 @ 11:53:
En nu ik er nog wat dieper overdenk doet je ~all een softfail (op alles wat tot dan toe niet overeenkwam) die niet wordt rechtgetrokken door de +all in je redirect.

Het idee is dat dat bij redirect wel gebeurt. Een +-~all in een include wordt genegeerd.

[Wolf3D]

gekkie schreef op woensdag 09 november 2016 @ 11:27:
Aanname is dat die website met mailproblemen gehost is bij yourhosting ?
En het domein en DNS ook ?

Yes, correct.

CyBeR schreef op woensdag 09 november 2016 @ 11:25:
Voor wat betreft het niet ontvangen van mail: zorg dat mail service bij yourhosting uit staat. Waarschijnlijk vindt de server die je gebruikt om te verzenden dat 'ie ook verantwoordelijk is voor het ontvangen, en dan gaat 't niet naar google toe.

Er staat bij Yourhosting nog niets ingesteld qua e-mail accounts. In admin panel staat onder SMTP:
"Gebruik de uitgaande e-mailserver (SMTP) van je eigen internetprovider." Als ik SMTP wil gebruiken moet ik extra betalen .

Qwerty-273 schreef op woensdag 09 november 2016 @ 11:53:
Dat is dan een vraag hoe de website mail verstuurd, wordt dat dan inderdaad via een smarthost van Google gedaan? Of wordt het door de webserver bij Yourhosting direct uitverstuurd naar de MTA's van de ontvangers?

Hoe test ik dat? De website draait op Drupal 7, in combinatie met webform.

[gekkie]

[quote]Wolf3D schreef op woensdag 09 november 2016 @ 12:02:
[...]
Yes, correct.
[...]
Er staat bij Yourhosting nog niets ingesteld qua e-mail accounts. In admin panel staat onder SMTP:
Gebruik de uitgaande e-mailserver (SMTP) van je eigen internetprovider. Als ik SMTP wil gebruiken moet ik extra betalen .
/quote]
De kans is dus groot dat jouw webserver, hun smtp-server gebruikt.
Waarbij hun smtp-server voor de beslissing waar het mailtje vervolgens naar doorgezet moet worden *niet* gebaseerd is op DNS, maar op een interne database waar jij geen zicht op hebt.
Standaard staat dat bij hun dan waarschijnlijk op intern afhandelen voor domeinen die bij hun geregistreerd staan, dus hun smtp-server gaat het intern proberen af te handelen.

Probeer eens mail te versturen van je mailserver met als verzender een volledig extern account (dus niet bij hun bijvb gmail) en als ontvanger het adres naar waar je nu de mails ook naar probeert te versturen.

Je hebt dan de kans dat je uiteindelijk een foutmelding krijgt op het verzend mailaccount dat die mail niet afleverbaar is gebleken. De smtp-server probeert het dan intern af te handelen, maar omdat je geen accounts hebt ingesteld kan het nergens heen en wordt het uiteindelijk gedropped.
Als je wel een verzendadres hebt waar een bounce heen kan dan zou dat moeten gebeuren en weet je dat het dus aan dit fenomeen ligt (en dus niet aan SPF records).

[Qwerty-273]

CyBeR schreef op woensdag 09 november 2016 @ 11:58:
Het idee is dat dat bij redirect wel gebeurt. Een +-~all in een include wordt genegeerd.

Ja maar, ja maar, ja maar

Als je kijkt naar http://www.ietf.org/rfc/rfc4408.txt

4.6.2. Mechanisms
Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is specified in Section 4.7. When a mechanism is evaluated, one of three things can happen: it can match, not match, or throw an exception.

If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing continues with the next mechanism. If it throws an exception, mechanism processing ends and the exception value is returned.

Dus bij:

v=spf1 ip4:[IP-ADRES]/32 include:aspmx.googlemail.com [b]~all[/b] redirect=_spf.hostcontrol.com

de ~all hier (dus niet van een include) matcht, dus dan wordt er niet verder gekeken wat er daarna nog meer komt. De redirect wordt dan dus niet geevalueerd. Toch?
Vaak zie je dan ook wanneer men een redirect gebruikt, dat je geen all meer tegenkomt (want die zit dan als het goed is in je redirect).

[ Voor 5% gewijzigd door Qwerty-273 op 09-11-2016 12:39 ]

[CyBeR]

Nee, redirect is geen mechanism. Zie ook afwijkende syntax. Redirect vervangt het huidige record, inclusief een All.

[Qwerty-273]

Uit de zelfde RFC:

6.1. redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is present, then processing proceeds....

Vaak worden redirects inderdaad omschreven dat het het huidige record vervangt (ook op http://www.openspf.org/SPF_Record_Syntax#redirect ) maar dat is niet volgens de RFC. Aangezien de ~all die voor de redirect komt (in het voorbeeld) en die matcht, dan wordt nooit de redirect geevalueerd.

In de meeste voorbeelden met een redirect zie je die namelijk als enige in het spf record terugkomen. Maar ik ken bedrijven die tig domeinen hebben (voor marketing / andere productgroepen) waarbij er 1 spf record het "hoofd" record is en de rest redirect daar naar toe. Maar met een aantal marketing domeinen waar ze 3rd party mail service providers gebruiken is het spf voor dat domein vaak een:

v=spf1 include:3rdparty.mail.com redirect=hoofrecord.com

Ook stukje 5.2 over de include in dezelfde RFC is interessant, de ~all of -all uit een include wordt wel geevalueerd (dus niet genegeerd) maar een Fail, Softfail, of Neutral uitkomst van een include betekend dat de include niet matcht. En de processing dus gewoon doorloopt in je SPF record.

[CyBeR]

Hm, je hebt gelijk. Ik had die eerste pagina erbij maar de rfc zegt idd dat de redirect modifier pas in zwang komt als alle eerdere mechanisms niet matchen. Dan zou "-all redirect=bla" dus idd niks met die redirect doen.

Sterker nog:

Any "redirect" modifier MUST be ignored if there is an "all" mechanism anywhere in the record.

Ook stukje 5.2 over de include in dezelfde RFC is interessant, de ~all of -all uit een include wordt wel geevalueerd (dus niet genegeerd) maar een Fail, Softfail, of Neutral uitkomst van een include betekend dat de include niet matcht.

Dat komt dus neer op het negeren van "all" mechanisms, behalve +all.

Overigens pas ik zelf ook redirect= toe als manier om alle spf in één domein te hebben.

[ Voor 7% gewijzigd door CyBeR op 09-11-2016 14:22 ]