1. Какво е SMTP: - протокол за предаване на електронна поща от клиент (MUA) към сървър (MTA) или от сървър към друг сървър (междинен или краен). - да, това се отнася дори за webmail среди, макар че там първото прехвърляне (от клиента към (обикновено локалния) сървър) е скрито и вероятно се прави по друг начин - две думи за историята - UUCP? или няма нужда? 2. Животът на едно e-mail съобщение - ражда се при взаимодействие между потребител и e-mail клиент (MUA - mail user agent) - има един или повече получателя - има header и body, а в зависимост от начина на зараждане може още на този етап да се появи и envelope: всъщност да бъде изпратен на адреси, които не се споменават по никакъв начин в header и body. - трябва да стигне до нещо, популярно наричано e-mail сървър, а всъщност представляващо MTA (mail transport agent) - до първия MTA обикновено стига само едно копие на съобщението - MTA анализира header-а (или envelope, ако му е подадено по подходящ начин) и прави списък от адреси на получатели - за всеки адрес на получател се решава дали е локален или трябва да бъде изпратен до друг MTA - за всеки remote адрес се решава до кой SMTP сървър да бъде изпратен - отваря се връзка до всеки SMTP сървър - чрез SMTP (ще говорим повече по-надолу) се изпраща съобщението, като ако има повече от един адрес, за когото е определен този сървър, се изпраща само едно копие до няколкото адреса там - ако remote SMTP сървърът върне съобщение за временна грешка, оставяме в опашката за retransmit по-късно - ако remote SMTP сървърът върне съобщение за сериозна (постоянна?) грешка, решаваме дали да изпратим bounce (ето защо винаги трябва да имаме пощенски кутии postmaster и mailer-daemon!) - когато всички remote SMTP сървъри са приели съобщението или са върнали съобщение за сериозна грешка или е изтекъл timeout, изтриваме съобщението от опашката - когато при нас дойде съобщение чрез SMTP, проверяваме дали е за наш локален потребител или не; ако не, се връщаме до изпращането на друг MTA - съобщенията за локални потребители предаваме на MDA (mail delivery agents) - MDA проверява дали има такава пощенска кутия при нас, ако няма, връща bounce - след като съобщението е стигнало до пощенската кутия, вече е работа на клиента как ще го прочете: POP3, IMAP, webmail, или някаква комбинация от изброените 3. И все пак... що за чудо е SMTP :) - структура: handshake, auth, envelope, data, envelope, data, envelope, data.. - handshake: "представяне" на сървърите (ако има access control, макар че е глупаво на този етап); опции: осембитово предаване на данни, автентикация, куп още неща - authentication: няколко начина: plaintext, вид CHAP/MD5 (с HMAC/MD5), TLS с X.509 сертификати - envelope: "ще ти изпратя съобщение от еди-кой си адрес до еди-кой си адрес" - тук получаващият сървър може да откаже: не е негов домейн или няма relaying (по-нататък) - data: пълното съобщение, header + body; както казахме, адресите в To и CC на header-а не е нужно да имат нищо общо с адресите от envelope-а - във всеки момент (handshake, auth, envelope, data) сървърът може да върне код за грешка; разлика между transient и permanent грешки, как реагира клиентът (MUA и MTA реагират различно: MUA обикновено няма опашка за *автоматично* повтаряне на предаването :) - други команди: VRFY, EXPN, NOOP, RSET - кратко обяснение - още по-други команди: STARTTLS за X.509, AUTH за plaintext и CHAP/MD5, DSN и ETRN за delivery status notification (което може и да не споменаваме?) 4. Relaying - всеки сървър обикновено приема съобщения за адреси (домейни), за които той е посочен като MX - съвсем не всеки сървър е длъжен да приема съобщения за адреси, които нямат нищо общо с него, и да ги прехвърля нататък (relay, open relay); кратко споменаване на проблемите със спам през open relays - решението: всеки сървър има списък от адреси, от които relay-ва, и/или иска автентикация преди това - повечето ISP-та имат SMTP сървъри, които relay-ват поща от адресите на клиентите си - повечето ISP-та имат POP-before-SMTP от целия свят - някои ISP-та имат SMTP auth от целия свят - blacklists за open relays: списъци на open relays - SMTP сървъри, които relay-ват поща от всички адреси за всички domains, и биват избягвани 5. Проблеми при SMTP (от гледна точка на администратора) - open relays! - непозволен достъп (използване на ресурсите): relaying, spam и т.н. - събиране на информация: VRFY и EXPN са забранени отдавна, а има и SMTP сървъри, които дори не казват "няма такъв mailbox при мен"; има и SMTP сървъри, които затварят връзката при първа сериозна грешка - denial of service: няма много как да се предпазим :) - exploits: предпазваме се с различни програми за различните неща, privilege separation, chroot/jail 6. Реализации на SMTP сървъри - Sendmail: разработена още в зорите на Интернет, била е почти "killer app" за тогавашния Интернет (приложението, което прави цялата история да има смисъл). Разработена от легенди, само че, както и BIND, това не я прави неуязвима: проблеми с монолитността, проблеми с чиста програмистка глупост (debug mode преди... известно време), проблеми при анализ на съобщенията. Навремето проблеми и с usability: странен синтаксис на конфигурационните файлове. Напоследък все по-стабилна и все по-лесна за използване, но все пак има хора, които си имат едно наум. - qmail: основна идея: използване на истинската Unix философия: малки инструментчета, всяко от които прави едно нещо и го прави добре. Парична награда за пробиви в сигурността - досега не е имало (имаше проблеми с vpopmail и проблеми с SMTP auth patch, само че те не бяха части от истинския qmail). Разделени мнения за лекотата на ползване/конфигуриране. Проблем е това, че не се update-ва често и не включва много функционалност за сметка на разширяемостта си; обикновено се налага да се слагат patches за функционалност и да се използва заедно с доста други програмки, което не винаги е минус :) - Postfix, Exim: тук аз не знам нищо :) - MS Exchange: native решение за Windows domain, интегрирано с Active Directory и изобщо структурата от domains, интегрирано с MS Project, MS LookOut! и куп други неща. Проблеми: голям, тежък, не толкова лесно следим (logs и т.н.), като реши да прави глупости, ги прави в голям мащаб. Проблеми със сигурността: много и непрекъснато, вкл. и два в последната година, което хич не е малко, като се има предвид колко малко хора изобщо инсталират security updates и колко бавно ги инсталират и малкото, които го правят - ssmtp, nullmailer: идеални решения за потребителска машина, вързана към ISP, и имаща право да ползва неговия SMTP сървър - други: zmailer (можем да го споменем само като кошмар от не толкова далечното минало)