
read receipts
دکمه Unsubscribe که ایمیل شما را به جای حذف میفروشد
در لیستهای مشکوک، کلیک کردن روی «unsubscribe» روشی است برای اطلاع یک غریبه به اینکه شما واقعیاید و ارزش فروختن دارید. دکمهای امنتر در جای پیدایی پنهان است.
اسپمرها بیش از هر چیز دوست دارند یک آدرس ایمیل تأیید شده داشته باشند، و ارزانترین راه برای تأیید آن، آویزان کردن پیوند unsubscribe و انتظار برای کلیک شما است. در لحظهای که این کار را انجام میدهید، تنها سؤالی را که آنها داشتند پاسخ دادهاید: آیا کسی در خانه است؟ یک آدرس مرده پاک میشود. یک آدرس زنده بستهبندی و فروخته میشود. Validity، یک شرکت دادههای ایمیل، مدتها است که قیمت رایج برای هزار آدرس تأیید شده را در بازار خاکستری در دولار پایین منفرد برآورد کرده است — سکهای برای هر کدام، اما سکههایی که تجمع مییابند وقتی صندوق ورودی شما اثبات زندگی شود.
اینجا بخشی است که هیچ کس به شما نمیگوید. دو چیز کاملاً متفاوت هستند که هر دو برچسب «unsubscribe» دارند، و رفتار یکسانی ندارند.
اول، پیوندی است که در متن ایمیل مخفی است. در یک خبرنامه مشروع، خوب کار میکند و باید از آن استفاده کنید. در یک انفجار اسپم، آن پیوند اغلب فقط یک پیکسل ردیابی است که لباس دکمه پوشیده است. این یک سرور را پینگ میکند که آدرس شما، باز شدن شما و گاهی اوقات IP شما را ثبت میکند، و به آرامی شما را تحت «درگیر» ثبت میکند. راهنمایی خود FTC در این باره صریح است: با فرستندههایی که نمیشناسید، کلیک کردن روی unsubscribe میتواند تأیید کند که آدرس شما فعال است، بنابراین حرکت امنتر این است که آن را به جای درخواست مودبانه برای حذف به عنوان اسپم علامتگذاری کنید.
دومی بهتر است، و برنامه ایمیل شما قبلاً آن را نمایش میدهد. به آن List-Unsubscribe header میگویند — یک قطعه لولهکشی که فرستنده به خود پیام الحاق میکند، نه پیوندی که آنها در متن نقاشی میکنند. برنامه شما آن را میخواند و دکمه native «Unsubscribe» خود را ارائه میدهد، معمولاً در کنار نام فرستنده در بالا.
این تمایز اهمیت دارد زیرا اکنون کسی است که آن را اجرا میکند. از فوریه 2024، Gmail و Yahoo نیاز دارند که فرستندههای انبوه — هر کسی که بیش از 5,000 پیام در روز به کاربران خود ارسال میکند — از یک کلیک unsubscribe تحت RFC 8058 حمایت کنند، مشخصاتی که List-Unsubscribe-Post را تعریف میکند. Apple Mail از سرصحت یکسان تکریم میکند. بنابراین وقتی روی درخواست unsubscribe که برنامه شما نمایش میدهد ضربه میزنید، URL ردیابی فرستنده را بارگذاری نمیکنید. ارائهدهنده شما درخواستی استاندارد شده را از طرف شما شلیک میکند، و یک فرستنده سازگار باید در مدت دو روز آن را تکریم کند. فرستندههای سایهای که در درخواست سوءاستفاده میکنند؟ آنها اغلب هرگز ندادند که header را اجرا کنند، که در حد خود یک نشانه مفید است.
بنابراین قانون انگشت خود را مینویسد:
- اگر برنامه شما دکمه Unsubscribe را در بالا نشان میدهد (در کنار فرستنده، نه در متن پیام)، از آن استفاده کنید. این header است. محفوظ.
- اگر تنها گزینه unsubscribe پیوندی در داخل ایمیل است، و فرستنده را به وضوح نمیشناسید، روی آن کلیک نکنید. به جای آن «Report Spam» را بزنید. این شما را حذف میکند و فیلتر را تعلیم میدهد، بدون اینکه تأیید کنید که شما وجود دارید.
- اگر فرستنده را میشناسید — یک فروشگاه که از آن خریدید، یک خبرنامه که برای آن ثبتنام کردید — پیوند متن خوب است.
حقیقت ناراحتکننده این است که بدترین فرستندهها «unsubscribe» را طوری مهندسی کردند که به نظر یک مودبت رسد در حالی که در واقع یک نظرسنجی است. آنها یک سؤال میپرسند، و کلیک شما پاسخ شما است. header کل بازی را دور میزند: شما با ارائهدهنده ایمیل خود صحبت میکنید، که هر انگیزهای برای خوشحال کردن شما دارد، به جای یک دلال لیست که قبلاً تصمیم گرفته است ارزش توجه شما چیست.
دفعه بعد که چیزی کثیف فرود بیاید، قبل از اینکه پایین را ببینید بالا را ببینید. خروج واقعی معمولاً در بالای پیام است، نه پایین.
منابع
- IETF — RFC 8058 List-Unsubscribe-Post one-click spec
- FTC — Guidance on unsubscribing vs. reporting spam
- Google Postmaster — Bulk sender requirements incl. one-click unsubscribe (Feb 2024)
- Apple — Mail's native unsubscribe behavior