د VPN له لارې لېږل شوې برېښنالیک: ځواب واقعاً چېرته ځي
ځواب د برېښنالیک صندوق ته ادرس کېږي، نه هغې VPN پتې ته چې تاسو ترې لېږلي. سپارل، رسول او هغه وروسته اړیکه چې ځواب لولي، بېل کړئ.
تاسو د تونل له لارې پیغام لېږئ، اړیکه پرې کوئ، او ځواب بله سهار راځي. په دې کې هیڅ شی زړې VPN پتې ته اړتیا نلري او هیڅ شی نه ماتېږي. برېښنالیک ځوابونه هغې پتې ته نه استوي چې پیغام ترې لېږل شوی و؛ هغه یې برېښنالیک صندوق ته استوي. دلته درې لارې یوې پوښتنې ته یوځای کېږي، او د هغوی بېلول د اندېښنې ډېره برخه ځوابوي.
درې لارې چې خلک یوې ته یوځای کوي
سپارل، رسول او لوستل درې جلا اړیکې دي، او یوازې دوه یې ستاسو وسیله شامله کوي.
Submission: your mail app -> your mail service
Delivery: other mail service -> your mailbox service
Reading: your app now -> your mailbox serviceVPN کولای شي پر لومړي او درېیم اغېز وکړي، ځکه چې دا هغه اړیکې دي چې ستاسو وسیله جوړوي. پر دویم نشي اغېز کولای، ځکه چې هغه لار د دوو برېښنالیک سرورونو ترمنځ تېرېږي چې تاسو یې نه کنټرولوئ. ځواب هغه پیکټ نه دی چې هغې پتې ته بېرته راځي چې تاسو ترې لېږلي و. دا یو نوی پیغام دی چې د بل اړخ برېښنالیک خدمت ستاسو د برېښنالیک صندوق خدمت ته رسوي.
کله چې دا درې بېل وساتئ، دا پوښتنه چې ځواب به تاسو ومومي که نه، نوره نه ده پټه.
Reply-To ساحه یوه پته ده، لار نه ده
RFC 5322 Reply-To هغه برېښنالیک صندوق یا صندوقونه تعریفوي چې ځوابونه باید ورته ولېږل شي. پرته له دې، معمول ډیفالټ From صندوق دی، پرته لدې چې ځواب ورکوونکی بل څه ولیکي. دواړه په سرلیک کې ناستې برېښنالیک پتې دي. هیڅ یوه هم د هغې شبکې اړیکې بیا پرانیستلو حکم نه دی چې اصلي پیغام یې سپارلی و.
له همدې امله د VPN وتلو پته هېڅکله د ځواب په لار کې نه ښکاري. حتی کله چې سپارلو سرور هغه وتلو پته چېرته ثبت کړې وي، ځواب برېښنالیک صندوق ته ادرس کېږي، او لېږونکی سرور ستاسو د زړې ساکټ پرځای د ډومین برېښنالیک تبادله کوونکی پلټي.
که ځواب چېرته ناڅاپي ولاړ، د تونل له شک کولو مخکې Reply-To او د لېږونکي خپل کلینټ تنظیمات ولولئ.
د تعقیب سرلیکونه واقعاً څه ثبتوي
هر SMTP پړاو مخکې د Received سرلیک ورزیاتوي چې هغه اړیکه بیانوي چې هغه یې سمبال کړې، او ترټولو پورته یې د رسولو دمخه وروستی پړاو دی. نو ځکه سپارل شوی پیغام کولای شي د کتنې وړ شبکې توضیحات ولري، او هغه توضیحات سرورونه لیکي، تاسو نه غوره کوئ. چې څه ولري، د خدمت چمتو کوونکي د سپارلو معماری او د سرلیکونو د چلند پورې اړه لري.
د اټکل کولو پرځای یې له خوندي شوي پیغام څخه ولولئ:
grep -E '^(Received|Return-Path|Reply-To|From):' message.emlګټوره نظم دا دی چې وپېژنئ کوم باوري خدمت هر ساحه ورزیاته کړه. د سرلیکونو په بلاک کې مخکې هر ډول خپل سري متن باوري شاهد نه دی، او د محصول نوم دا تلپاتې ژمنه نه ده چې ستاسو کور پته تل موجوده ده یا تل نه ده.
وروسته برېښنالیک لوستل یوه نوې اړیکه ده
کله چې ځواب پرانیزئ، ستاسو کلینټ اوس چې په کومه شبکه کې یاست، د هغې له لارې ستاسو د برېښنالیک صندوق خدمت سره نښلوي. دا د خپلې سرچینې پتې سره نوې اړیکه ده، د پرون د سپارلو ساکټ دوام نه دی. هغه د هغې شبکې اوسنی سیاست تعقیبوي چې په هغه شیبه کې یې کاروئ.
لرې منځپانګه بیا درېیمه څیز دی. هغه برېښنالیک کلینټ چې لرې انځور باروي یا لینک تعقیبوي، د خپلو اوسنیو تنظیماتو له مخې جلا غوښتنه کوي، او هغه غوښتنه کولای شي هر هغه پېژندونکی ولېږدوي چې پیغام کې ځای پرځای شوی وي. دا هغه SMTP ځواب نه دی چې زړې پتې ته رسېږي، او داسې ګڼل یې ریښتینی خطر پټوي.
که غواړئ پیغام پرته لدې چې اعلان کړئ پرانیستی یې دی ولولئ، لرې منځپانګه بنده کړئ.
د دې له تویېدنې بللو مخکې څه وګورئ
د اصلي پیغام نندارې او Reply-To ساحې څخه پیل وکړئ. بیا وپېژنئ کوم خدمت هغه Received ننوتنې ورزیاتې کړې چې تاسو اندېښمن کوي، او دا د زړې فورمې ځواب پرځای د خدمت چمتو کوونکي اوسنیو اسنادو سره پرتله کړئ.
په پای کې، پوښتنې بېلې کړئ: د سپارلو سرور څه ولیدل، د رسولو زنځیر څه ورزیات کړل، او کله چې پیغام پرانیستل ستاسو کلینټ څه وغوښتل؟
دې درېیو ته جلا جواب ورکول د IP پاڼې کتلو څخه ډېر کار دی، او یوازینی نسخه همدا ده چې د دفاع وړ نتیجه ورکوي. برېښنالیک پتې ته ځواب ورکول ستاسو کور پته نه ښکاره کوي، او اړتیا نه لري چې زوړ تونل پرانیستی پاتې شي.