Електронната поща и златната ябълка
В приказния свят на народното творчество юнакът традиционно трябва да преодолее минимум три препятствия за да изпълни своето добро дело. В днешно време, задачата на всяко електронно съобщение да стигне до своя получател, не е по-лека . С развитието на мейл маркетинга, все по-нежелан, но и все по-разпространен, изпитанията се увеличават и стават по-сериозни. В този материал ще стане дума за три от тях: RBLs, rDNS и SPF.
Започваме, както си му е редът, с първата ламя – RBLs.
Още при изпращане на едно съобщение, мейл сървърът на услугата, която ползвате, независимо дали е частна или публична, прави проверка дали IP адресът от който изпращате е включен в някой от Real-time Blackhole Lists (RBLs). RBLs представляват разпределена система за проследяване на източниците на спам. Те се използват от различни приложения, за да се установи дали на даден IP адрес “може да се има доверие”. За целта се прави проверка на IP адреса на подателя. Ако той е попаднал в RBLs, значи е потенциален изпращач на СПАМ.
Списъците следват различни правила за включване на един адрес. Някои от тях са пасивни и ползват информация от SMTP сървърите. Механизмът за идентифициране на дадено съобщение като СПАМ, а адресът на подателя като спамърски, се променя и подобрява постоянно. Други RBLs активно търсят спамърите. Те използват кутии клопки с традиционни имена, като office@…, sales@… и т. н. За тези кутии със сигурност е известно, че не са включвани в мейл списъци с абонати на каквато и да е информация. Изпращачите на е-поща към тези кутии автоматично се включват в “черните списъци”.
Подобни списъци съществуват от много години. Администраторите на частни мейл услуги традиционно ги ползват, като често проверяват по няколко списъка преди да допуснат едно съобщение за изпращане. Увеличаването на обема на спам съобщенията в последните години обаче, принуди доставчиците на комерсиални и публични мейл услуги също да започнат да ги използват активно, въпреки един очевиден недостатък на това решение.
Представете си, че вашият компютър се намира в локална мрежа от 500 компютъра. Това може да е мрежата на голяма фирма или на местен интернет доставчик. Когато изпратите е-поща тя пристига при изпращащия (SMTP) сървър от IP адреса на рутъра на мрежата. Ако дори един компютър или лаптоп от тази мрежа е заразен с вирус, който генерира СПАМ, IP адресът попада в RBL. Така проверката на мейл, изпратен от който и да е компютър от тази мрежа, ще показва потенциално опасен подател и съобщенията ще бъдат блокирани.
В случай, че се сблъскате с подобен проблем трябва да направите две неща – да се свържете с доставчика на мейл услугата за да изясните точно къде е проблемът и да се заинтересувате от “хигиената” на локалната мрежата, в която се намира вашият компютър.
Ако адресът на подателя е минал през “ситото” на RBLs, идва ред на препятствието rDNS.
rDNS е съкращение на „reverse DNS lookup“, което на на български е добило популярност като „обратен резолвинг“. Името се налага от факта, че най-често изпълняваната идентификация в Интернет е намирането на IP адреса на един сайт по неговото домейн име, необходима за намиране и зареждане на сайта в браузъра. При обслужване на мейл трафика се налага изпълнението на обратната операция – установяване на домейн име, което е свързано с даден IP адрес.
Информацията за обратния резолвинг се съхранява отново в DNS, само че в записите за специално предназначения за целта домейн in-addr.arpa. За версия 6 на IP адресите – IPv6, rDNS домейнът е ip6.arpa. Самите записи не са стандартни и имат вида: „3.40.120.87.in-addr.arpa domain name pointer mail.host.bg“, което означава, че на IP адреса 87.120.40.3 е зададено името на мейл сървърът на Host.bg – mail.host.bg.
Проверката „oбратен резолвинг“ се прави в приемната страна. Още когато сървърът подател се опита да осъществи комуникация със следващия във веригата, той минава rDNS проверка. За да бъде успешна тази проверка, съответната настройка (запис в in-addr.arpa) трябва да бъде направена от собственика на мрежата в която се намира IP адресът на машината подател.
Това не носи 100% защита от разпращане на СПАМ, но включва в процеса на идентификацията на подателя трета страна, което затруднява процеса на създаване на спамърски канал. Хостинг компаниите, в това число и Host.bg, за които мейл услугата е една от основните, спазват строги правила при проверката на мейл източниците. Интернет доставчиците от своя страна провеждат различна политика в това отношение, понякога доста либерална.
Всичко това води до появата на следващото изпитание за нашето електроно съобщение – SPF.
Sender Policy Framework (SPF) също е система за проверка, предназначена за предотвратяване на СПАМ. Тя позволява на администраторите да установят от кои хостинги сървъри е позволено да се изпраща поща от името на даден домейн. За целта се ползва специален SPF запис в DNS зоната на домейна.
Липсата на сигурност в SMTP улеснява спамърите да изпращат е-поща от подправени мейл адреси. По този начин проследяването на подателя се затруднява, а спамърите могат лесно да скрият своята самоличност и да избягат от отговорност.
Както rDNS, SPF информацията се използва от сървъра-получател на е-поща. Тя му позволява да определи дали сървърът подател е упълномощен да изпраща поща от e-mail адреси в определен домейн. За това се използват SPF записите в система за имена на домейни (DNS). Всъщност специални SPF записи няма – това са стандартни TXT записи, които спазват определен синтаксис и изполват специални думи. Приемната страна прави проверка дали такива записи съществуват и какво е тяхното съдържание и на тази база може да отхвърли съобщения от неоторизирани източници.
SPF-защитените домейни са по-малко привлекателни за спамърите. Ако даден домейн има публикуван SPF запис, е малко вероятно да бъде използван като подател на СПАМ защото една от задачите на Спам филтрите е да проверяват именно SPF записите. Всеки домейн или хостинг, който има „А“ или „MX“ запис, трябва да има SPF запис. Домейните на хостинг машини, които не изпращат е-поща, трябва да имат SPF запис от вида „V = spf1 -all „, където „V=“ определя версията на използвания SPF. Това е препоръчително, за да се валидира SPF записът от инструментите за тестване на SPF.
Няма официално изследване каква част от мейл сървърите проверяват SPF записи или каква част от домейните притежават SPF запис. По някои оценки на специалисти става дума за под 10% от домейните. Все повече мейл сървъри обаче, включват тази проверка, което може ненадейно да доведе до прекъсване на връзката между един подател и неговите партньори или приятели, с които до скоро не е имал никакъв проблем с мейл комуникацията.
Host.bg провежда балансирана пoлитика, която включва максимален обем мероприятия насочени срещу СПАМ, без да се стига до блокирането на поща от легални частни или публични мейл услуги. Компанията осигурява SPF записи за клиентите със собствен мейл съръвър и изпълнява RBLs и rDNS проверки. Ограниченията, въведени в публичните мейл сървъри са съобразени изцяло с актуалните тенденции във филтрирането на СПАМ, като по този начин се гарантира безотказна работа на мейл услугата.