VPN nosūtīts e-pasts: kur patiesībā aiziet atbilde

Jūs nosūtāt ziņu caur tuneli, atvienojaties, un atbilde pienāk nākamajā rītā. Nekas no tā neprasa veco VPN adresi, un nekas no tā nesabrūk. E-pasts nevirza atbildes uz adresi, no kuras ziņa tika nosūtīta; tas virza tās uz pastkasti. Trīs ceļi šeit tiek sablīvēti vienā jautājumā, un to atdalīšana atbild uz lielāko daļu satraukuma.

Trīs ceļi, ko cilvēki sablīvē vienā

Iesniegšana, piegāde un lasīšana ir trīs atsevišķi savienojumi, un tikai divi no tiem skar jūsu ierīci.

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN var ietekmēt pirmo un trešo, jo tie ir savienojumi, ko izveido jūsu ierīce. Tas nevar ietekmēt otro, jo šis ceļš iet starp diviem pasta serveriem, kurus jūs nekontrolējat. Atbilde nav pakete, kas atgriežas uz adresi, no kuras sūtījāt. Tā ir jauna ziņa, ko otras puses pasta pakalpojums piegādā jūsu pastkastes pakalpojumam.

Kad šos trīs turat atsevišķi, jautājums par to, vai atbilde jūs atradīs, pārstāj būt noslēpumains.

Reply-To lauks ir adrese, nevis maršruts

RFC 5322 definē Reply-To kā pastkasti vai pastkastes, uz kurām jāsūta atbildes. Bez tā parastā noklusējuma vērtība ir From pastkaste, ja vien atbildētājs neieraksta ko citu. Abi ir pasta adreses galvenē. Neviens no tiem nav norādījums atkārtoti atvērt tīkla savienojumu, kas iesniedza sākotnējo ziņu.

Tāpēc VPN izejas adrese nekad neparādās atbildes ceļā. Pat ja iesniegšanas serveris kaut kur ir reģistrējis šo izejas adresi, atbilde tiek adresēta pastkastei, un sūtošais serveris meklē domēna pasta apmainītāju, nevis jūsu veco ligzdu.

Ja atbilde aiziet kaut kur negaidīti, izlasiet Reply-To un paša sūtītāja klienta iestatījumus, pirms turat aizdomās tuneli.

Ko izsekošanas galvenes patiešām reģistrē

Katrs SMTP lēciens priekšā pievieno Received galveni, kas apraksta apstrādāto savienojumu, un augšējā ir pēdējais lēciens pirms piegādes. Tāpēc iesniegtā ziņa var saturēt tīkla detaļas, ko ir vērts pārskatīt, un šīs detaļas raksta serveri, nevis jūs. Ko tās satur, ir atkarīgs no pakalpojumu sniedzēja iesniegšanas arhitektūras un tā rīcības ar galvenēm.

Lasiet tās, nevis miniet, no saglabātas ziņas:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

Noderīga disciplīna ir noteikt, kurš uzticams pakalpojums pievienoja katru lauku. Patvaļīgs teksts agrāk galveņu blokā nav uzticams pierādījums, un produkta nosaukums nav mūžīgs solījums, ka jūsu mājas adrese vienmēr ir vai vienmēr nav.

Pasta lasīšana vēlāk ir jauns savienojums

Kad atverat atbildi, jūsu klients pieslēdzas jūsu pastkastes pakalpojumam pa to tīklu, kurā tagad atrodaties. Tas ir svaigs savienojums ar savu avota adresi, nevis vakardienas iesniegšanas ligzdas turpinājums. Tas seko tā tīkla pašreizējai politikai, kuru tajā brīdī izmantojat.

Attālinātais saturs ir vēl trešā lieta. Pasta klients, kas ielādē attālinātu attēlu vai seko saitei, veic atsevišķu pieprasījumu saskaņā ar saviem pašreizējiem iestatījumiem, un šajā pieprasījumā var būt jebkuri identifikatori, ko ziņa ir ieguldījusi. Tas nav SMTP atbilde, kas ierodas vecajā adresē, un tā uzskatīšana par tādu slēpj reālo iedarbību.

Izslēdziet attālināto saturu, ja vēlaties lasīt ziņu, nepaziņojot, ka esat to atvēris.

Kas jāpārbauda, pirms to saukt par noplūdi

Sāciet ar sākotnējās ziņas skatu un Reply-To lauku. Pēc tam nosakiet, kurš pakalpojums pievienoja Received ierakstus, kas jūs satrauc, un salīdziniet to ar pakalpojumu sniedzēja pašreizējo dokumentāciju, nevis ar vecu foruma atbildi.

Visbeidzot, atdaliet jautājumus: ko novēroja iesniegšanas serveris, ko pievienoja piegādes ķēde un ko pieprasīja jūsu klients, kad atvērāt ziņu?

Atbildēt uz šiem trim atsevišķi ir vairāk darba nekā pārbaudīt IP lapu, un tā ir vienīgā versija, kas dod secinājumu, ko varat aizstāvēt. Atbilde uz e-pasta adresi neatklāj jūsu mājas adresi, un tā neprasa, lai vecais tunelis paliktu atvērts.