Door Whacko: 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.
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...