Op de oude mailserver moet SPF ingericht zijn. De nieuwe mailserver weet dan dat de doorgestuurde e-mails echt van de oude server afkomstig zijn.

Hoe de nieuwe mailserver ermee omgaat hangt af van de configuratie van de nieuwe server. De server kan de mail weggooien, van een label voorzien en in de spam-folder zetten, of afleveren alsof er niets aan de hand is.

Je kunt hier weinig van zeggen met deze informatie.

Een exchange server bijvoorbeeld, stuurt de mail door alsof de mail van zijn eigen server wordt gestuurd door de originele verzender. Maar iedere server kan dit anders doen. Een plesk server doet dit weer anders dan een exchange server.
Maar het is in een geval van een exchange server dan niet afhankelijk van spf records die jij kan instellen, maar het is afhankelijk van de spf records van diegene die aan jou een email verzenden.

Een voorbeeld

Ik stel op de server van Pietje (serverPietje) in dat een mailtje gestuurd aan pietje@test.nl wordt geforward naar pietje@hotmail.com

Als jantje@beton.nl nu een mailtje stuur naar pietje@test.nl wordt deze doorgestuurd via serverPietje naar pietje@hotmail.com
Als de spamfilter van Hotmail.com dan op spf controleert (niet alle mailfilters controleren daar helaas op) ziet hij dat serverPietje niet in het spf record staat van beton.nl En dan komt het mailtje niet aan.

SPF is bedoeld als hulpmiddel voor de ontvanger. Het hangt dus van de ontvanger af of en hoe deze met aanwezigheid of een gebrek aan SPF om gaat. Omdat hier niemand kan zien wat het beleid van de ontvanger is valt er ook geen eenduidig antwoord te geven wat er zal gebeuren.

Uhhhh SPF richt je niet enkel in op een mailserver, SPF is oa. een text record in de DNS van het betreffende Domein.

De ontvangende servers (die van xs4all in dit geval) controleren of de binnen komende mail van dat domein beperkt is tot in het SPF record genoemde mail servers.

Verder kunnen we de vraag van OP niet beantwoorden omdat hij/zij niet meld hoe er wordt geforward, dat kan nl. op meerdere methoden.

Forwarding kan alleen als de server die het doorstuurt ARC ondersteund.
Vaak is het beter bij de nieuwe provider het oude adres middels POP3 over SSL leeg te lepelen. Meeste providers zoals gmail etc ondersteunen dat ook.

Om dit soort risico's te voorkomen heb een tijd geleden mijn forwards gewist en haal ze nu op via POP. Dan heb ik ze ook op mijn plek.

ONZIN.

Forward servers dienen gebruik te maken van SRS

Ik (TS) heb wat headers verzameld uit verschillende mailtjes in de webmail van xs4all. Deze leken mij relevant:


Sommige mailtjes hebben ook niet de Authentication-Results header. Vooral mailing lijsten lijkt het. Alle mailtjes in mijn inbox hebben de X-Authentication-Warning header.

Niet helemaal on-topic, sorry daarvoor.

Wat is het nut van een '?all' in het SPF-record? De ontvanger valideert, matcht niet met de bedoelde afzender, maar hij gaat toch gewoon door. Doet het dan onder SPF (in tegenstelling tot ~all, waarbij er tenminste een 'mark' gebeurt).

Voor zover ik weet heeft SPF helemaal niks te maken met FORWARDEN van mails.een geforwarde mail komt dus van het adres dat het forward, niet van de originele afzender. En zal dus altijd gewoon goed gaan en niet in je spam belanden. Want dan heeft het gewoon te maken met de SPF van de originele afzender.

Dat ligt helemaal aan het systeem wat iets forward. Sommige programma's laten de originele afzender staan. Ik ben ook wel eens geforwarde mail kwijt geraakt omdat de afzender een hard-fail ingesteld had.


Dat is volgens mij iets heel nieuws dat pas dit jaar geïntroduceerd is. (http://arc-spec.org) Dit protocol moet de problemen oplossen die DMARC geeft met mailing lists. Ik verwacht niet dat dit al algemeen ondersteunt wordt.

Dit is een oud fenomeen;

Zodra er een hardfail staat en de ontvangende mailserver accepteert deze; dan gaat het linea recta /dev/null in.
Tenzij je elk mogelijke domein wat kan forwarden gaat opnemen in SPF; is dit een onmogelijkheid waar je tegen aan gaat lopen.

http://www.openspf.org/SRS kan natuurlijk, maar dan herschrijf je het verzend e-mailadres.
Bij ARC https://blog.returnpath.com/how-to-explain-authenticated-received-chain-arc-in-plain-english-2/ (kijk maar eens in je gmail headers, daar staan ze als ARC-Seal en ARC-Message-Signature en ARC-Authentication-Results) hoeft dat niet, maar lost het probleem zich op een andere manier op, door de SPF validatie terug te verplaatsen naar alleen de eerste schakel. De tweede schakel vertrouwd dan de het ARC-bewijs.

(Mocht ik ernaast zitten (tja, blijf mens), geef even aan hoe het dan wel werkt).

Het probleem zit hem vooral in het automatisch laten doorsturen van e-mail (denk bijv. aan een promovendus, die na promotie een "postdoc" baan bij een andere universiteit krijgt, wiens eerste universiteits-e-mail adres bekend is bij veel vakgenoten, die later vragen kunnen hebben over onderzoekspublicaties; het account vervalt na vertrek maar inkomemde mail wordt nog een tijd doorgestuurd). Als je handmatig op doorsturen drukt heb je zelden last van SPF (want de meeste clients vervangen de oorspronkelijke envelop-afzender en de body-afzender door degene die op "doorsturen" drukt).

Gegeven iemand met een e-mail account y@mailsrv2 die haar mail automatisch laat doorsturen naar z@mailsrv3, en iemand met account x@mailsrv1 die haar een mail stuurt, gebeurt het volgende:

[Mailsrv1] -- Return path en From: x@mailsrv1 --> [Mailsrv2] -- Return path en From: x@mailsrv1 --> [Mailsrv3]

Het "Return path", ook "Envelope from" genoemd, is waar de e-mail naartoe terug moet als deze niet op het bedoelde adres kan worden afgeleverd. SPF werkt op basis van het domein in dit adres.

Als Mailsrv2 SPF checks doet, zal deze, tijdens ontvangst van de mail, via DNS navragen of er voor Mailsrv1 een SPF record is gepubliceerd en zo ja, of het IP-adres van Mailsrv1 gebruikt mag worden on namens die domeinnaam mails te versturen. Dat is natuurlijk zo, dus de mail wordt niet geweigerd.

Na volledige ontvangst van de mail zal Mailsrv2 deze mail zo snel als mogelijk proberen door te sturen naar Mailsrv3. De klassieke manier is om daarbij het Return-path niet te wijzigen. Immers, als Mailsrv3 de mail niet kwijt kan (bijv. vanwege een volle mailbox of een verwijderd account), dan kan Mailsrv3 dat direct aan Mailsrv1 terugmelden (waarom zou Mailsrv2 daar weer tussen gaan zitten).

Als Mailsrv3 SPF checks doet, zal ook deze via DNS navragen of er voor Mailsrv1 een SPF record is gepubliceerd en zo ja, of het IP-adres van Mailsrv2 gebruikt mag worden om namens die domeinnaam mails te versturen. Dat is natuurlijk niet zo, met als gevolg dat Mailsrv3 de mail niet zal aannemen.

SRS (Sender Rewriting Scheme, zie http://www.openspf.org/SRS) tracht dit probleem te verhelpen en moet door de forwardende mailserver (Mailsrv2) worden geïmplementeerd. Effectief wordt er voor elke doorgestuurde mail een tijdelijk account @Mailsrv2 aangemaakt, dat als "Envelope-From" wordt gebruikt in de doorgestuurde mail (het "Body-from" veld wordt niet gewijzigd). Als er voor Mailsrv2 ook een SPF record in DNS is gepubliceerd, zal dat record door Mailsrv3 worden gecheckt (en dat zal natuurlijk wel kloppen).

De tweede helft van bovenstaand "plaatje" ziet er dan uit als volgt:

[Mailsrv2] -- Return path: 4dgyrkx36t7r@mailsrv2; From: x@mailsrv1 --> [Mailsrv3]

Nb. om SRS te laten werken, moet een ontvangende mailserver wel accepteren dat "Envelope-from" van geen kanten lijkt op "Body-from". Dit is dus ook een veld dat niet meegenomen moet worden in een DKIM signature, want die zou dan niet meer kloppen.

Omdat het enige tijd kan duren voordat wordt ontdekt dat een mail niet kan worden afgeleverd, is het de vraag hoe lang dat "tijdelijke account" moet blijven bestaan. Dit is best wel "gedoe", mailserverbeheerders houden niet van allerlei queues die kunnen vollopen (bij voorkeur is een mailserver zo "stateless" mogelijk).

Nu lees ik hierboven dat er opnieuw een protocol is bedacht ("ARC") dat belooft al uw problemen op te lossen. Ik weet niet hoe het met u zit, maar ik begin een beetje e-mail-protocol-moe te worden...

@Bitwiper, SRS klinkt zeer werkzaam, maar dan moet het wel toegepast worden. Ik lees dat het al in 2003 bedacht is zodat je verwacht dat dit toch wel breed ingevoerd is. Bij je mail provider vind je dit soort informatie zelden.

Als test heb ik eens een mailtje van een iCloud account via een Ziggo.nl account naar mijn account geforward. In de header zie ik dan:


Mijn server ziet nog steeds iCloud als de originele afzender in de 'mfrom'. Ziggo past dus geen SRS toe terwijl dat toch een grotere mail verwerker is in Nederland.

DMARC gaat overigens wel goed omdat daar SPF mag falen, mits DKIM geldig is.

Resumerend: als je uiteindelijke ontvanger SPF controleert en de resultaten logt in de header, kun je daar aan de afzender in het Received-Spf veld zien of je kunt forwarden zonder bang te zijn of een hard fail zal bouncen. (Of in de spammap beland)

Hier TS. Een aanvulling op mijn post van 11:20:

Het interessants is natuurlijk, als ik mail van het oude geforwarde adres naar datzelfde adres stuur via de webmail van xs4all. Dan krijg ik (zoals altijd) de X-Authentication-Warning header, met mijn oude e-mail adres. Maar de header Authentication-Results ontbreekt volledig.

Als ik met Thunderbird een e-mail vanaf een andere xs4all mailbox van mij naar het oude geforwarde adres stuur, dan is dit hetzelfde, maar heeft de X-Authentication-Warning header het e-mail adres van dit andere Thunderbird account.


Nog een correctie op mijn post van 11:20: Waar ik Mailing Lijst schrijf, bedoelde ik Nieuwsbrief. Klein detail..


Ondertussen ben ik mij aan het verdiepen in RFC 7208 over SPF. Ik begrijp dat de verstuurder van een 'hardfail' bericht een 550 foutmelding krijgt. Dat is dan tenminste iets..

>. Ik begrijp dat de verstuurder van een 'hardfail' bericht een 550 foutmelding krijgt. Dat is dan tenminste iets..
Nee, de forwarder krijgt een hardfail terug, want deze is in dit geval de verzender.

Ik ga hier gewoon heel cynish zijn, maar als je mailservers van volume beheerd dan weetje wat praktisch is.
Weer iets wat de ontvanger moet checken en zeer weinig ontvangers gebruiken het.
DUS: de enige praktische oplossing is nog steeds SRS.

En waar moet de 550 foutmelding dan worden getoond? Niet bij de ontvanger van een hardfailed e-mail, want die krijgt helemaal geen bericht als de checking software akkoord gaat met de fail. Die ziet het gewoon als spam die /dev/null in gaat.

Dus de verzender van het bericht krijgt de 550 foutmelding via SMTP.
De verzender is bekend bij de checking software, want deze staat in de headers als het goed is.

Als je het precies wilt weten hoe het zit, zie https://tools.ietf.org/html/rfc7208#section-8.4

heb je het over een demon probleempje? hoorde dat ze dat erfgoed aan klanten ooit in hun maag gesplitst gekregen hebben in opdracht van kpn. en dat ze daar intern een grote hekel aan demon en alles wat ze daarvoor aan extra energie moeten besteden. oud demon klanten hebben overerfde rechten waar de provider niet zomaar vanaf kan, zeg maar net zoals het privacy dilemma dat ze van gongrijp hebben georven. men zit eraan vast, dus dat probleem wat je schetst van het wegvallen van diensten zal nog wel meevallen. een heel nieuw account aan laten maken kan ook en dan ben je ervan af. het voordeel kan dan ook zijn dat je dan eindelijk een nieuw modem ontvangt dat minimaal 10x sneller is dan het oude bbnet modem. want dat recht was voor die oude klanten dan weer niet automatisch na de overname, wel het abonnement en de jaarlijkse prijsverhoging maar in de verte dus ook niet de bijbehorende snelheden. waarom zou je iets nog in stand houden als je er geen voordeel meer van hebt? dan wordt het wel een erg dure provider. kijk en meet ook eens wat er tussen jou en de centrale gebeurt, want misschien zal je de geadverteerde snelheden zowiezo nooit halen en is een andere provider uiteindelijk wel een betere optie.

TS Hier,

Samenvattend:

Er is veel mogelijk, maar de enige manier om zeker te weten dat al mijn mail voor mijn oude e-mail adres aankomt, is door de forward uit te zetten en via de webmail of via POP3 mijn oude mail te lezen.

Ik ben niet zo gek van POP3, omdat ik nogal vreemde en verdachte mailtjes op dit oude adres krijg, dus dat wordt goed opletten als ik dit instel.

Ook is mijn oude webmail niet zo groot (de webmail van XS4All is 1,5 GB), dus dat wordt dan lezen en meteen weggooien (ook niet echt handig).

P.S. Ik vond deze draad zeer leerzaam! Zelfs voor een draad op security.nl.

Ik (TS) heb nog een (laatste?) update.

Ik haal nu de mail van mijn oude e-mail adres binnen met Thunderbird (met SSL/TLS!). De X-Authentication-Warning en Authentication-Results zijn verdwenen, maar ik vermoed dat de POP3 van mijn oude provider, die ik nu gebruik, daar niets mee doet.

Ik heb vanaf XS4All, Planet en Gmail mailtjes van en naar mijzelf gestuurd. En de twee bovengenoemde headers zijn dus verdwenen. Planet en Gmail hebben wel DKIM (XS4All niet). Ik verstuur mail vanaf mijn oude e-mail adres via de SMTP van XS4All, omdat het mij lastig lijkt twee SMTP servers tegelijk in Thunderbird te gebruiken. Bovendien laat mijn poortbeveilingsinstelling bij XS4All geen andere SMTP server toe!

Ik vond de forward bij mijn oude e-mail adres wel prettiger, omdat mijn mail dan maar heel erg kort op de servers van mijn oude provider staat (XS4All is toch altijd veiliger/beter). Maar dit is ook goed.

De SMTP van XS4All levert wel een X-CMAE-Envelope header op. (Misschien is er daarom geen DKIM header noodzakelijk?)

Met Thunderbird kun je juist losse SMTP servers toe voegen en per account instellen welke je voor dat account wilt gebruiken.

In zijn algemeenheid moet je echter de SMTP server van het account gebruiken. Beveiligingen als SPF zijn er juist voor bedoeld om vast te leggen welke SMTP server voor dat account gebruikt wordt. Stuur je het via een andere server, dan kan die mail als minder betrouwbaar aangemerkt worden of zelfs helemaal bouncen als de ontvanger erg strikt op spf failures reageert

De kans is groot dat jouw oude account geen spf ingesteld heeft en dan maakt die smtp server niets uit. Of jou account een spf policy heeft kun je snel met het "host" of "dig" command testen door daar het "TXT" record op te vragen. (Host geeft minder 'rotzooi' als antwoord, maar zit niet standaard op windows)

dus:

Vervang "xs4all.nl" natuurlijk voor het domein wat je wilt bekijken. Als deze terug komen ets dat met "v=spf1" begint, zou ik altijd de bijbehorende smpt server gebruiken.


Meestal zit die blokkade alleen op poort 25. Poort 465 of 587 moeten normaal wel open staan.

Je opmerkingen over SMTP kloppen. Waarschijnlijk werkt dat zonder al te veel moeite. Maar ik denk dat ik de gok waag dat, de SMTP van mijn oude provider, niet nodig is. Voor belangrijke dingen maak ik toch al gebruik van nieuwe adressen. Het oude adres is meer een placeholder voor oude accounts die ik niet meer gebruik of die ik vergeten ben. Of voor oude accounts die ik niet kan wissen en die niet naar een ander e-mail adres verhuist kunnen worden.

Onder Windows werkt wel:
Antwoord:

Dan kun je doen:
Atwoord:

In https://www.xs4all.nl/service/diensten/beveiliging-en-veiligheid/installeren/hoe-zet-ik-poortbeveiliging-aan.htm zie je dat als je niveau 2 kiest, je poort 25 van elke server op internet kunt communiceren. Als je een Fritz!Box hebt kun je dit met firewall rules desgewenst beperken tot vertrouwde servers (zo voorkom je, mocht een PC aan jouw netwerk geïnfecteerd raken, dat deze naar willekeurige mailservers kan gaan staan spammen en xs4all jou, na ontvangen klachten daarover, afsluit).

@Bitwiper, dat werkte perfect! (Zie ook https://blogs.technet.microsoft.com/rmilne/2015/09/11/how-to-use-nslookup-to-check-dns-txt-record/). Mijn oude provider is spf1, ~all. Dus dat is een softfail als ik hun smtp server niet gebruik voor het verzenden van e-mail met mijn oude adres.

Grappig dat XS4All zo anti-spf is :-)

Nog een vraag (van TS).

Hoe moet ik dit lezen? Bij de ene regel staat ~all, en bij de andere ?all. Een van de (SMTP) mailservers van XS4All is 194.109.24.21. Die matched dan met ip4:194.109.24.0/24, maar krijgt het bericht dan een 'neutral' (tweede regel) of krijgt het een 'softfail' (eerste regel). Dit is mij niet duidelijk uit de RFC.

Volgens https://tools.ietf.org/html/rfc7208#section-5.2 wordt, tijdens parsen van het eerste DNS record, recursief eerst alle include statements geëvalueerd. De tabel in pagina 22 beschrijft dat als het include statement zelf "neutral" oplevert (net als een softfail zou doen trouwens) dit als een "not match" moet worden geïnterpreteerd door de "aanroepende" regel. Het overall resultaat hoort op basis van de ~all (uit de eerste regel) te worden geïnterpreteerd.

Maar of alle ontvangende mailservers zich hieraan houden; is afwachten.

Duidelijk! Bedankt voor de uitleg.