پسوند cid که شبیه شناسهٔ VPN است فقط یک Content-ID از MIME است

شما openvpn را داخل یک شناسهٔ میان‌قلاب در سرصفحهٔ ایمیل می‌بینید و نتیجهٔ بدیهی این است که پیام به نشست VPN مربوط است. پیش از پذیرفتن آن، تمام سطر را بخوانید: رشته درون یک Content-ID قرار دارد و Content-ID نام یک بخش بدنه در یک پیام است. ارجاع cid: در HTML به همان نام اشاره می‌کند و این جفت وجود دارد تا ایمیل بتواند تصویری را بدون ارسال دوباره حمل کند. هیچ‌چیز در این چیدمان به سرور VPN نمی‌رسد و هیچ‌چیز در پسوند نمی‌گوید چه کسی شناسه را ساخته است.

شناسه در واقع به چه چیزی اشاره می‌کند

ایمیل HTML به‌ندرت یکجا می‌رسد. متن و هر تصویر جاسازی‌شده معمولاً به‌صورت بخش‌های جداگانهٔ MIME سفر می‌کنند و کارخواه آن‌ها را برای نمایش دوباره کنار هم می‌گذارد. برای این کار به نامی برای بخش تصویر و ارجاعی نیاز دارد که به همان نام برسد.

جفت زیر برای نمونه‌سازی ساخته شده است.

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

سطر سرصفحه روی بخش تصویر است؛ عنصر img در بخش HTML است. قلاب‌ها به نحو سرصفحه تعلق دارند، پس ارجاع cid: معمولاً شناسه را بدون آن‌ها می‌نویسد. مقادیری که نویسه‌های نیازمند گریز دارند باید کدگذاری شوند و به همین دلیل این جفت یک نمونه است، نه قاعدهٔ تبدیل. آنچه معنا را حمل می‌کند تطابق دو رشته است، نه هیچ‌کدام به‌تنهایی.

پسوند @openvpn جزئیات ساخت است

Content-ID طوری ساخته می‌شود که در یک پیام یکتا باشد و نرم‌افزار ایمیل اغلب با افزودن @ و یک دامنه آن را شبیه نشانی می‌کند. این شکل قرارداد تولیدکننده است، نه مسیر: هیچ‌چیز در سرصفحه از کارخواه نمی‌خواهد با mailer.example تماس بگیرد و هنگام نمایش پیام هیچ جست‌وجویی رخ نمی‌دهد. این فیلد همچنین نام حساب، کاربر VPN یا نشانی نیست که کارخواه VPN گذاشته باشد. هر که پیام را سرهم کرده، رشته را هنگام نام‌گذاری یک بخش انتخاب کرده است.

RFC 2392 طرح cid را تعریف می‌کند و آن را به ارجاع به پیام‌ها و بخش‌هایشان محدود می‌کند. آن دامنه را تحت‌اللفظی بخوانید و پسوند دیگر مدرک چیزی فراتر از نام‌گذاری نخواهد بود. این همچنین یعنی تولیدکننده از پسوند قابل شناسایی نیست و مردم دقیقاً همین جهش را می‌کنند وقتی واژه‌ای آشنا در سرصفحه پیدا می‌شود.

منبع خام را بررسی کنید، سپس دربارهٔ مسئلهٔ حریم خصوصی داوری کنید

منبع خام را باز کنید و کل مقدار Content-ID را بخوانید، چون RFC 2392 اجازه می‌دهد مقدار نام میزبان پدیدآورنده یا رشته‌ای شبیه نام حساب را حمل کند. سپس هر جایی را که همان نام ظاهر می‌شود بیابید: ارجاع cid: در HTML، سرصفحه‌ای دیگر، بلوکی نقل‌شده از پاسخی پیشین. تطابق میان این ظهورهاست که هدف بخش را به شما می‌گوید.

همین ویژگی است که یک شناسه می‌تواند برای حریم خصوصی مهم باشد. مقداری که از نام میزبان یا نام حساب مشتق شده با پیام سفر می‌کند و می‌تواند چیزی دربارهٔ دستگاه یا شخص فرستنده آشکار کند. با این حال نشست VPN نیست و برخورد کردن با آن به‌عنوان نشست، یافته را هدر می‌دهد.

تصویر دوردست یا بخش جاسازی‌شده: ترافیک متفاوت

عنصر img با منبع https و عنصر img با منبع cid در HTML یکسان به نظر می‌رسند و در شبکه متفاوت رفتار می‌کنند. اولی منبعی را نام می‌برد که کارخواه پس از باز شدن پیام می‌تواند بگیرد و آن دریافت به فرستنده می‌گوید پیام خوانده شده و از کدام نشانی. دومی در برابر بخشی که از پیش درون پیام است حل می‌شود، پس نمایش آن با کسی تماس نمی‌گیرد.

یک پیام می‌تواند هر دو را بیامیزد و بررسی یکی دیگری را پاک نمی‌کند. ارجاع‌های دوردست را جدا از جاسازی‌شده‌ها بشمارید و بنویسید تنظیمات کارخواه چه چیزی را مجاز می‌کند. همین تفکیک تصمیمی است که برای حریم خصوصی مهم است، نه واژهٔ درون شناسه.

مدرک را بدون فرستادن پیام به اشتراک بگذارید

وقتی کس دیگری باید این را ببیند، نخست پاک‌سازی کنید و یکدست پاک‌سازی کنید. نشانی‌ها و سرصفحه‌های نامرتبط را جایگزین کنید، سپس Content-ID و ارجاع cid: آن را در رونوشت یکسان نگه دارید، چون ناهمخوانی تنها مدرک مهم را نابود می‌کند. بگویید سرصفحه به کدام بخش تعلق داشت و کدام سطر به آن ارجاع می‌داد. بازبین به رابطه نیاز دارد، نه به پیام.

سپس دو نتیجه را مکتوب از هم جدا کنید: پیام چه دارد و چه چیزی را اثبات نمی‌کند. ادعایی که این‌گونه چارچوب‌بندی شود قابل بررسی و بحث است و یک گزارش سودمند همین را ممکن می‌کند.