Електронна пошта

Матеріал з Вікіпедії - вільної енциклопедії

Типовий інтерфейс клієнта електронної пошти, з можливістю вибору папок з повідомленнями (ліворуч), повідомлень (праворуч угорі) та перегляду тексту повідомлень (справа внизу)

Електронна пошта (англ. email, e-mail, Від англ. electronic mail) - Технологія і надані нею послуги з пересилання та отримання електронних повідомлень (званих «листа» або «електронні листи») по розподіленої (у тому числі глобальної) Комп'ютерної мережі. Основною відмінністю від інших систем передачі повідомлень (наприклад, служб миттєвих повідомлень) Є можливість відкладеної доставки і розвинена (і заплутана з-за тривалого часу розвитку) система взаємодії між незалежними поштовими серверами.

Назви

Якщо в Європі, Америці та інших регіонах написання «e-mail» стало практично одноваріантна, то в російській мові присутня значна варіативність. Найбільш часто в кириличних текстах використовується «e-mail», тобто написання латиницею без транслітерації (візуальне сприйняття інших форм написання гірше). Але можна зустріти і інші написання:

• електронна пошта
• імейл, мейл (транскрипція з англійської).^[1]
• е-мейл, емейл, емайл (різні літерні кальки з англійської)
• мило (в просторіччі, від англійського «мейл»)
• пошта (як скорочення від «електронна пошта»)

Правильне написання поки не зафіксовано в словниках. Довідкове бюро Грамота.Ру вказує, що Є. Ваулина в словнику «Мій комп'ютер» пропонує писати e-пошта і е-мейл, Але зазначає, що таке написання не відповідає літературній нормі, в той же час, в іншому відповіді радять писати e-mail латиницею.^[1][2]

Історія

Основна стаття: mail (програма)

Поява електронної пошти можна віднести до 1965 року, коли співробітники Массачусетського технологічного інституту (MIT) Ноель Морріс і Том Ван спричиняв написали програму MAIL для операційної системи CTSS (Compatible Time-Sharing System), встановлену на комп'ютері IBM 7090/7094.

Текстовий інтерфейс програми mail

Загальний розвиток електронної пошти йшло через розвиток локального взаємодії користувачів на багатокористувацьких системах. Користувачі могли, використовуючи програму mail (або її еквівалент), пересилати один одному повідомлення у межах одного мейнфрейма (великого комп'ютера). Наступний крок був у можливості переслати повідомлення користувачеві на іншій машині - для цього використовували вказівка імені машини та імені користувача на машині. Адреса міг записуватися у вигляді foo! Joe (користувач joe на комп'ютері foo). Третій крок для становлення електронної пошти стався в момент появи передачі листів через треті комп'ютер. У разі використання UUCP-адресу користувача містив у собі маршрут до користувача через кілька проміжних машин (наприклад, gate1! gate2! foo! joe- Лист для joe через машину gate1, gate2 на машину foo). Недоліком такої адресації було те, що відправнику (або адміністратора машини, на якій працював відправник) необхідно було знати точний шлях до машини адресата.

Після появи розподіленої глобальної системи імен DNS, Для вказівки адреси стали використовуватися доменні імена -- user@example.com- Користувач user на машині example.com. Одночасно з цим відбувалося переосмислення поняття «на машині»: для пошти стали використовуватися виділені сервери, на які не мали доступ звичайні користувачі (тільки адміністратори), а користувачі працювали на своїх машинах, при цьому пошта приходила не на робочі машини користувачів, а на поштову сервер, звідки користувачі забирали свою пошту по різних мережевих протоколів (серед поширених на даний момент -- POP3, IMAP, MAPI, Веб-інтерфейси). Одночасно з появою DNS була продумана система резервування маршрутів доставки пошти, а доменне ім'я в поштовій адресі перестало бути ім'ям конкретного комп'ютера і стало просто фрагментом поштової адреси. За обслуговування домену можуть відповідати багато серверів (можливо, фізично розташовані на різних континентах і в різних організаціях), а користувачі з одного домену можуть не мати між собою нічого спільного (особливо такий стан характерний для користувачів безкоштовних серверів електронної пошти).

Крім того, існували (і існують по даний момент) та інші системи електронної пошти (деякі з них існують і зараз), як-то: Netmail у мережі Фідонет, X.400 в мережах X.25^{[уточнити]}. Доступ до них з інтернет і назад здійснюється через поштовий шлюз. Для маршрутизації пошти в мережах X.25 в DNS передбачена спеціальна ресурсна запис c відповідною назвою X25 (код 19).

Сучасна архітектура (SMTP)

Основна стаття: SMTP

Найпростіший випадок пересилання пошти

Загальноприйнятим у світі протоколом обміну електронною поштою є SMTP (англ. Simple mail transfer protocol- Простий протокол передачі пошти). У загальноприйнятою реалізації він використовує DNS для визначення правил пересилання пошти (хоча в приватних системах, на зразок Microsoft Exchange, SMTP може діяти виходячи з інформації з інших джерел).

У різних доменах налаштовані свої, незалежні один від одного, поштові системи. У кожного поштового домену може бути декілька користувачів. (Однак, фактично, може бути так, що одна організація чи особа володіє багатьма доменами, які обслуговуються (фізично) однією поштовою системою). Пошта передається між вузлами за використанням програм пересилання пошти (англ. Mail Transfer Agent; Такими, як, наприклад, sendmail, exim4, postfix, Microsoft Exchange Server, Lotus Domino і т. д.). Поведінка систем при зв'язки один з одним суворо стандартизовано, для цього використовується протокол SMTP (і дотримання цього стандарту, нарівні з загальною підтримкою DNS всіма учасниками, є основою для можливості зв'язку «усіх з усіма» без попередніх домовленостей). Взаємодія поштової системи і користувачів, у загальному випадку, ніяк не регламентується і може бути довільним, хоча існують як відкриті, так і закриті (зав'язані на ПЗ конкретних виробників) протоколи взаємодії між користувачами і поштовою системою. Програма, що працює в поштовій системі і обслуговує користувачів, називається MDA (англ. mail delivery agent, Агент доставки пошти). У деяких поштових системах MDA і MTA можуть бути об'єднані в одну програму, в інших системах можуть бути рознесені у вигляді різних програм або взагалі виконуватися на різних серверах. Програма, за допомогою якої користувач здійснює доступ, називається MUA (англ. mail user agent), Хоча у випадку, наприклад, веб-інтерфейсу, і може бути відсутнім.

Всередині заданої поштової системи (зазвичай знаходиться в рамках однієї організації) може бути безліч поштових серверів, що виконують як пересилання пошти всередині організації, так і інші, пов'язані з електронною поштою завдання: фільтрування спаму, перевірку вкладень антивірусом, забезпечення автовідповіді, архівація вхідної / вихідної пошти , забезпечення доступу користувачам різними методами (від POP3 до ActiveSync). Взаємодія між серверами в рамках однієї поштової системи може бути як підпорядковане загальними правилами (використання DNS і правил маршрутизації пошти за допомогою протоколу SMTP), так і слідувати власними правилами компанії (використовуваного програмного забезпечення).

Релеї

DNS дозволяє вказати в якості приймаючої сервера (MX-запис) Будь-який вузол інтернету, не обов'язково є частиною доменної зони домену одержувача. Це може використовуватися для налаштування релеінга (пересилання) пошти через треті сервери. Сторонній сервер (наприклад, більш надійний, ніж сервери користувача) приймає пошту для домену користувача і пересилає його на поштові сервери користувача як тільки з'являється можливість. Історично, контролю за тим, «кому пересилати» почту не було (або цьому не надавали належного значення), та сервери без подібного контролю передавали пошту на будь-які домени. Такі сервери називаються відкритими релея (в даний час нові відкриті релеї з'являються в основному через помилки в конфігуруванні сервера).

Для своїх користувачів сервери поштової системи є реле (користувачі відправляють пошту не на сервери поштової системи адресата, а на «свій» поштовий сервер, який передає листа далі). У багатьох мережах провайдерів інтернету можливість відправляти листи по протоколу SMTP за межі мережі закрита (через використання цієї можливості троянами, вірусами). В цьому випадку провайдер надає свій SMTP-сервер, через який і йде вся пошта за межі мережі. Відкритим реле при цьому вважається такою релей, який не перевіряє, чи є користувач «своїм» (перевірка може здійснюватися як на підставі мережевого адреси комп'ютера користувача, так і на підставі ідентифікації користувача паролем / сертифікатом).

Маршрутизація пошти

Поштовий сервер, отримавши пошту (з локального джерела або від іншого сервера) перевіряє, чи існують специфічні правила для обробки пошти (правила можуть грунтуватися на імені користувача, на домен в адресі, вмісті листи і т. д.), якщо специфічних правил не виявлено , то перевіряється, чи є поштовий домен локальним для сервера (тобто чи є сервер кінцевим одержувачем листа). Якщо є, то лист приймається в обробку. Якщо ж домен листи не є локальним, то застосовується процедура маршрутизації пошти (що є основою для передачі листів між різними серверами в Інтернеті).

При маршрутизації використовується тільки доменна частина адреси одержувача (тобто частина, що знаходиться після символу @). Для домену одержувача шукаються всі MX-записи. Вони сортуються в порядку зменшення пріоритету. Якщо адресу поштового сервера збігається з одним з вузлів, зазначених у MX-записи, то всі записи з пріоритетом меншим пріоритету вузла в MX-записи (а так само MX-запис самого вузла) відкидаються, а доставка здійснюється на перший відповідальний вузол (вузли пробуються у порядку зменшення пріоритету). Якщо MX-запис для домену не знайдено, то деякі сервери можуть намагатися доставляти пошту по A-записи. Якщо ж записи про домен ні, то формується відлупцював (повідомлення про неможливість доставки). Це повідомлення формується з порожнім полем відправника, в полі "Кому" вказується відправник вихідного листа. Пусте поле «Кому» дозволяє захистити поштові сервера від нескінченного ходіння повідомлень про помилку між серверами - якщо сервер виявляє, що не може доставити лист з порожнім зворотною адресою, то він знищує його.

Якщо мережа має різні DNS-сервери (наприклад, зовнішні - в Інтернеті, і локальні - у власних межах), то можлива ситуація, коли «внутрішні» DNS-сервери як найбільш пріоритетного одержувача вказують на недоступний в Інтернеті сервер, куди і перенаправляється пошта з релея, вказаного як вузол-одержувач для Інтернету. Такий поділ дозволяє здійснювати маршрутизацію пошти за загальними правилами між серверами, що не мають виходу в Інтернет.

Цей розділ не завершений. Ви допоможете проекту, виправивши або дописавши його.

Протоколи доступу до серверів

Після потрапляння пошти на кінцевий сервер, він здійснює тимчасове або постійне зберігання прийнятої пошти. Існує дві різні моделі роботи з поштою: концепція поштової скриньки і сховища пошти. У концепції поштової скриньки пошта на сервері зберігається тимчасово, в обмеженому обсязі (аналогічно поштової скриньки для паперової пошти), а користувач періодично звертається до ящика і «забирає» листа (тобто поштовий клієнт завантажує копію листа до себе і видаляє оригінал з поштової скриньки). На підставі цієї концепції діє протокол POP3.

Концепція постійного зберігання на увазі, що вся кореспонденція, пов'язана з поштовою скринькою (включаючи копії відправлених листів) зберігається на сервері, а користувач звертається до сховища (іноді його за традицією так само називають «поштовою скринькою») для перегляду кореспонденції (як нової, так і архіву) і написання нових листів (включаючи відповіді на інші листи). На цьому принципі діє протокол IMAP і більшість веб-інтерфейсів безкоштовних поштових служб. Подібне зберігання поштового листування вимагає значно більших потужностей від поштових серверів, в результаті, в багатьох випадках відбувається поділ між поштовими серверами, які переказують пошту, і серверами зберігання листів.

У певних умовах сервер зберігання листів може бути налаштований на поведінку, подібне клієнту: такий сервер звертається до поштового сервера по протоколу POP3 і забирає пошту собі. Подібні рішення використовуються зазвичай в малих організаціях, в яких немає інфраструктури для розгортання повноцінних поштових серверів; в цьому випадку використовується локальний сервер для зберігання пошти та поштовий сервер провайдера, що надає послугу отримання пошти по POP3 (наприклад, за допомогою fetchmail). Основним недоліком подібного рішення є затримка в доставці (так як забирають пошту ПО звертається на сервери з деякою затримкою) - наприклад, POP3 connector з Exchange 2003 Server у складі Windows SBS не дозволяє через інтерфейс конфігурування виставити інтервал менше 15 хвилин.^[3]

Структура листа

Основна стаття: Електронний лист

Електронний лист складається з наступних частин:

• Заголовків SMTP-протоколу, отриманих сервером. Ці заголовки можуть включатися, а можуть і не включатися в тіло листа надалі, тому що можлива ситуація, коли сервер володіє більшою інформацією про лист, що міститься в самому листі. Так, наприклад, поле RCPT TO вказує одержувача листа, при цьому в самому листі одержувач може бути не вказана. Ця інформація передається за межі сервери тільки в рамках протоколу SMTP, і зміна протоколу при доставці пошти (наприклад, на вузлі-одержувача в ході внутрішньої маршрутизації) може призводити до втрати цієї інформації. У більшості випадків ця інформація не доступна кінцевого одержувача, який використовує не-SMTP протоколи (POP3, IMAP) для доступу до поштової скриньки. Для можливості контролювати працездатність системи ця інформація зазвичай зберігається в журналах поштових серверів деякий час.
• Самого листа (у термінології протоколу SMTP - 'DATA'), яке, у свою чергу, складається з наступних частин, розділених символом нового рядка:
• Заголовків листа аби бути придатним за аналогією з паперовою поштою конвертом (англ. envelope). У заголовку вказується службова інформація та позначки поштових серверів, через які пройшли лист, позначки про пріоритет, вказівка на адресу та ім'я відправника та одержувача листа, тема листа та інша інформація. З терміном "конверт" є певна плутанина, тому що в залежності від ситуації "конвертом" називають або заголовок листа, яку інформацію, якою володіє SMTP-сервер після одержання листа (так, наприклад, в документації до поштового сервера postfix, термін "конверт" використовується відносно SMTP-даних, що включають не тільки поля RCPT TO і MAIL FROM, але і IP-адреса відправника, його рядок HELO і т.д.)
• Тіла листи. У тілі листа знаходиться, власне, текст листа. Відповідно до стандарту, в тілі листа можуть перебувати лише символи ASCII. Тому при використанні національних кодувань або різних форм представлення інформації (HTML, RTF, бінарні файли) текст листа повинен кодуватися за стандартом MIME і не може бути прочитаний людиною без використання декодера чи поштового клієнта з таким декодером.

Заголовок SMTP

Заголовок SMTP містить в собі наступну інформацію:

• ім'я відправляє вузла (не ім'я відправника, а ім'я сервера або комп'ютера користувача, який звернувся до сервера) - параметр повідомлення HELO / EHLO, Звичайно доповнюються «об'єктивної» інформацією самим сервером (HELO може містити довільне ім'я, а IP відправника підробити істотно складніше), за IP-адресою здійснюється пошук PTR-записи в DNS, все це разом дозволяє ідентифікувати відправника на мережевому рівні (і в реальності часто використовується для перевірки надійності відправника за допомогою чорних / білих списків , у тому числі через інтернет - см RBL).
• Поле MAIL FROM:, Що містить адресу відправника. Адреса може бути довільним (в тому числі з неіснуючих доменів, однак ця адреса може так само перевірятися при первинній перевірці на спам).
• Поле RCPT TO:- Найбільш важливе поле для доставки пошти, містить електронну адресу одержувача. Більшість поштових систем у разі можливості перевіряє, чи існує користувач і може відмовитися приймати пошту, якщо користувач, зазначений у RCPT TO не існує.

Заголовок листа

Заголовок листа описується стандартами RFC:

• RFC 2076- Common Internet Message Headers (загальноприйняті стандарти заголовків повідомлень), Містить у собі інформацію з інших RFC: RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864, RFC 1911).
• RFC 4021- Registration of Mail and MIME Header Fields (реєстрація пошти і поля заголовків MIME).

Заголовок відділяється від тіла листа нового рядка. Заголовок використовується для журналювання проходження листа і службових позначок (іноді рядка журналювання і позначки називаються кладжамі). У Microsoft Outlook цей заголовок називається «Заголовки Інтернет» (мається на увазі, що кожен рядок - окремий заголовок). У заголовку звичайно вказуються: поштові сервери, через які пройшли лист (кожен поштовий сервер додає інформацію про те, від кого він отримав цей лист), інформацію про те, схоже це лист на спам, інформацію про перевірку антивірусами, рівень терміновості листа (може мінятися поштовими серверами). Так само в заголовку зазвичай пишеться програма, за допомогою якої було створено лист. Найчастіше поштові клієнти приховують заголовки від користувача при звичайному використанні поштовою системою, але надають можливість побачити заголовки, якщо виникає потреба в більш детальному аналізі листи. У випадку, якщо лист з SMTP формату конвертується в інший формат (наприклад, в Microsoft Exchange 2007 листа конвертуються з SMTP-формату в MAPI), то заголовки зберігаються окремо, для можливості діагностики.

Заголовки зазвичай додаються знизу вгору (тобто кожен раз, коли до повідомлення потрібно додати заголовок, він дописується першим рядком, перед всіма попередніми).

Крім службової інформації, заголовки листа так само зберігають і будуть показані користувачеві інформацію, це звичайно відправник листа, одержувач, тема та дата відправлення.

Часто використовувані поля

Основна стаття: Заголовки листа

• Return-Path (RFC 821, RFC 1123) - Зворотну адресу. Може відрізнятися від MAIL FROM (тобто зворотну адресу може бути вказаний відмінним від адреси відправника).
• Received (RFC 822, RFC 1123) - Рядок журналювання проходження листа. Кожен поштовий сервер (MTA) позначає процес обробки цим повідомленням. Якщо повідомлення проходить через декілька поштових серверів (звичайна ситуація), то нові повідомлення дописуються над попередніми (і журнал переміщення читається у зворотному порядку, від найближчого вузла до самому далекому).
• MIME-Version (RFC 1521) - Версія MIME, З яким це повідомлення створено. Оскільки повідомлення створюється раніше всіх інших подій з листом, то цей заголовок звичайно самий перший (тобто останній у списку).
• From: (RFC 822, RFC 1123, RFC 1036) - Назва та адреса відправника (саме в цьому заголовку з'являється текстове поле з ім'ям відправника). Може не збігатися з return-path і навіть не збігатися із заголовком SMTP MAIL FROM:.
• Sender: (RFC 822, RFC 1123) - Відправник листа. Додано для можливості вказати, що лист від чийогось імені (from) відправлено іншого персоною (наприклад, секретаркою від імені начальника). Деякі поштові клієнти показують повідомлення при наявності sender і from як «повідомлення від 'sender' від імені 'from'». Sender є інформаційним заголовком (і так само може відрізнятися від заголовка SMTP MAIL FROM).
• To: (RFC 822, RFC 1123) - Ім'я та адреса одержувача. Може мати декілька разів (якщо лист адресовано декільком одержувачам). Може не співпадати з полем SMTP RCPT TO.
• cc: (RFC 822, RFC 1123) - (Від англ. carbon copy). Містить імена та адреси вторинних одержувачів листа, до яких направляється копія.
• bcc: (RFC 822, RFC 1123) - (Від англ. blind carbon copy). Містить імена та адреси одержувачів листа, чиї адреси не слід показувати іншим адресатам. Це поле зазвичай обробляється поштовим сервером (і призводить до появи декількох різних повідомлень, у яких bcc містить тільки того одержувача, кому фактично адресований лист). Кожен з одержувачів не буде бачити в цьому полі інших одержувачів з поля bcc.
• Reply-To: (RFC 822, RFC 1036) - Ім'я та адреса, куди слід адресувати відповіді на цей лист. Якщо, наприклад, лист розсилається ботом, то як Reply-To буде вказана адреса персони, готовою прийняти відповідь на лист.
• Message-ID: (RFC 822, RFC 1036) - Унікальний ідентифікатор повідомлення. Складається з адреси вузла-відправника та номери (унікального в межах вузла). Алгоритм створення унікального номера залежить від сервера / клієнта. Виглядає приблизно так: AAB77AA2175ADD4BACECE2A49988705C0C93BB7B4A@example.com. Разом з іншими ідентифікаторами використовується для пошуку проходження конкретного повідомлення по журналах поштової системи (поштові системи фіксують проходження листа за його Message-ID) І для вказівки на лист з інших листів (використовується для групування та побудови ланцюжків листів). Звичайно створюється перший поштовим сервером (MTA) в момент прийняття пошти від користувача.
• In-Reply-To: (RFC 822) - Вказує на Message-ID, Для якого цей лист є відповіддю (за допомогою цього поштові клієнти можуть легко вибудовувати ланцюжок листування - кожен новий відповідь містить Message-ID для попереднього повідомлення).
• Subject: (RFC 822, RFC 1036) - Тема листа.
• Date: (RFC 822, RFC 1123, RFC 1036) - Дата написання листа.
• Content-Type: (RFC 1049, RFC 1123, RFC 1521, RFC 1766) - Тип вмісту листа. За допомогою цього поля вказується тип (HTML, RTF, Plain text) вмісту листа та кодування, в якій створено лист (см нижче про кодування).

Крім стандартних, поштові клієнти, сервери та роботи обробки пошти можуть додавати свої власні заголовки, що починаються з «X-» (наприклад, X-Mailer, X-MyServer-Note-OK або X-Spamassasin-Level).

Тіло листа

Тіло листа відділяється від заголовка порожнім рядком, а закінчується (відповідно до стандартів SMTP) Рядком, що складається з єдиної точки (або символ перекладу рядка). Частина поштових клієнтів (наприклад, Thunderbird) Показують цю точку, частина ні. У не-smtp стандартах формат листа залежить від стандарту системи (наприклад, MAPI), Але перед «виходом» листи за межі MAPI-сумісної системи (наприклад, перед пересиланням через Інтернет) зазвичай приводиться до SMTP-сумісного увазі (інакше маршрутизація листа була б неможливою, тому що стандартом передачі пошти в Інтернеті є SMTP).

Одним з істотних обмежень стандартів на поштову пересилку є застосування 7-бітної кодування (ASCII). Для англійського тексту це не представляє особливої проблеми, однак, більшість неангломовних мов використовують 8 (і більше) бітні кодування, передача яких без спотворень не гарантується. Для цілей сумісності, все не 7-бітні кодування наводяться в 7-бітний вигляд (використовуючи різні методи кодування тексту).^{[уточнити]}

Ланцюжки листів

Завдяки наявності в листі унікального ідентифікатора, а також того, що переважна більшість поштових клієнтів при відповіді на лист копіюють його ідентифікатор у полі In-Reply-To ( «У відповідь на"), з'являється можливість достовірної угрупування листів по ланцюжку (англ. thread). В різних поштових клієнтах це реалізовано по різному, наприклад, Microsoft Outlook можна знайти будь-які пов'язані із заданим листа; веб-інтерфейс GMail групує повідомлення на підставі даних про ланцюжок в єдиний об'єкт. Деякі поштові клієнти (наприклад, mutt) Дозволяють структурувати ланцюжка (утворюються зазвичай в поштових розсилках, коли в розмові бере участь багато передплатників) у формі дерева (питання породив кілька відповідей, на кожен з яких дали коментар - це сформувало декілька гілок дерева). Так само такі клієнти зазвичай вміють примусово різати ланцюжка при зміні теми повідомлення (вважаючи, що зміна теми повідомлення означає нове обговорення, хоча, можливо, і викликана попередньою бесідою).

Поштові розсилки

Основна стаття: Розсилки електронної пошти

Поштова система дозволяє організувати складні системи, засновані на пересилання пошти від одного до багатьох абонентам, це:

• Поштові розсилки - лист від одного адреси з однаковим (або змінним за шаблоном) вмістом, що розсилаються передплатникам розсилки. Технічно може бути організовано як відправка безлічі листів (використовується при шаблонних листах) або як відправка листа з безліччю одержувачів (у полях TO, CC, BCC). Для управління великими поштовими розсилками (більше 10-50 абонентів) використовуються спеціалізовані програми (наприклад, mailman). Правильно організована поштова розсилка повинна контролювати повернення листів (повідомлення про неможливість доставити лист) з виключенням недоступних адресатів зі списку розсилки, дозволяти передплатникам відписуватись від розсилок. Небажані поштові розсилки називаються спамом й істотно ускладнюють функціонування поштових систем.
• Групи листування - спеціалізований тип поштової розсилки, в якій лист на пошта групи (звичайну поштову адресу, обробкою пошти якого займається спеціалізована програма) розсилається всім учасникам групи. Є аналогом новинних конференцій, ехоконференцій. Правильно налаштована поштова розсилка повинна контролювати цикли (два робота розсилок, підписані один на одного здатні створити нескінченний цикл пересилання листів), обмежувати список учасників розсилки, що мають право на приміщення повідомлення, виконувати інші вимоги до поштовій розсилці.

Для управління поштовими розсилками використовуються менеджери поштових розсилок. Крім ведення списку адрес і виконання відсилання заданого повідомлення вони забезпечують фільтрацію листів, можливості премодерації листів перед приміщенням до розсилки, ведення архівів, управління підпискою / відпискою, розсилку збірок (стислого вмісту) замість всього обсягу розсилки.

Приклади програм управління розсилками:

• mailman<