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


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

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

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

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

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

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

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

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

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

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

WordPress – история с лесно начало

WordPress безспорно се наложи като най-предпочитаната блог платформа в света със своите над 60 милиона потребители. Постоянно излизат нови подобрения като безплатни теми (визии), нови plugin-и и най-различни джаджи. Случва се често обаче, един обикновен блог с не голям брой посещения да се отваря бавно и да изпитва нужда от допълнителен хостинг ресурс. Ако до момента вашият блог не е имал проблем с потреблението на голям ресурс от хостинга ви, това значи че или още не е станал популярен или

сте положили грижи за неговото оптимизиране.
Изчерпването на хостинг ресурсите идва неочаквано, особено когато регистрирате редовно нови посетители. Както знаем, WordPress е мощна платформа, която позволява на блогърите бързо, лесно и адаптивно да управляват своята блог страничка. За нещастие, тази гъвкавост, води и до промени в структурата и дизайна, които самата платформа все още не обслужва оптимално.
В следващите няколко реда ще се опитаме да разберем на какво се дължи това, като отговорим на няколко важни въпроса.

Как работи WordPress с базата данни?

WordPress се обръща към MySQL базата данни (БД) за всичко! За всяка страница, която се визуализира, WordPress прави множество заявки към БД. Високата свързаност и бързата работа на сървърните хард-дискове са нещо, което може намали забавящия ефект на множеството заявки. Има неща обаче, които не могат да бъдат избегнати. Тук влизат използването на памет за осъществяване на тези операции и общата сложност на изпълнение на всички заявки.
Нека разгледаме един прост пример. Ето какво се случва когато направим една заяква към базата данни във вашия блог:

Тя казва следното:

1. Отвори връзка към базата данни;
2. Провери пълномощията;
3. Подготви заявки, за които трябва да се чете в няколко таблици;
4. Вземи записа обратно;
5. Направи анализ на информацията;
6. Сложи по-малко от 30 знака текст на един елемент на вашата страница.

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

Как се държи уеб сървърът?

Повечето хостинги са базирани на операционна система Linux и използват Apache уеб сървър. Apache е усъвършенстван уеб сървър, който може да обслужва всички нужди на WordPress. С неговата универсалност обаче, идва и нуждата от ресурси. Всеки потребител, който се свързва към Apache зарежда множество елементи от вашия блог: изображения, скриптове, различни стилове и HTML. Това натоварва уеб сървърa, заради големия брой заявки.
Второто предизвикателство е свързано с това, че интернет връзките са „словоохотливи”. Докато пишете в блога си, браузърът ви изисква три различни начина на „ръкостискане” с мрежата. Той прави множество запитвания към хостинг сървъра, който от своя страна му отвръща съвестно и това се случва през цялото време. Това може да доведе до проблеми с изпълнението на определена заявка, в моментите на пиково натоварване на мрежата, от която потребителят сърфира.

Проблемът не е ли в хостинга?

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

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


Процесорът Nehalem EP е два пъти по продуктивен от предшественика си

Първият едночипов 8-ядрен процесор на Intel с кодово име Nehalem EX, вече е на пазара. Новият чип е изработен по 32-нановата технология. Архитектурата на процесора не предлага революционни промени, като отново включва Hyper-Threading (HT) и TurboBoost (TB). Основната разлика е в броя на ядрата, които вече не са 4, а 8. Процесорите от серията Xeon 7500 имат 24МВ L3 кеш и по-бърз достъп до данните в кеш-паметта.

Докато Nehalem EX стане достатъчно разпространен и на приемлива цена, процесорът, който може да предложи оптимално за хостинг потребителите отношение на цена спрямо производителност остава Nehalem EP. Серията се произвежда по добре усвоената 45 нанометрова технология. Моделите от серията Xeon 5500 започват от 5502 с честота 1.86 GHz. Първите два модела 5502 и 5504 могат да са с 2 или 4 ядра, но нямат HT и TB. Всички модели от 5530 нагоре са от типа Quad Core и поддържат по две нишки на ядро, както и TurboBoost.

По данни от Intel, постигнати с конфигурации с два процесора и няколко различни приложения, средната производителност на 5500 надвишава около два пъти тази на процесорите от серията 5400 с кодово име Harpertown.

Работата на базата данни е ключова при предлагането на уеб услуги. Традиционно, интелските процесори се представят добре при работа с продуктите на Microsoft. Данните на следващата схема са получени при работа на конфигурация на Fujitsu с MS SQL 2008 сървър. Използван е процесорът Xeon 5570 с тактова честота 2.93 GHz в X86 платформа и Primergy RX300 G5 сървър. Сравнението е направено с TPC-E Benchmarc, а метриката е tps (transactions per second). Xeon QuadCore X5570 показва 152% по-висок резултат от предшественика си Xeon QuadCore X5460.

Сравнението на производителността на процесорите при работата на Oracle база данни с HP ProLiant DL370 G6 e направено с TCP-C бенчмарк и tpm (transaction per minute) метрика. X5460 е в конфигурация с 64 GB и Oracle 10g, а X5570 e тестван със 144 GB и Oracle 11g. Nehalem EP е изпълнил 125% повече транзакции в сравнение с Harpertown процесора.

Сериозно увеличение се постига с X5570 при оценка на SpecWEB2005 бенчмарк. За проверката отново е използван HP DL370 G6 сървър на който са инсталирани Rock Web Server 1.4.7 и Red Hat Linux 5.3. Бенчмаркът включва три различни приложения – банково ( https), електронна търговия (http и https) и предоставяне на съдържание (http).

Енергийната ефективност на процесорите е оценена с SPECpower_ssj2008. Бенчмаркът включва проверка на използваната мощност при 11 различни нива на натоварване от 0 до 100% през 10% и усредняване на получените резултати за отношението производителност на ват. Представени са оптималните резултати постигнати с IBM System x 3650 M2 сървър с IBM J9 Java virtual Machine и Microsoft Windows Server 2008 Enterprice.