پیش‌نویس:لیست مسدودی سیستم نام دامنه

"این مقاله در حال ترجمه از ویکی انگلیسی است.لطفا حذف نشود."

یک سیستم نام دامنه blocklist , فهرست blackhole مبتنی بر سیستم نام دامنه , فهرست سیاه سیستم نام دامنه ( DNSBL ) یا فهرست blackhole زمان واقعی ( RBL ) یک سرویس برای عملکرد سرورهای پست برای انجام یک چک از طریق سیستم نشانی دامنه است . بیشتر نرم‌افزارهای سرور پست می‌توانند برای بررسی این فهرست پیکربندی شوند , به طور معمول پیغام‌های چنین سایت‌هایی را رد یا ضعیف می‌کنند .

DNSBL یک مکانیزم نرم‌افزاری است نه یک لیست یا سیاست خاص . ده‌ها of وجود دارند . آن‌ها از طیف وسیعی از معیارها برای فهرست کردن و نشانی‌های delisting استفاده می‌کنند . این موارد ممکن است شامل فهرست نشانی کامپیوترهای زامبی یا ماشین‌های دیگر باشد که برای فرستادن اسپم , ارائه دهندگان خدمات اینترنتی ( isp ها) که با رغبت میزبان spammers هستند , یا آن‌هایی که اسپم را به سیستم honeypot ارسال کرده‌اند .

از زمان ایجاد اولین DNSBL در سال ۱۹۹۸ , عملیات و سیاست‌های این فهرست به کرات بحث‌برانگیز بوده‌است , هم در محافل حمایتی اینترنت و هم در دعاوی . بسیاری از کاربران و کاربران سیستم‌های ایمیل DNSBLs را ابزاری ارزشمند برای به اشتراک گذاشتن اطلاعات درباره منابع اسپم می‌دانند , اما برخی دیگر از جمله برخی فعالان برجسته اینترنتی به آن‌ها به عنوان نوعی سانسور اعتراض کرده‌اند . علاوه بر این , تعداد کمی از اپراتورهای DNSBL هدف پرونده‌های حقوقی مطرح‌شده توسط spammers هستند که به دنبال بسته شدن فهرست هستند .

تاریخچه ویرایش

یdelisting استفاده می‌کنند . این موارد ممکن است شامل فهرست نشانی کامپیوترهای زامبی یا ماشین‌های دیگر باشد که برای فرستادن اسپم , ارائه دهندگان خدمات اینترنتی ( isp ها) که با رغبت میزبان spammers هستند , یا آن‌هایی که اسپم را به سیستم honeypot ارسال کرده‌اند . فهرست e ( RBL ) یک سرویس برای عملیات سرورهای پست برای انجام یک چک از طریق یک پرس و جو سیستم نام دامنه ( dns ) است که آیا آدرس ip میزبان در لیست سیاه اسپم قرار دارد یا خیر . بیشتر نرم‌افزارهای سرور پست می‌توانند برای بررسی این فهرست پیکربندی شوند , به طور معمول پیغام‌های چنین سایت‌هایی را رد یا ضعیف می‌کنند .

عبارت " blackhole " به یک سیاهچاله شبکه‌ای اشاره دارد , عبارتی برای ارتباط بر روی شبکه‌ای که ترافیک ورودی را به جای ارسال آن به طور معمول کاهش می‌دهد . هدف of این بود که سایت‌هایی که از آن استفاده می‌کنند از ترافیک سایت‌هایی که از اسپم پشتیبانی می‌کنند - چه با ارسال فعالانه اسپم و چه به روش‌های دیگر امتناع کنند. قبل از اینکه آدرس در RBL لیست شود , داوطلبان و کارکنان نقشه‌ها به طور مکرر تلاش می‌کنند تا با افرادی که مسئول آن هستند تماس بگیرند و مشکلاتش را اصلاح کنند . چنین تلاشی قبل از سیاه شدن ترافیک شبکه بسیار مهم به نظر می‌رسید , اما همچنین به این معنی بود که spammers و spam پشتیبانی از isp ها می‌توانند به مدت طولانی به تاخیر انداخته شوند در حالی که چنین مذاکراتی ادامه داشت .

بعدها , RBL به شکل DNSBL آزاد شد و پل Vixie نویسندگان sendmail و دیگر نرم‌افزارهای پست را تشویق کرد تا پشتیبانی of را در مشتریان خود اجرا کنند . این امر به نرم‌افزار پست اجازه داد تا به جای سیاه کردن تمام ترافیک , پست از سایت‌های فهرست‌شده را براساس یک سرور در هر پست رد کند .

کمی پس از ظهور RBL , دیگران شروع به توسعه لیست‌های خود با سیاست‌های مختلف کردند . یکی از اولین آن‌ها سیستم اصلاح رفتار رله باز آلن براون بود . این تست خودکار برای شناسایی و فهرست کردن سرورهای پستی که به عنوان رله‌های باز ارسال می‌شوند , توسط spammers برای حمل اسپم آن‌ها استفاده می‌شود. در آن زمان , ORBS بحث‌برانگیز بودند زیرا بسیاری از مردم احساس می‌کردند که اجرای یک رله باز قابل‌قبول است و اسکن اینترنت برای سرورهای پست باز می‌تواند توهین‌آمیز باشد .

در سال ۲۰۰۳ , تعدادی از DNSBLs تحت حملات انکار سرویس ( dos ) قرار گرفتند . از آنجا که هیچ حزبی به این حملات اعتراف نکرده و کسی را مسئول نمی‌داند , هدف آن‌ها موضوع گمانه‌زنی است . با این حال , بسیاری از ناظران بر این باورند که این حملات توسط spammers صورت می‌گیرد تا در عملیات DNSBLs دخالت کند یا آن‌ها را به تعطیلی بکشاند . در آگوست ۲۰۰۳ , شرکت Osirusoft , یک اپراتور چندین DNSBLs شامل یک نفر براساس مجموعه داده‌های SPEWS , پس از هفته‌ها حمله نزدیک به پیوسته , فهرست‌های خود را تعطیل کرد.

مشخصات فنی برای نام DNSBLs در RFC5782 نسبتا ً دیر بود .

نشانی اینترنتی DNSBLs ویرایش

شناسه منبع یکنواخت ( نشانی اینترنتی ) DNSBL است که نام دامنه و گاهی آدرس‌های ip را فهرست می‌کند که در لینک‌های قابل کلیک موجود در بدنه of یافت می‌شوند , اما معمولا ً در پیام‌های مشروع یافت نمی‌شوند .

DNSBLs URI زمانی ایجاد شد که مشخص شد که بسیاری از spam آن را در طول این بازه زمانی کوتاه بین اولین استفاده از آدرس ip ارسال اسپم و نقطه‌ای که آدرس ip برای اولین بار بر مبنای ارسال ip اصلی فهرست شده‌است , از فیلترهای اسپم عبور می‌دهند.

در بسیاری از موارد , چنین spams فراری حاوی نام‌های دامنه لینک یا آدرس‌های ip ( که به طور جمعی به عنوان نشانی‌های اینترنتی نامیده می‌شوند ) هستند که در گذشته در اسپم کشف شده‌اند و نشانی اینترنتی در ایمیل غیر اسپم یافت نمی‌شود .

بنابراین , هنگامی که فیلتر اسپم تمام نشانی‌های اینترنتی را از یک پیام استخراج می‌کند و آن‌ها را بر ضد a نشانی اینترنتی چک می‌کند , حتی اگر ip ارسالی برای آن اسپم هنوز در هیچ DNSBL ip ارسال نشده باشد , اسپم می‌تواند مسدود شود .

از سه نشانی اصلی DNSBLs , قدیمی‌ترین و محبوب‌ترین آن‌ها SURBL است . پس از اینکه SURBL ایجاد شد , برخی از داوطلبان for دومین URI اصلی DNSBL , URIBL را آغاز کردند . در سال ۲۰۰۸ , یک داوطلب بلند مدت دیگر با نام اینترنتی another , ivmURI را آغاز کرد . پروژه Spamhaus فهرست بلوک دامنه Spamhaus ( DBL ) را فراهم می‌کند که آن‌ها به عنوان حوزه‌های " در پیام‌های اسپم " توصیف می‌کنند . DBL به عنوان یک URIBL و RHSBL در نظر گرفته می‌شود تا در هر دو حوزه در پوشش پیام و headers و دامنه‌ها در نشانی‌های اینترنتی در بدنه پیام بررسی شود . برخلاف دیگر URIBLs , DBL تنها نام‌های دامنه را لیست می‌کند , نه آدرس‌های ip , زیرا Spamhaus لیست‌های دیگر آدرس‌های ip را فراهم می‌کند .

DNSBLs URI اغلب با RHSBLs ( سمت راست BLs ) اشتباه می‌شوند . اما آن‌ها متفاوت هستند . نشانی اینترنتی نام دامنه و ip موجود در بدنه پیام را فهرست می‌کند. An نام دامنه مورد استفاده در آدرس " از " یا " پاسخ " به آدرس ایمیل را فهرست می‌کند. RHSBLs از اثربخشی قابل بحث هستند زیرا بسیاری از spams یا از نشانی‌های " نشانی یا استفاده " از آدرس‌های حاوی نام‌های دامنه freemail محبوب مانند @ gmail.com , @ yahoo.com , یا @ hotmail.com استفاده می‌کنند .

اصل ویرایش

برای کار با DNSBL به سه چیز نیاز است : یک دامنه برای میزبانی آن زیر , یک کارگزار نام برای آن دامنه , و فهرستی از آدرس‌ها برای انتشار .

این امکان وجود دارد که با استفاده از هر نرم‌افزار کارگزار dns به یک DNSBL خدمت کنید. با این حال , این مساله اغلب برای مناطقی که دارای تعداد زیادی آدرس هستند , به ویژه DNSBLs که فهرست کامل مسیریابی Classless درون دامنه هستند , ناکارآمد است . برای مصرف منابع بزرگ در هنگام استفاده از نرم‌افزار طراحی‌شده به عنوان یک سرور نام دامنه , برنامه‌های نرم‌افزاری خاص نقش ویژه برای سرورها با نقش فهرست سیاه dns طراحی شده‌اند .

بخش سخت کار کردن یک DNSBL آن را با آدرس پر می‌کند . DNSBLs که برای استفاده عمومی در نظر گرفته می‌شود معمولا ً سیاست‌های خاص , منتشر شده در مورد اینکه چه وسیله‌ای برای فهرست کردن وجود دارد و باید براساس آن عمل شود تا اعتماد عمومی به دست آید یا حفظ شود .

جستارهای DNSBL ویرایش

زمانی که یک سرور ایمیل یک اتصال از یک مشتری دریافت می‌کند , و می‌خواهد مشتری را در برابر یک client چک کند ( اجازه دهید بگوییم , dnsbl.example.net ) , این کار کم‌تر یا بیشتر انجام می‌دهد :

  1. آدرس ip مشتری را بگیرید - مثلا ً - و ترتیب octets را معکوس کنید , ۲۳.۴۲.۱۶۸.۱۹ 2 را تسلیم کنید .
  2. الحاق نام دامنه DNSBL : ۲۳.۴۲.۱۶۸.۱۹ .
  3. این نام را در dns به عنوان نام دامنه ( یک رکورد ) ببینید . این موضوع یا آدرس را برمی گرداند و نشان می‌دهد که مشتری فهرست شده‌است ; یا کد " NXDOMAIN " ( " فاقد دامنه " ) , که نشان می‌دهد مشتری نیست .
  4. به صورت اختیاری , اگر مشتری لیست شود , نام را به عنوان یک رکورد متنی ( رکورد " TXT " ) نگاه کنید. بیشتر DNSBLs اطلاعاتی را در مورد اینکه چرا یک مشتری به عنوان رکوردهای TXT لیست شده‌است , منتشر می‌کنند.

نگاه کردن به یک آدرس در a شبیه به نگاه کردن به آن در dns معکوس است . تفاوت این است که جستجوی DNSBL از نوع رکورد " a " به‌جای " PTR " استفاده می‌کند و از یک دامنه پیشرو ( مانند dnsbl.example.net بالا ) به‌جای دامنه معکوس خاص استفاده می‌کند .

یک پروتکل غیر رسمی برای آدرس‌های بازگشته توسط queries DNSBL وجود دارد که مطابقت دارد . بیشتر DNSBLs یک آدرس را در شبکه / 8 ip loopback باز می‌گردانند . آدرس ۱۲۷.۰.۰.۲ یک فهرست عمومی را نشان می‌دهد . آدرس‌های دیگر در این بلوک ممکن است چیزی خاص در مورد فهرست کردن نشان دهند - که نشان‌دهنده یک رله باز , پیشکار , میزبان spammer و غیره برای جزئیات rfc ۵۷۸۲ است.

نشانی اینترنتی DNSBL ویرایش

یک پرس و جوی DNSBL ( و یک پرس و جو RHSBL ) نسبتا ً ساده است . نام دامنه برای پرس‌وجو به میزبان فهرست dns به شرح زیر است :

example.net.dnslist.example.com

که dnslist.example.com میزبان فهرست dns و example.net دامنه مورد سوال است . به طور کلی اگر یک رکورد برگردانده شود نام لیست می‌شود .

سیاست های DNSBL ویرایش

DNSBLs مختلف سیاست‌های متفاوتی دارند . سیاست‌های DNSBL در سه جبهه با یکدیگر تفاوت دارند :

  • *اهداف . the به دنبال چه چیزی هستند ? آیا این یک فهرست از سرورهای پست رله باز یا proxies باز - یا آدرس‌های ip شناخته‌شده برای ارسال اسپم - یا شاید آدرس ip متعلق به isp هایی است که harbor را ارسال می‌کنند ? *نامزدی . DNSBL چگونه addresses را برای لیست کشف می‌کند ? آیا از نامزدی ارائه‌شده توسط کاربران استفاده می‌کند ? آدرس‌های تله اسپم یا honeypots ? *فهرست عمر . فهرست چه مدت طول می‌کشد ? آیا آن‌ها به صورت خودکار منقضی می‌شوند یا تنها به صورت دستی حذف می‌شوند ? اپراتور یک میزبان لیست شده چه کاری می‌تواند انجام دهد ?

انواع ویرایش

علاوه بر انواع مختلف موجودیت‌های فهرست‌شده ( آدرس‌های ip برای نام‌های سنتی DNSBLs , میزبان و دامنه برای RHSBLs , نشانی‌های اینترنتی برای URIBLs ) , طیف وسیعی از تغییرات معنایی بین لیست وجود دارد که به معنی فهرست کردن است . maintainers لیست خودشان در مورد اینکه آیا فهرست آن‌ها باید به عنوان عبارات حقیقت عینی یا نظر ذهنی دیده شود و اینکه چگونه لیست‌های آن‌ها باید به بهترین نحو استفاده شوند , تقسیم شده‌اند . در نتیجه هیچ رده‌بندی قطعی برای DNSBLs وجود ندارد . برخی از نام‌های تعریف‌شده در اینجا ( مانند " زرد " و " NoBL " ) گونه‌هایی هستند که کاربرد گسترده‌ای ندارند و بنابراین خود اسامی در استفاده گسترده نیستند , بلکه باید توسط بسیاری از متخصصان کنترل اسپم شناسایی شوند .

لیست سفید / لیست مجاز
یک فهرست نشانه مثبتی از اعتماد اساساً مطلق است
لیست سیاه / لیست بلوک
یک فهرست نشانه منفی اساساً بی اعتمادی مطلق است
لیست خاکستری
اغلب به عنوان یک کلمه (فهرست خاکستری یا فهرست خاکستری) دیده می شود که مستقیماً DNSBL ها را شامل نمی شود، اما از تعویق موقت نامه از منابع ناآشنا برای ایجاد شهرت عمومی (مانند لیست های DNSBL) یا جلوگیری از ارسال هرزنامه متمرکز بر سرعت استفاده می کند. گاهی اوقات برای اشاره به DNSBL های واقعی استفاده می شود که در آن لیست ها سطوح و اشکال غیرمطلق متمایز و اشکال اعتماد یا بی اعتمادی را نشان می دهند.
لیست زرد
یک فهرست نشان می‌دهد که منبع ترکیبی از هرزنامه و غیرهرزنامه را تولید می‌کند تا حدی که بررسی سایر DNSBL‌ها از هر نوع بی‌فایده باشد.
لیست NoBL
یک لیست نشان می دهد که اعتقاد بر این است که منبع هیچ هرزنامه ای ارسال نمی کند و نباید تحت آزمایش لیست سیاه قرار گیرد، اما به اندازه یک منبع در لیست سفید قابل اعتماد نیست.

استفاده ویرایش

  • اکثر عوامل انتقال پیام (MTA) [nb ۱] را می توان طوری پیکربندی کرد که به طور مطلق مسدود یا (به طور معمول کمتر) ایمیل را بر اساس فهرست DNSBL بپذیرد. این قدیمی ترین شکل استفاده از DNSBL ها است. بسته به MTA خاص، می‌تواند تفاوت‌های ظریفی در پیکربندی وجود داشته باشد که به دلیل نحوه مدیریت MTA با چندین DNSBL، انواع لیست مانند Yellow و NoBL را مفید یا بی‌معنی می‌سازد. یک اشکال استفاده از پشتیبانی مستقیم DNSBL در اکثر MTAها این است که منابعی که در هیچ لیستی قرار ندارند نیاز به بررسی همه DNSBLهایی دارند که با کاربرد نسبتا کمی برای ذخیره نتایج منفی استفاده می شوند. در برخی موارد این می تواند باعث کندی قابل توجهی در تحویل نامه شود. استفاده از لیست های سفید، زرد و NoBL برای جلوگیری از برخی جستجوها می تواند برای کاهش این مشکل در برخی MTA ها استفاده شود.
  • DNSBL ها را می توان در نرم افزارهای تجزیه و تحلیل هرزنامه مبتنی بر قانون مانند Spamassassin استفاده کرد که در آن هر DNSBL قانون خاص خود را دارد. هر قانون دارای وزن مثبت یا منفی خاصی است که با انواع قوانین دیگر ترکیب می شود تا به هر پیام امتیاز دهد. این امکان استفاده از قوانینی را فراهم می کند که (با هر معیاری که در نرم افزار خاص موجود است) به نامه های "فهرست سفید" که در غیر این صورت به دلیل فهرست DNSBL یا قوانین دیگر رد می شوند، عمل می کنند. این همچنین می‌تواند مشکل بارگیری سنگین DNS برای عدم نتایج مفید را داشته باشد، اما ممکن است نامه‌ها را چندان به تأخیر نیندازد زیرا امتیازدهی امکان انجام جستجوها را به صورت موازی و ناهمزمان در حالی که فیلتر در حال بررسی پیام در برابر قوانین دیگر است، می‌کند.
  • این امکان وجود دارد که با برخی از مجموعه ابزارها، رویکردهای تست باینری و قوانین وزنی را با هم ترکیب کنیم. یکی از راه‌های انجام این کار این است که ابتدا لیست‌های سفید را بررسی کنید و اگر منبع در لیست سفید قرار دارد، پیام را بپذیرید و همه مکانیسم‌های آزمایشی دیگر را دور بزنید. تکنیکی که توسط فیلتر ایمیل ناخواسته [۱] توسعه داده شده است، از لیست‌های زرد و لیست‌های NoBL برای کاهش موارد مثبت کاذب استفاده می‌کند که به طور معمول هنگام استفاده از لیست‌های سیاه که برای اجتناب از آنها به دقت نگهداری نمی‌شوند، رخ می‌دهد.
  • برخی از DNSBL ها برای استفاده هایی غیر از فیلتر کردن ایمیل برای هرزنامه، بلکه برای اهداف نمایشی، اطلاعاتی، بلاغی و آزمایشی ایجاد شده اند. مثال‌ها عبارتند از: «فهرست منفی کاذب»، «فهرست هفت شانس»، «فهرست فیبوناچی»، فهرست‌های مختلفی که اطلاعات GeoIP را کد می‌کنند، و فهرست‌های انتخاب تصادفی مقیاس‌بندی شده برای مطابقت با پوشش فهرست دیگر، که به‌عنوان کنترلی برای تعیین اینکه آیا اثرات آن فهرست مفید است. قابل تشخیص از ردهای تصادفی

انتقاد ویرایش

برخی کاربران و سازمان‌های نهایی در مورد مفهوم DNSBLs یا ویژگی‌های چگونگی ایجاد و استفاده آن‌ها نگران هستند . برخی از انتقادات عبارتند از :

  • ایمیل‌های قانونی همراه با اسپم از mailservers مشترک مسدود شدند . زمانی که an مشترک isp دارای یک یا چند ماشین در معرض خطر برای ارسال اسپم باشد , می‌تواند در یک DNSBL لیست شود . کاربران نهایی که به همان mailserver مشترک تخصیص داده می‌شوند ممکن است ایمیل‌های خود را با دریافت mailservers با استفاده از چنین DNSBL مسدود کنند . در ماه می سال ۲۰۱۶ , سیستم SORBS سرورهای smtp of استرالیا , بزرگ‌ترین تامین‌کننده خدمات اینترنتی استرالیا را مسدود کرد . هیچ تعجبی ندارد که در هر زمانی هزاران کامپیوتر متصل به این سرور پستی که آلوده به ویروس‌های نوع زامبی است که اسپم ارسال می‌کنند وجود دارد . این اثر قطع همه ایمیل‌های قانونی کاربران سیستم Telstra استرالیا است . فهرست نشانی‌های ip پویا . این نوع از DNSBL آدرس‌های ip ارائه‌شده توسط isp ها به عنوان پویا را فهرست می‌کند و بنابراین احتمالا ً برای ارسال مستقیم ایمیل نامناسب است . اما این فهرست‌ها می‌توانند به طور تصادفی شامل آدرس‌های استاتیک نیز باشند که ممکن است به طور قانونی توسط صاحبان تجارت‌های کوچک یا دیگر کاربران نهایی برای میزبانی سرورهای پست الکترونیکی استفاده شوند . لیستی که شامل " عملیات پشتیبانی اسپم " , مانند نقشه‌های RBL است. یک عملیات پشتیبانی اسپم , سایتی است که ممکن است مستقیما ً اسپم ارسال نکند , بلکه خدمات تجاری برای spammers فراهم می‌کند , مانند میزبانی وب سایت‌هایی که در اسپم تبلیغ می‌شوند . امتناع از پذیرش نامه از عملیات پشتیبانی اسپم به عنوان تحریم برای تشویق چنین سایت‌هایی برای توقف تجارت با spammers , با هزینه ایجاد دردسر غیر spammers که از سایتی مشابه با spammers استفاده می‌کنند , در نظر گرفته می‌شود. برخی از فهرست‌ها معیارهای لیست نامشخص دارند و delisting ممکن است به صورت خودکار یا سریع اتفاق نیفتد . چند اپراتور DNSBL درخواست پرداخت ( مانند uceprotect.net ) یا اهدا ( مانند SORBS ) خواهند کرد. برخی از سیاست‌های فهرستی / delisting را می‌توان در مقایسه با مقاله dns blacklists یافت . از آنجا که لیست‌ها روش‌های مختلفی برای اضافه کردن آدرس‌های ip و / یا نشانی‌های اینترنتی دارند , پیکربندی مناسب سیستم‌های آن‌ها برای اجتناب از فهرست شدن در یک DNSBL دشوار است . برای مثال , به نظر می‌رسد که DNSBL UCEProtect فقط زمانی آدرس‌های ip را لیست می‌کند که آدرس گیرنده را تایید کرده یا یک اتصال tcp ایجاد کرده‌اند , حتی اگر هیچ پیام اسپم ارسال نشود .

با وجود این انتقادات , تعداد کمی از مردم به این اصل اعتراض دارند که سایت‌های دریافت نامه باید بتوانند بطور سیستماتیک پست نامطلوب را رد کنند . یکی از کسانی که این کار را می‌کند جان گیلمور است که عمدا ً یک مراسم حمل ایمیل باز را اجرا می‌کند گیلمور اپراتورهای DNSBL را به نقض قانون ضد تراست متهم می‌کند .

برای جو بلو رد ایمیل قانونی است (اگرچه این سیاست بدی است، شبیه به "تیراندازی به پیام رسان"). اما اگر جو و ده میلیون دوست برای ایجاد یک لیست سیاه دست به دست هم بدهند، قدرت انحصاری غیرقانونی را اعمال می کنند.

تعدادی از احزاب , مانند بنیاد مرزی الکترونیک و Peacefire , نگرانی‌هایی در مورد استفاده از DNSBLs توسط isp ها ایجاد کرده‌اند . یک بیانیه مشترک که توسط گروهی از جمله EFF و Peacefire صادر شد , به " منع پنهان " اشاره کرد که در آن isp ها از تکنیک‌های DNSBLs یا دیگر روش‌های منع اسپم بدون اطلاع مشتریان خود استفاده می‌کنند .

دعاوی حقوقی ویرایش

Spammers به دلایل مشابهی علیه اپراتورهای DNSBL اقامه دعوی کرده‌است :

درجبند

  • در سال ۲۰۰۳ , EMarketersAmerica.org دادخواستی را علیه تعدادی از اپراتورهای DNSBL در یک دادگاه فلوریدا مطرح کرد. این شرکت که توسط spammer ادی مارین پشتیبانی می‌شد ادعا کرد که یک سازمان تجاری برای بازاریابان ایمیلی است و اپراتورهای DNSBL Spamhaus و SPEWS در منع تجارت شرکت داشتند . این کت و شلوار در نهایت به خاطر عدم ایستادن مرخص شد . در سال ۲۰۰۶ , دادگاه ایالات‌متحده به Spamhaus دستور داد تا ۱۱.۷ میلیون دلار خسارت به دیدگاه spammer e360 llc بپردازد . این حکم حکم پیش‌فرض بود , زیرا Spamhaus , که در انگلستان مستقر است , از تشخیص صلاحیت دادگاه امتناع کرده و در دادخواست e360 از خود دفاع نکرده بود . در سال ۲۰۱۱ , تصمیم او توسط دادگاه استیناف ایالات‌متحده برای مدار هفتم لغو شد .

همچنین ببینید ویرایش

یادداشت ویرایش

  1. As of July 2016, 30 out of 41 MTAs listed in Comparison of mail servers#Antispam features are known to support DNSBL, 1 doesn't, and the remaining 10 are not known.

منابع ویرایش

  1. "Junk Email Filter". Wiki.junkemailfilter.com. 2012-02-17. Retrieved 2012-05-06.

لینک های خارجی ویرایش