Електронско писмо

**Електронска пошта**, попозната како ** е-пошта** или ** e-mail**, е метод за размена на дигитални пораки од авторот до еден или повеќе примачи. Модерниот е-мејл работи низ интернет или други компјутерски мрежи. Некои рани системи за електронска пошта барале и авторот и примателот да се онлајн во исто време, слично како со инстант пораки. Системи за електронска пошта денес се врз основа на зачувај и препрати моделот. опслужувачи за е-пошта прифаќаат, препраќаат, доставуваат и чуваат пораки. Ниту за корисниците, ниту за нивните компјутери е потребно да бидат онлајн истовремено, тие треба поврзат само за кратко, обично на опслужувач за електронска пошта, колку што е потребно за да праќаат и примаат пораки.

Е-пошта порака се состои од три компоненти,*[[плик]]от* на пораката, *насловот* на пораката и *тело* на пораката. Насловот на пораката содржи контрола на информации, вклучувајќи ги, најмалку, авторот на електронска пошта и една или повеќе адреси на примачот. Обично исто така се додаваат описни информации како што е насловот во полето за предмет и печат за датум / време на праќање на пораката.

Првично е само текстуален (7-битни ASCII и други)  комуникациски медиум, а сега е-мејлот е проширен и може да се прикачуваат додатоци со мулти-медиална содржина, процес стандардизиран во RFC 2045 преку 2049. Колективно, овие RFC се наречени мултинаменски е-поштенски домени (MIME).

Електронска пошта претходи на почетокот на интернет, и е всушност клучна алатка во создавањето на истиот, но историјата на модерни, глобални интернет-мејл услуги достигнува до почетокот на ARPANET. Стандарди за кодирање на e-mail пораки беа предложени уште во 1973 (RFC 561). Претворање од ARPANET на интернет во раните 1980-ти го произведе јадрото на тековните услуги. Е-пошта испратен во раните 1970-ти изгледа доста сличен на основнаата текст порака испратена на интернет денес.

Електронски писма засновани на мрежа првично беа разменувани на ARPANET во екстензии на протокол за пренос на податотеки (FTP), но сега тоа е извршено од страна на Протокол за пренос на едноставна пошта (SMTP), првпат објавен на интернет стандард 10 (RFC 821) во 1982 година. Во процесот на транспорт на е-мејл пораки помеѓу системите, SMTP комуницира со испорака на параметри користејќи го *пликот* на пораката одвоено од пораката и (заглавјето и телото) за себе.

## Правопис
Електронската пошта, има неколку опции за англиски правопис кои повремено се покажуваат како причина за несогласување.

**Е пошта* е во форма побарана од страна на IETF Барања за коментар и работни групи и повеќе е водено од аспект на стил. Овој правопис исто така се појавува во повеќето речници.
**E-mail* е форма претходно препорачана од некои истакнати новинарски и технички водичи за стил. Според корпусот на современиот американско англиски јазик на податоци, оваа форма се појавува најчесто изменето, објави американско-англиското пишување. 
**Пошта* е форма која се користи во оригиналниот RFC. Услугата е наведена како *пошта* и едно парче на електронска пошта се нарекува *порака*.

## Потекло
### Пренасочувања
Испраќање на текстуални пораки по електронски пат може да се каже дека датира од Morse code телеграф од средината на 1800-тите; На светскиот саем 1939  во Њујорк, каде IBM испрати писмо со честитки од Сан Франциско до Њујорк на IBM радио-тип, нарекувајќи со набрзо замена за mail сервисот во светот на утрешнината. Телепринтери се користени во Германија за време на Втората светска војна и употребата се шири до крајот на 1960-тите години кога била претставена Телекс мрежа. Покрај тоа, имало слични, но некомпатибилен американски TWX, кој остана во употреба до крајот на 1980-тите.

### Хост-засновани системи за пошта
Со воведувањето на Систем за компатибилно споделување (CTSS) во 1961 година од страна на МИТ за првпат повеќе корисници беа во можност да влезат во централниот систем од далечински dial-up терминали, за чување и споделување додадени фајлови на централниот диск..

Неслужбени начини на користење на ова е да поминат пораки и да се прошири за да се создаде првиот вистински е-пошта:
* Систем за компатибилно споделување (CTSS) од МИТ, во 1965 година 

Други рани системи за споделување имаа свои е поштенски апликации:
* 1972 - Unix пошта програмата 
* 1972 - APL поштенското сандаче од раса Лари
* 1981 - ресор од страна на IBM
* 1982 - All-In-1] од Digital Equipment Corporation

Иако имаат сличен концепт, сите овие оригинални системи за електронска пошта се со многу различни одлики и излегоа некомпатибилни системи. Тие дозволија комуникација само помеѓу корисниците најавени во ист хост или "супер" - иако ова може да биде стотици или дури и илјадници корисници во рамките на една организација.

### Е-поштенски мрежи
Наскоро беа развиени системи за поврзување на програми за компатибилна пошта помеѓу различни организации преку дајл-ап модеми или изнајмени линии, создавање на локални и глобални мрежи.

* Во 1971 година, првиот ARPANET e-mail бил испратен, и преку 561 RFC, RFC 680, RFC 724 и конечно 1977 е RFC 733, стана стандардизиран систем за работа.

Други одделни мрежи беа исто така создавани и тоа:
* Unix пошта е вмрежена од 1978 UUCP,
* IBM супер-мејл е поврзана со BITNET во 1981 година
* IBM кој работи во ДОС во 1984 година може да се поврзе со fidonet за е-мејл и објавување на заедничка огласна табла

### LAN системи за електронска пошта
Во раните 1980-ти, мрежни лични сметачи на LAN станаа многу значајни. опслужувач-засновани системи слични на претходните супер системи беа развиени. Повторно овие системи првично дозволено комуникација само помеѓу корисниците најавени во истата опслужувачка инфраструктура. Примерите вклучуваат:
* 
* Lantastic
* WordPerfect Office
* Microsoft Mail
* Banyan VINES
* Lotus Notes

Конечно овие системи исто така, може да се поврзат меѓу различни организации, додека тие, користат ист е-мејл систем и комерцијален протокол.

### Обиди за интероперабилност
Почетокот на интероперабилност меѓу независни системи вклучува:

* ARPANET, претходник на интернет денес, дефинирани првите протоколи за различни компјутери за размена на e-mail
* UUCP имплементација на не-Unix системи беа користени како отворено „лепило“ меѓу различни поштенски системи, првенствено преку дајл-ап телефони
* CSNet се користи dial-up пристап до телефонски линк дополнителни на сајтови на ARPANET и потоа Интернет

Подоцнежните напори за интероперабилност на стандардизација вклучуваат:
* Novell накратко се залагале за отворено MHS протокол, но го напуштен по купување на не-MHS WordPerfect Office (преименуван во GroupWise)
* На обоени протоколи на книга на Обединетото Кралство за академските мрежи до 1992 година
* X.400 во 1980-тите и раните 1990-ти бил промовиран од страна на големите производители и го употребувала Владата под GOSIP, но е напуштен од сите во корист на интернет SMTP до средината на 1990-тите години.

### Од SNDMSG до MSG
Во раните 1970-ти, Реј Томлинсон ја обновi постоечкаta алатка наречена SNDMSG, така што тоа би можело да се направи копија од пораки (како фајлови) преку мрежата. Лоренс Робертс, менаџерот на проектот за развој на ARPANET, ја зеде идејата за READMAIL, кога биле фрлени "последните" пораки кон терминалот на корисникот, и напишал програмата за TENEX во Teco макроа наречени RD кои му овозможија пристап до поединечни пораки. Barry Wessler then updated RD and called it NRD.

Марти Yonke комбинирано ги пренапиша NRD за да го вклучи читањето, пристап до SNDMSG за испраќање, и систем за помош, и да повика на нови WRD која подоцна биле познати како BANANARD. Џон Vittal тогаш ја има обновено оваа верзија за да вклучи 3 важни команди:*Поместување* (во комбинација спаси / избриши команда), *Одговор* (утврдува кој одговор треба да биде испратен) *напред* (Испрати е-пошта на лице кое не е веќе примател). Системот е наречен MSG. Со вклучување на овие одлики, MSG се смета за првата интегрирна модерна e-mail програма, од кои многу други апликации се спуштаа.

### Подемот на ARPANET пошта
ARPAnet компјутерска мрежа направи голем придонес во развојот на е-мејл. Постои еден извештај кој покажува експерименти меѓу систем-мејл трансфери кој почна кратко време по неговото формирање во 1969 година. Реј Томлинсон обично е заслужен што е испратен прв мејл преку мрежа, започнување на користење на "@" знак за поделба на имињата на корисникот и машината на корисникот во 1971 година, кога испрати порака од еден Digital Equipment Corporation декември-10 компјутер на друг Dec-10. Двете машини се сместени еден до друг. Работата на Томлинсон била брзо усвоена низ ARPANET, со што значително се зголеми популарноста на е-мејл. За многу години, е-мејл е Killer App на ARPANET, а потоа на интернет.

Повеќето други мрежи имаа свои e-mail протоколи и формати на адреси, како влијание на ARPANET, а подоцна и на интернет се зголеми, централна сајтови често беа домаќини на е-мејл портали кои ја положиле поштата меѓу интернет и другите мрежи. Интернет e-mail адресирање сè уште е комплицирана од потребата да се справи поштата наменета за овие постари мрежи. Некои добро познати примери од нив биле UUCP (најчесто Unix компјутери), BITNET (најчесто IBM и VAX главно на универзитетите), fidonet (лични сметачи), DECnet  (различни мрежи) и CSNET претходник на NSFNet.

Еден пример на интернет e-mail адреса која изнесе mail на корисникот во домаќин UUCP:


```
hubhost!middlehost!edgehost!user@uucpgateway.somedomain.example.com
```


Ова е потребно бидејќи во раните години UUCP компјутери не се одржуваа (и не можеле да се консултираает централните опслужувачи за) информации за локацијата на сите домаќини кои се разменија со е-пошта, туку само се знаело како да комуницира со неколку соседни мрежи, е-мејл пораки (и други податоци како што се Usenet Вести) беа донесени заедно во синџирот меѓу домаќините кои експлицитно се согласија да разменуваат податоци едни со други. (Крајот на UUCP проект за мапирање обезбеди форма на мрежа за насочување врз основа на податоци за е-мејл.)

### Заглавје на порака
Секоја порака има точно еден наслов, кои се поделени во области. Секоја област има име и вредност. RFC 5322 ја одредува точната синтакса.

Неформално, секоја линија на текст во насловот кој започнува со печатење на карактери кога започнува посебна област. Во полето Име започнува со првиот лик на линијата и завршува пред сепаратор карактерот ":". Сепаратор потоа се следи од областа вредност ("телото" на поле). Вредноста се продолжува кон следните линии ако тие линии имаат простор или јазиче како нивниот прв карактер. Областа имиња и вредности се ограничени на 7-битни ASCII карактери. Не-ASCII вредности можат да бидат претставени со MIME кодирани зборови.

#### Заглавја
Насловот на пораката мора да ги содржи најмалку следните полиња:
**Од*: во електронска пошта, и избор на името на авторот(ите). Во многу e-mail клиенти не се променливи освен преку менување на поставките на сметката.
**Датум на*: На месното време и датум кога пораката е напишана. Како на*Од:*поле, многу e-mail клиенти го пополнуваат ова автоматски кога се испраќа. Клиентот на примачот тогаш може да го прикаже времето во формат и часовен појас локално до него / неа.

Насловот на пораката треба да содржи најмалку следните области:

**Идентификатор на порака*: исто така автоматски генерирана област; се користи да се спречи повеќе испораки и за упатување во Reply-To: **Во-Одговор-До*: Идентификатор на порака на пораката дека ова е одговор на. Користи за поврзување поврзани пораки заедно. Ова поле се однесува само за одговор пораки.

RFC 3864 се опишуваат процедурите за регистрација за заглавијата на Јана, таа овозможува за постојан и привремени пораки како насловот во поле за имиња, вклучувајќи ги и областите дефинирани за MIME, netnews, и HTTP, и цитирање релевантни RFC. Заеднички насловните полиња за е-мејл вклучуваат:
**До*: е-поштенска адреса (es), и по можност име (и) на примателот на пораката е. Укажува основни корисници (повеќе е дозволено), за средни корисници види
**Предмет*: кратко резиме на темата на пораката. одредени кратенки најчесто се користат во предметот, вклучувајќи ги "RE:" и "FW :".
**Bcc*: невидлива копија; адреса додадена на испорака на SMTP листа, но не (обично), останатите во пораката на податоци, останувајќи невидлив за останатите примачи.
**Копија*: копија, многу e-mail клиенти ќе го одбележат email во вашиот inbox различно, во зависност од тоа дали се во To: или Сс: листа.
* Content-Type: информации за тоа како порака да бидат прикажани, обично MIME тип.
**Преседан*: најчесто со вредности "рефус", "ѓубре", или "листа", се користи за да укаже дека автоматски "одмор" или "надвор од канцеларија" одговори не треба да се вратат за оваа пошта, на пример, за да се спречи жизвестувања од тоа да биде испратено до сите други претплатници на mailinglist. Sendmail користи овој наслов да влијае на приоритет на дното е-пошта, со "Преседан: специјални испорака" пораки доставени порано. Со модерна високопропусниот опсег мрежи испорака приоритет е помалку од еден проблем отколку што некогаш бил. Microsoft Exchange почитува ситно-грануларен автоматски одговор, X-авто-одговор-сузбивање на заглавието.
**Наводи*: идентификатор на пораката дека ова е одговор на, и порака-ID на пораката од претходниот одговор или бил одговор на, итн
**Одговор до*: Адреса каде треба да се испратат за да одговорите на пораката.
**Испраќач*: Адреса на испраќачот кој вистински дејствува во име на авторот наведени во Од: поле (секретар, листата менаџер, итн.)
**Архивирано-Во*: Директна врска со архивираната форма на поединечна е-мејл порака.

Имајте на ум дека*до:*полето не е нужно поврзано со адреси на кои пораката е испорачана. Вистинската список на испорака е снабдена посебно на протокол за транспорт, SMTP, кој може или не првично може да се извадени од содржина во насловот. "To:" областа е слична на решавање на врвот на едно конвенционално писмо кое е дадено во согласност со адреса на надворешен плик. На ист начин, "Од:" полето не мора да биде вистински испраќачот на e-mail порака. Некои mail опслужувачи применуваат email за проверка системи за пораки кои се пренесени. Податоци кои се однесуваат на активноста на опслужувачот е исто така дел од насловот.

SMTP дефинира *трага информации* на пораката, кој исто така е зачуван во насловот со користење на следните две полиња:

**Примени*: кога SMTP опслужувачот ја прифаќа пораката што внесува трага на врвот на заглавието (последна до прва).
**Враќање*: кога испорака SMTP опслужувач прави *конечната испорака* на пораката, таа се внесува во областа на врвот на насловот.

Други заглавијата кои се додадени на врвот на насловот од страна на добивањето на опслужувачот може да се наречат *траги*, во поширока смисла на зборот.

**Резултати од автентикација*: кога опслужувачот врши проверка на проверки, може да ги зачува резултатите во оваа област за консумирање од страна на низводни агенти.
* *Received-SPF*: ги зачувува резултатите од SPF проверки.
* *Auto-Submitted*: се користи да ги означи автоматски генерираните пораки
* *VBR-Info*: побарува VBR листање

Неодамна на IETF EAI работна група има дефинирано некои експериментални екстензии за да се овозможи Уникод карактери да се користи во рамките на насловот. Конкретно, тоа им овозможува на мејл адреси да користат не-ASCII карактери. Таквите знаци треба само да се користат од страна на опслужувачи кои ги поддржуваат овие екстензии.

### Тело на пораката
#### Содржина на кодирање
Е-пошта првично била наменета за 7-битни ASCII. Многу е-мејл софтвер е 8-битно чист, но мора да се претпостави дека ќе комуницира со 7-битни опслужувачи и пошта на читателите. На MIME стандардот воведе карактер сет спецификатори и две Content Transfer кодирања за да се овозможи пренос на не-ASCII податоци: цитирање за печатење за најмногу 7 битна содржина, со неколку карактери кои се движат надвор и base64 за произволни бинарни податоци. 8BITMIME и бинарни проширувања беа воведени за да се овозможи пренос на пошта, без потреба за овие кодни табели, но многу агенти на транспорт уште не го поддржуваат целосно. Во некои земји, неколку шеми за кодирање коегзистираат, како резултат на тоа, по правило, на порака во латиничното писмо, јазикот се појавува во не-читлив облик (единствен исклучок е случајно, кога испраќачот и примачот користат иста шема на кодирање). Затоа меѓународно множество на знаци и Уникод имаат сè поголема популарност.

#### Обичен текст и HTML
Повеќето модерни графички e-mail клиенти дозволуваат употреба на било обичен текст или HTML за пораката по избор на корисникот. HTML e-mail пораки често вклучуваат автоматски генериран обичен текст примерок, како за компатибилност.

Предности на HTML ја вклучуваат способноста да се вклучат врски и слики, во текстот покрај претходните пораки на блоковите, завршува природно за секој дисплеј, користење на акцент, како што се нагласи или закосени букви , и промена на font стилови. Недостатоци вклучуваат зголемување на големината на е-пошта, стравувањата поврзани со приватноста во врска со веб бубачкаи, злоупотреба на HTML-мејл како вектор за напади и ширењето на малициозен софтвер.

Некои веб-засновани Маил листи ги препорачуваа сите мислења да се направи во обичен текст, со 72 или 80 знаци во еден ред за сите погоре наведени причини, но исто така и бидејќи имаат значаен број на читатели кои користат текст засновани е-пошта клиенти како Mutt.

Некои Microsoft e-mail клиенти овозможуваат богато форматирање со користење на RTF, но освен ако примачот е загарантирано да има компатибилен e-mail клиент ова треба да се избегнува.

## опслужувачи и клиент апликации
Пораките се разменуваат помеѓу домаќините со користење на SMTP со програми наречени агенти за трансфер на пошта (MTA); и предадена на e-mail продавница со програми наречени агент на поштенска пратка. Корисниците можат да пристапат на нивните пораки од опслужувачи со користење на стандардни протоколи, како што се POP или IMAP, или, како што е повеќе веројатно во големи корпоративни во животната средина, со комерцијален протокол специфичен за Novell GroupWise, Lotus Notes или Microsoft Exchange Server Webmail интерфејси кои им овозможуваат на корисниците да имаат пристап до своите пораки со било кој стандарден прелистувач, од било кој компјутер, наместо да се потпираат на е-пошта клиент. Програми што се користат од страна на корисниците за прибирањето, читање, и управување со електронска пошта се нарекува прелистувач на пошта.

Пошта може да се чува кај клиентот, од страна на опслужувачот, или на двете места. Стандардни формати за поштенски сандачиња вклучуваат Maildir и mbox. Неколку истакнати e-mail клиенти ги користат нивните сопствени формати и бараат софтвер за претворање за пренос на е-пошта меѓу нив. Од страна на опслужувачот за складирање често е во неслободен формат, но од пристап е преку стандарден протокол како што се IMAP, движејќи мејл од еден опслужувач на друг може да се направи со било кој MUA протокол за поддршка.

Прифаќањето на пораки ја обврзува МТА да ги достави, и кога пораката не може да биде донесена, дека МТА мора да испрати отскокнување на порака назад до испраќачот, укажувајќи на проблемот.

### Екстензии за име
По приемот на е-мејл пораки, e-mail клиент апликации ги зачувуваат пораките во податотеки во датотечниот систем на оперативниот систем. Некои клиенти снимаат поединечни пораки како посебни податотеки, додека други користат различни форми на бази на податоци, често комерцијални, за колективно складирање. А историски стандард на складирање е *[[mbox]]* формат. Специфичните формати кои се користат често се означени со посебна екстензија:eml

:. Користен од страна на многу e-mail клиенти, вклучувајќи Microsoft Outlook Express, Windows Mail и Mozilla Thunderbird; Податотеките се обичен текст во MIME формат, го содржат e-mail насловот, како и содржината на пораката и прилози во една или повеќе од неколку формати. 
;emlx
:Користено од Apple Mail.
;msg
:Користено од Microsoft Office Outlook и OfficeLogic Groupware.
;mbx
:Користено од Opera Mail, KMail и Apple Mail засновано на mbox формат.

Некои апликации (како Apple пошта) оставаат додатоци кодирани во пораките за пребарување, а исто така заштедуваат на одделни примероци на додатоци. Други посебни прилози од пораки за да ги зачувате во одреден директориум.

### URI шема ''mailto:''
URI шема, како регистрирана во Јана, го дефинира mailto: шема за SMTP е-мејл адреси. Иако неговата употреба не е строго дефинирана, адресите на оваа форма се наменети да се користат да се отвори нов прозорец на mail клиент на корисникот кога URL е активиран, со адреса како што е дефинирано од страна на URL во*до:*област.

## Употреба
### Во општеството
Постојат бројни начини на кои луѓето го сменија начинот на кој тие комуницираат во последните 50 години; е-пошта е сигурно една од нив. Традиционално, социјална интеракција во локалната заедница била основа за комуникација - лице во лице. Сепак, денес лице-в-лице состаноци не се примарен начин да се комуницира, може да се користат фиксен телефон, мобилен телефон и факс услуги, или било кој од бројните можности за комуникации со посредство на компјутер како е-мејл.

#### Избувнување
Избувнување се случува кога едно лице праќа порака со лута или антагонистичка содржина. Поимот е изведен од употребата на зборот запаливо да се опише особено жестокост на Е-дискусии. Избувнување се претпоставува дека е почесто денес поради леснотијата и безличност на комуникации преку е-пошта: конфронтации лично или преку телефон бараат директна интеракција, каде што општествените норми охрабруваат на учтивост, а внесување на пораката на друго лице е индиректна интеракција, па учтивоста може да биде заборавена. Избувливоста обично се гледа со презир на страна на интернет заедници со што се смета за грубо и непродуктивни.

#### Е-пошта стечај
Исто така познат како "е-мејл замор", е-пошта стечај е кога корисникот го игнорираат голем број на е-мејл пораки по заостанувањето за читање и одговарање на нив. Причината за заостанувањето најчесто се должи на преоптоварување со информации и општа смисла има толку многу информации дека не е можно да се прочита сето тоа. Како решение, луѓе повремено праќаат порака објаснувајќи дека е-пошта сандаче е расчистено. Професор по право на Харвард, Лоренс Лесиг е заслужен за создавањето на овој термин, но тој само може да го популаризира.

### Во бизнисот
Е-мејл е широко прифатен од страна на деловната заедница како прв широк електронски комуникациски медиум и е првата "е-револуција" во бизнис комуникацијата. Е-пошта е многу едноставна да се разбере како пошта, е-мејл решава два основни проблеми на комуникација: логистика и синхронизација.

LAN заснован е-пошта е нова форма на користење за бизнис. Тоа не само што им овозможува на бизнис корисниците да ја преземат поштата кога е *присутна*, исто така им овозможува на мали бизнис корисници да има мејл ИД повеќе корисници со само една е-пошта *врска*.

#### За
**Проблемот на логистиката*: Голем дел од светот на бизнисот се потпира на комуникација помеѓу луѓе кои не се физички во иста зграда, површина, па дури и земјата; поставување и присутните во-лице состанок, телефонски повик или конференциски повик може да биде неповолно, одземаат многу време и се скапи. Е-пошта обезбедува начин за размена на информации помеѓу двајца или повеќе луѓе без поставување на трошоците, а тоа е генерално многу помалку скапо од физичките собири и состаноци или телефонски повици.
**Проблемот на синхронизација*: во реално време комуникација со состаноци или телефонски повици, учесниците треба да работат на ист распоред, и секој учесник мора да помине иста количина на време на состанок или повик. Е-пошта им овозможува на асинхронизација: секој учесник може да го контролира својот распоред независно.

#### Против
Повеќето од денешните бизнис работници поминуваат од еден до два часа од нивниот работен ден на е-пошта: читање, нарачување, сортирање, "повторно контекстуализирање" фрагментирани информации и пишување е-пошта. Употребата на е-пошта е зголемено како резултат на зголемување на нивото на глобализацијата на поделба на труд и outsourcing меѓу другото. Е-пошта може да доведе до некои добро познати проблеми:

**Загуба од контекст*: што значи дека контекстот е изгубен засекогаш; не постои начин да се добие текстот назад. Информации во контекст (како и во весникот) е многу полесно и побрзо да се разберат од неиздаден, а понекогаш и не се поврзани во фрагменти од информации. Комуникација во контекст може да се постигне кога двете страни имаат целосно разбирање на контекстот и прашање во прашање.
**Информации за преоптоварување*: пошта е притисна технологија - испраќачот контролира кој добива информации. Практична достапност на мејлинг листата и употреба на "копија на сите" може да доведе до луѓето да добиваат несакани или нерелевантни информации од корист за нив.
**Недоследност*: со е-пошта може да се дуплираат информации. Ова може да биде проблем кога голем тим работи на документи и информации додека не е во постојан контакт со другите членови на нивниот тим.
**Одговорност*. Изјавите дадени во е-пошта може да се сметаат за законски обврзувачки и се користат против лица во судот.

## Проблеми
### Ограничување на големината на прилогот
E-пошта пораки може да имаат еден или повеќе додатоци. Прилозите може да послужат за целите на обезбедување на бинарни или текстуални податотеки со неодредена големина. Во принцип не постои техника за внатрешно ограничување во протоколот SMTP на големина или број на додатоци. Во пракса, сепак, е-мејл услуги спроведувани на разни ограничувања на дозволена големина на податотеки или големината на целата порака.

Исто така, поради технички причини, често мала приврзаност може да го зголеми во големина кога ќе се испрати кои можат да бидат збунувачки за испраќачите кога се обидуваат да проценат дали тие можат да или не можат да испратат податотека по е-пошта, и ова може да резултира пораката да биде одбиена.

Како поголеми и поголеми податотеки по големина се создаваат и се тргува со нив, многу корисници се или принудени да ги испратат и преземат нивните податотеки со користење на FTP опслужувач, или повеќе популарно, користат онлајн споделување на податотеки објекти или услуги, обично веб-пријателски HTTP, со цел да праќаат и примаат.

### Преоптоварување со информации
Декември 2007 година Њујорк Тајмс во блог пост има опишано информации за преоптоварување како "$ 650 милијарди повлекување врз економијата", и Њујорк тајмс во април 2008 година дека "e-mail стана отров на некои професионални животи на луѓето" што се должи на преоптоварување со информации, но "Никој од сегашниот бран од висок профил интернет start-ups, не се фокусирале на e-mail дека навистина елиминира проблеми на е-мејл преоптоварување, бидејќи никој не ни помага да се подготват одговори ".

Во октомври 2010 година, Си-Ен-Ен објави напис под наслов "Среќен ден на преоптоварување со информации", кој ги состави од истражување на е-мејл преоптоварување од ИТ компании и продуктивни експерти. Според Basex, просечниот работник добива 93 пораки на ден. По студиите се изјасниле поголем број.

### Спам и компјутерски вируси
Корисноста на е-пошта е под закана од четири причини: email бомба, спамирање, phishing, и e-mail црви.

Спам е несакан комерцијален е-пошта. Поради малата цена на испраќање на е-пошта, спамери можат да испраќаат стотици милиони е-мејл пораки секој ден во текот евтина интернет-врска. Стотици активни спамери испраќаат резултати за преоптоварување со информации за многу компјутерски корисници кои примаат обемни несакани електронски пораки секој ден.

Е-пошта црви го користат е-поштаот како начин на реплицирање на себеси во ранливи компјутери. Иако од првиот мејл црв биле погодени UNIX компјутери, проблемот е најчест денес на повеќе популарните Microsoft Windows оперативни системи.

Комбинацијата на спам и црв програми како резултати кај корисници дава постојана несакана електронска пошта, со што се намалува корисноста на е-поштата како практична алатка.

Голем број на анти-спам техники го ублажуваат влијанието на спам. Во САД, САД Конгресот, исто така е донесен закон, SPAM Act од 2003 година, во обид да се регулира е-мејл. Австралија, исто така, има многу строги закони за спам ограничување на испраќање на спам од австралиски семрежни услужници,, но неговото влијание е минимално бидејќи најчесто спам доаѓа од режими кои се чини дека не сакаат да го регулираат испраќањето на спам.

### E-пошта измама
Е-пошта измама се случува кога технички податоци на е-пошта се променет за да се направи порака да се чини дека доаѓа од познат или доверлив извор. Тоа често се користи како обид да се собираат лични информации.

### E-mail бомбардирањето
Email бомба е намерно испраќање на големи количини на пораки на истљ целна адреса. Преоптоварување на целната е-поштенска адреса може да ја направи неупотреблива, па дури и може да предизвика опслужувач за пошта да има несреќа.

### Загриженост околу приватноста
Денес може да биде важно да се направи разлика помеѓу Интернет и внатрешните системи за електронска пошта. Интернет-мејл може да патува и да се чува на мрежи и компјутери без испраќачот или примачот да има контрола. Во текот на транзитот можно е дека трети страни ќе прочитаат или дури и ја менуваат содржината. Внатрешната пошта во системите, во кои никогаш не останува е организациона мрежа, може да биде побезбедна, иако персоналот на информатичката технологија и други чија функција може да се вклучи како мониторинг или управување, може да се пристапуваат со внесување на другите вработени.

Приватноста по е-пошта без некои безбедносни мерки на претпазливост, може да биде компромитирана поради фактот дека:
* E-mail пораки обично не се енкриптирани.
* E-mail пораки мора да одат преку средни компјутери, пред да стигнат до нивното одредиште, што значи дека е релативно лесно за другите да интервенираат и да читаат пораки.
* Многу Интернет Услужници (ISP) имаат копии на е-мејл пораки на нивните поштенски опслужувачи пред да се предадат. Бекап на овие може да остане до неколку месеци на нивните опслужувачи, и покрај бришење од поштенското сандаче.
* На "доби"-полиња и други информации во е-пошта често може да се идентификува испраќачот, спречување на анонимна комуникација.

Постојат криптографски апликации кои може да послужат како лек за една или повеќе од горенаведените. На пример, Виртуелна приватна мрежа и или Tor анонимна мрежа може да се користи за криптирање на сообраќај од страна на корисничката машина за побезбедна мрежа, додека ГПГ , PGP, SMEmail, или S / MIME може да се користи за крај-до-крај шифрирање, и SMTP STARTTLS или SMTP во транспорт Layer Security / Secure Sockets Layer може да се користи за да се криптираат комуникации за пошта помеѓу клиентот SMTP и SMTP опслужувачот.

Покрај тоа, многу прелистувачи на пошта не заштитуваат најави и лозинки, правејќи ги лесни за да се интервенира од страна на напаѓачот. Шифрирана проверка на шеми како што се SASL може да го спречат ова.

Конечно, прикачените податотеки делат многу од истите опасности како оние кои се наоѓаат во peer-to-peer споделување на податотеки. Прикачените податотеки може да содржат тројанци или вируси.

### Следење на испратена пошта
Оригиналниот SMTP е-поштенска служба дава ограничени механизми за следење на пренесување на пораки, и за потврдување дека тоа му е доставено или прочитано. Се бара секој поштенски опслужувач да мора или да го достави до денес или да се врати известување за неуспех (отскокнување на порака), но и двете софтверски грешки и неуспеси на системот може да предизвикаат пораки да бидат изгубени. За да се поправи ова, IETF воведе известување на испорака (испорака на сметки) и распоред на известувања (враќање на приходи), но сепак, тие не се универзално распоредени во производство.

Многу семрежни услужници сега намерно оневозможуваат извештаи за неиспорака (NDRs) и сметки за испорака што се должи на активностите на спамери:
* Извештаи за испорака може да се користат за да се потврди дали адресата постои и е на располагање да биде спамирана
* Ако спамер користи фалсификувани испраќачки е-пошта адреси (email измама), тогаш невини мејл адреси, кои се користат може да бидат преплавени со NDRs од многу валидни мејл адреси на спамер. Овие NDRs тогаш претставуваат спам од семрежен услужник на невините корисници.

Постојат голем број на системи кои им овозможуваат на испраќачот да се види дали пораки се отворени. Приемникот, исто така, може да го споделите со испраќачот за да знаат дека пораките се отворени преку "Океј" копчето. А проверка за знак може да се појави на екранот на испраќачот кога на примачот "Океј" копчето е притиснато.

## Разгледај
### Терминологија за електонско писмо
* Internet fax

### Социјални прашања за електронско писмо
* Компјутерски вирус
* Шпионски програм

### Клиенти и опслужувачи
* Автентикација

### Список на мејлови
* Енкрипција

### Историја
* Telegraphy
* Lexigram

### Протоколи
* IMAP
* POP3
* SMTP

## Наводи

## Понатамошни информации
* Cemil Betanov, *Introduction to X.400*, Artech House, ISBN 0-89006-597-7.
* Marsha Egan, "Inbox Detox and The Habit of Email Excellence", Acanthus Publishing ISBN 978-0981558981
* Lawrence Hughes, *Internet e-mail Protocols, Standards and Implementation*, Artech House Publishers, ISBN 0-89006-939-5.
* Kevin Johnson, *Internet Email Protocols: A Developer's Guide*, Addison-Wesley Professional, ISBN 0-201-43288-9.
* Pete Loshin, *Essential Email Standards: RFCs and Protocols Made Practical*, John Wiley & Sons, ISBN 0-471-34597-0.
* 
* Sara Radicati, *Electronic Mail: An Introduction to the X.400 Message Handling Standards*, Mcgraw-Hill, ISBN 0-07-051104-7.
* John Rhoton, *Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP*, Elsevier, ISBN 1-55558-212-5.
* John Rhoton, *X.400 and SMTP: Battle of the E-mail Protocols*, Elsevier, ISBN 1-55558-165-X.
* David Wood, *Programming Internet Mail*, O'Reilly, ISBN 1-56592-479-7.
* Yoram M. Kalman & Sheizaf Rafaeli, Online Pauses and Silence: Chronemic Expectancy Violations in Written Computer-Mediated Communication, *Communication Research*, Vol. 38, pp.&nbsp;54–69, 2011

## Надворешни врски

* 
* IANA's list of standard header fields
* The History of Electronic Mail is a personal memoir by the implementer of an early email system

Категорија:Семрежје