E-pos gestuur deur ’n VPN: waar die antwoord werklik heen gaan
’n Antwoord word aan ’n posbus geadresseer, nie aan die VPN-adres waarvan jy gestuur het nie. Skei indiening, aflewering en die latere verbinding wat die antwoord lees.
Jy stuur ’n boodskap deur die tonnel, maak los, en die antwoord kom die volgende oggend aan. Niks daarvan het die ou VPN-adres nodig nie, en niks daarvan breek nie. E-pos lei nie antwoorde na die adres waarvan ’n boodskap gestuur is nie; dit lei hulle na ’n posbus. Drie roetes word hier in een vraag saamgevat, en om hulle te skei beantwoord die meeste van die bekommernis.
Drie roetes wat mense in een saamvat
Indiening, aflewering en lees is drie afsonderlike verbindings, en net twee daarvan betrek jou toestel.
Submission: your mail app -> your mail service
Delivery: other mail service -> your mailbox service
Reading: your app now -> your mailbox serviceDie VPN kan die eerste en die derde beïnvloed, want dit is verbindings wat jou toestel maak. Dit kan nie die tweede beïnvloed nie, want daardie roete loop tussen twee e-posbedieners wat jy nie beheer nie. ’n Antwoord is nie ’n pakkie wat na die adres terugkeer waarvan jy gestuur het nie. Dit is ’n nuwe boodskap wat die ander kant se e-posdiens by jou posbusdiens aflewer.
Sodra jy daardie drie uitmekaar hou, hou die vraag of die antwoord jou vind op om geheimsinnig te wees.
’n Reply-To-veld is ’n adres, nie ’n roete nie
RFC 5322 definieer Reply-To as die posbus of posbusse waarheen antwoorde gestuur moet word. Sonder dit is die gewone verstek die From-posbus, tensy die persoon wat antwoord iets anders tik. Albei is e-posadresse in ’n kop. Nie een is ’n opdrag om die netwerkverbinding wat die oorspronklike boodskap ingedien het, weer oop te maak nie.
Dit is waarom ’n VPN-uitgangadres nooit in die antwoordroete verskyn nie. Selfs wanneer die indieningsbediener daardie uitgangadres iewers aangeteken het, word die antwoord aan ’n posbus geadresseer, en die sturende bediener soek die domein se e-posuitruiler op eerder as jou ou sok.
As ’n antwoord êrens onverwags heen gaan, lees Reply-To en die sender se eie kliëntinstellings voordat jy die tonnel verdink.
Wat die spoor-opskrifte werklik aanteken
Elke SMTP-hop voeg ’n Received-opskrif by wat die verbinding beskryf wat dit hanteer het, en die boonste een is die laaste hop voor aflewering. ’n Ingediende boodskap kan dus netwerkbesonderhede dra wat die moeite werd is om na te gaan, en daardie besonderhede word deur bedieners geskryf eerder as deur jou gekies. Wat hulle bevat, hang af van die verskaffer se indieningsargitektuur en die hantering van opskrifte.
Lees hulle eerder as om te raai, uit ’n gestoorde boodskap:
grep -E '^(Received|Return-Path|Reply-To|From):' message.emlDie nuttige dissipline is om te bepaal watter vertroude diens elke veld bygevoeg het. Willekeurige teks vroeër in die opskrifblok is nie betroubare bewyse nie, en ’n produknaam is nie ’n permanente belofte dat jou huisadres altyd daar is of altyd afwesig is nie.
Om later e-pos te lees is ’n nuwe verbinding
Wanneer jy die antwoord oopmaak, verbind jou kliënt met jou posbusdiens oor watter netwerk jy nou ook al gebruik. Dit is ’n vars verbinding met sy eie bronadres, nie ’n voortsetting van gister se indieningsok nie. Dit volg die huidige beleid van die netwerk wat jy op daardie oomblik gebruik.
Afgeleë inhoud is weer ’n derde ding. ’n E-poskliënt wat ’n afgeleë prent laai of ’n skakel volg, maak ’n aparte versoek onder sy huidige instellings, en daardie versoek kan enige identifiseerders dra wat die boodskap ingebed het. Dit is nie die SMTP-antwoord wat by ’n ou adres aankom nie, en om dit so te behandel verberg die werklike blootstelling.
Skakel afgeleë inhoud af as jy ’n boodskap wil lees sonder om aan te kondig dat jy dit oopgemaak het.
Wat om na te gaan voordat jy dit ’n lek noem
Begin met die aansig van die oorspronklike boodskap en die Reply-To-veld. Bepaal dan watter diens die Received-inskrywings bygevoeg het wat jou pla, en vergelyk dit met die verskaffer se huidige dokumentasie eerder as met ’n ou forumantwoord.
Skei laastens die vrae: wat het die indieningsbediener waargeneem, wat het die afleweringsketting bygevoeg, en wat het jou kliënt aangevra toe jy die boodskap oopgemaak het?
Om daardie drie afsonderlik te beantwoord is meer werk as om ’n IP-bladsy na te gaan, en dit is die enigste weergawe wat ’n gevolgtrekking lewer wat jy kan verdedig. Om op ’n e-posadres te antwoord, verklap nie jou huisadres nie, en dit vereis nie dat die ou tonnel bly staan nie.