Електронната поща и златната ябълка

от admin | юли 26, 2012 | Съвети, Технологии | 2 коментари

В приказния свят на народното творчество юнакът традиционно трябва да преодолее минимум три препятствия за да изпълни своето добро дело. В днешно време, задачата на всяко електронно съобщение да стигне до своя получател, не е по-лека . С развитието на мейл маркетинга, все по-нежелан, но и все по-разпространен, изпитанията се увеличават и стават по-сериозни. В този материал ще стане дума за три от тях: 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 проверки. Ограниченията, въведени в публичните мейл сървъри са съобразени изцяло с актуалните тенденции във филтрирането на СПАМ, като по този начин се гарантира безотказна работа на мейл услугата.

Хостинг контролният панел – нещо повече от кутия с инструменти

от | май 9, 2012 | Съвети, Технологии |

За потребителите на хостинг услуги контролният панел е полезен и дори незаменим помощник при изграждането на техния уеб сайт. Нещо повече, контролният панел може да облекчи и улесни работата по осъществяване на „уеб“ идеите на потребителя в такава степен, че да се превърне в своеобразен негов партньор. С такъв помощник клиентът може да се фокусира в своята основна бизнес или друга цел, като му бъдат спестени подмолните камъни по пътя на осъществяването на един проект, както и немалка част от техническите затруднения. Когато става дума за такъв важен помощник, изборът очевидно е важен.

Това, за което потребителите обикновено не си дават сметка е, че функциите на контролния панел не се изчерпват с инструментариума, осигурен да помогне при създаването и поддържането на уеб сайтовете. В повечето от съществуващите продукти контролният панел и софтуерът осигуряващ хостинг услугата са един и същ продукт. Това означава, че контролният панел отговаря не само за „инструментите“, но и за базовата хостинг функционалност. В това число влизат защитеността на хостингите, надеждността на работа на хостинг сървъра и неговата производителност.

За да сме коректни, трябва да отбележим, че на пазара за хостинг софтуер вече има специализирани продукти, които се нагърбват с нелеката задача да осигурят базовата функционалност. Двата продукта – хостинг софтуер и контролен панел могат да съжителстват заедно, като всеки изпълнява различни задачи. Така се постига по-висока специализация и по-високо качество на двете приложения. Все още обаче, този модел на предлагане на хостинг не е масово разпространен, включително в България.

Да се върнем на традиционния модел. Доставчиците, които залагат на продукт, разработен и предлаган от трета страна, на практика оставят по-голямата част от гаранциите за качествена услуга в други ръце. Това може би не е толкова опасно, колкото звучи на пръв поглед, когато става дума за реномиран разработчик и утвърден продукт. Дори в този случай обаче, хостинг доставчикът е с вързани ръце, когато избира посока на развитие. Причината не е във факта, че той обикновено няма желание, интерес или потенциал да доработва продукта, нито в технологичните затруднения, свързани с използването на традициония API. Проблемът идва от това, че всяка сериозна доработка отдалечава софтуера от неговия родител и прави невъзможно или неефективно връщането към следващата версия на хостинг софтуера. Така, в дългосрочен план, използването на стандартен софтуер, създава ограничения за един хостинг доставчик.

Разработчикът на комерсиалния продукт от своя страна също прави контролиран избор. Представете си, че той създаде версия, която изисква ъпгрейд на хардуера, смяна на платформата или друга сериозна промяна. Дори новата версия да предлага комплект от качествени подобрения, адекватни на актуалните тенденции в развитието на технологите и потреблението, тя трудно ще се приеме от хостинг доставчиците. Причината е очевидна, промяната не следва техния план, а темпа на развитие, който разработчикът е избрал.

Да разгледаме няколко примера. Повечето комерсиални хостинг панели организират работата на хостинг и мейл услугата върху един и същ сървър. Това е било рационално архитектурно решение в момента на тяхното създаване. С течение на времето обаче, обемът на атаките, които във всеки момент се провеждат в уеб, е нарастнал с няколко порядъка. Същото е положението и с обема на електронната поща, дори без да отчитаме тази с етикет „нежелана“. Сега работата на двете услуги на една физическа машина не е добро решение. Този проблем е преодолян от контролния панел на Host.bg , който предлага управлeние от едно място на хостинга, разположен на хостинг сървър и мейл услугата от облачен вид, която работи върху множество сървъри.

Типично решение в комерсиалните хостинг панели е използването на функциите на операционната система за управление на един от важните параметри на хостинга – квотата за използваното дисково пространство. Това е едно ефективно решение от гледна точка на икономия на системен ресурс. За акаунти, които се ползват от един или двама потребителя, тази икономия може би е оправдана. Когато обаче акаунтът е фирмен и се ползва от повече хора, ограниченията, които това икономично решение налага върху функционалността, водят до загуба на най-ценното – времето на потребителите. Управлението на квотите от контролния панел на Host.bg гарантира независимост на работата на всеки потребител от поведението на останалите. Това е особенно ценно в момент, когато една електронна пощенска кутия, може да се окаже препълнена без участието или знанието на нейния притежател.

Преходът от един контролен панел към друг обикновено създава притеснение у потребителите. Затова той често е обект на спекулация от доставчиците на услуги, ползващи комерсиален хостинг софтуер. Залага се на интуитивното усещане у потребителя, че контролният панел фиксира версиите на използваните сървъри, приложения и библиотеки, а всеки е наясно, че промяната на този комплект води до несъвместимост с вече създадения уеб сайт. Факт е обаче, че добрият контролен панел дава избор на въпросните версии, включително такива, използвани преди 3 и повече години. Изборът на версиите на PHP например, в контролния панел на Host.bg е настройка, която може да се направи веднага след наемане на хостинга. За разлика от стандартен контролен панел освен това, Host.bg зарежда отделни копия на PHP модулите за всеки клиент, което намалява зависимостта на един потребител от поведението на останалите, ползващи същия уеб сървър.