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

Од Википедија — слободната енциклопедија
Прејди на: содржини, барај

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

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

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

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

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

Содржина

Правопис[уреди]

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

  • Е маил е во форма побарана од страна на IETF Барања за коментар и работни групи[4] и повеќе е водено од аспект на стил. [5][6][7] Овој правопис исто така се појавува во повеќето речници.[8][9][10][11][12][13]
  • E-mail е форма претходно препорачана од некои истакнати новинарски и технички водичи за стил. Според корпусот на современиот американско англиски јазик на податоци, оваа форма се појавува најчесто изменето, објави американско-англиското пишување.[14]
  • Пошта е форма која се користи во оригиналниот RFC. Услугата е наведена како пошта и едно парче на електронска пошта се нарекува порака.[15][16][17]

Потекло[уреди]

Пренасочувања[уреди]

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

Хост-базирани системи за пошта[уреди]

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

Неслужбени начини на користење на ова е да поминат пораки и да се прошири за да се создаде првиот вистински е-маил:

Други рани системи за споделување имаа свои е маил апликации:

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

Емаил мрежи[уреди]

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

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

Други одделни мрежи беа исто така создавани и тоа:

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

LAN системи за електронска пошта[уреди]

Во раните 1980-ти, мрежни персонални компјутери на LAN станаа многу значајни. Сервер-базирани системи слични на претходните супер системи беа развиени. Повторно овие системи првично дозволено комуникација само помеѓу корисниците најавени во истата серверска инфраструктура. Примерите вклучуваат:

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

Обиди за интероперабилност[уреди]

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

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

Подоцнежните напори за интероперабилност на стандардизација вклучуваат:

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

Од SNDMSG дo MSG[уреди]

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

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

Подемот на ARPANET пошта[уреди]

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

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

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

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

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

Заглавје на порака[уреди]

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

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

Заглавја[уреди]

Насловот на пораката мора да ги содржи најмалку следните полиња:[37]

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

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

  • Идентификатор на порака: исто така автоматски генерирана област; се користи да се спречи повеќе испораки и за упатување во 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-авто-одговор-сузбивање на заглавието.[39]
  • Референци: идентификатор на пораката дека ова е одговор на, и порака-ID на пораката од претходниот одговор или бил одговор на, итн
  • Одговор до: Адреса каде треба да се испратат за да одговорите на пораката.
  • Испраќач: Адреса на испраќачот кој вистински дејствува во име на авторот наведени во Од: поле (секретар, листата менаџер, итн.)
  • Архивирано-Во: Директна врска со архивираната форма на индивидуална е-мејл порака.[40]

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

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

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

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

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

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

Тело на пораката[уреди]

Содржина на кодирање[уреди]

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

Обичен текст и HTML[уреди]

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

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

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

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

Сервери и клиент апликации[уреди]

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

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

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

Екстензии за име[уреди]

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

. Користен од страна на многу e-mail клиенти, вклучувајќи Microsoft Outlook Express, Windows Mail и Mozilla Thunderbird;[53] Датотеките се обичен текст во 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 водо:област.[54]

Употреба[уреди]

Во општеството[уреди]

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

Избувнување[уреди]

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

Е-маил стечај[уреди]

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

Во бизнисот[уреди]

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

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

За[уреди]

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

Против[уреди]

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

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

Проблеми[уреди]

Ограничување на големината на прилогот[уреди]

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

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

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

Преоптоварување со информации[уреди]

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

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

Спам и компјутерски вируси[уреди]

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

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

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

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

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

E-маил измама[уреди]

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

E-mail бомбардирањето[уреди]

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

Загриженост околу приватноста[уреди]

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

Приватноста по е-пошта без некои безбедносни мерки на претпазливост, може да биде компромитирана поради фактот дека:

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

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

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

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

Следење на испратена пошта[уреди]

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

Многу интернет провајдери сега намерно оневозможуваат извештаи за неиспорака (NDRs) и сметки за испорака што се должи на активностите на спамери:

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

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

Разгледај[уреди]

Терминологија за електонско писмо[уреди]

Социјални прашања за електронско писмо[уреди]

Клиенти и сервери[уреди]

Листа на мејлови[уреди]

Историја[уреди]

Протоколи[уреди]

Наводи[уреди]

  1. See (Partridge 2008) for early history of email, from origins through 1991.
  2. Long, Tony (23 October 2000). „A Matter of (Wired News) Style“. Wired magazine. http://www.nettime.org/Lists-Archives/nettime-bold-0010/msg00471.html. 
  3. Readers on (Wired News) Style“. Wired magazine. 24 October 2000. http://www.wired.com/culture/lifestyle/news/2000/10/39651. 
  4. „RFC Editor Terms List“. IETF. http://www.rfc-editor.org/rfc-style-guide/terms-online.txt. 
  5. Yahoo style guide
  6. AP Stylebook editors share big changes from the American Copy Editors Society
  7. Gerri Berendzen. „AP changes e-mail to email“. „15th National Conference of the American Copy Editors Society (2011, Phoenix)“. ACES. http://www.aces2011.org/sessions/18/the-ap-stylebook-editors-visit-aces-2011/. конс. 23 март 2011. 
  8. AskOxford Language Query team. „What is the correct way to spell 'e' words such as 'email', 'ecommerce', 'egovernment'?“. „FAQ“. Oxford University Press. http://www.askoxford.com/asktheexperts/faq/aboutspelling/email. конс. 4 септември 2009. „We recommend email, as this is now by far the most common form“ 
  9. Reference.com
  10. Random House Unabridged Dictionary, 2006
  11. The American Heritage Dictionary of the English Language, Fourth Edition
  12. Princeton University WordNet 3.0
  13. The American Heritage Science Dictionary, 2002
  14. „"Email" or "e-mail"“. „English Language & Usage — Stack Exchange“. 25 август 2010. http://english.stackexchange.com/questions/1925/email-or-e-mail. конс. 26 септември 2010. 
  15. RFC 821 (rfc821) - Simple Mail Transfer Protocol
  16. RFC 1939 (rfc1939) - Post Office Protocol - Version 3
  17. RFC 3501 (rfc3501) - Internet Message Access Protocol - version 4rev1
  18. "The Watsons: IBM's Troubled Legacy"
  19. See File:Gestapo anti-gay telex.jpg
  20. "Telex and TWX History", Donald E. Kimberlin, 1986
  21. "CTSS, Compatible Time-Sharing System" (September 4, 2006), University of South Alabama, http://www.cis.usouthal.edu/faculty/daigle/project1/ctss.htm USA-CTSS].
  22. an IBM 7094
  23. Tom Van Vleck, "The IBM 7094 and CTSS" (September 10, 2004), Multicians.org (Multics), web: Multicians-7094.
  24. 24,0 24,1 Tom Van Vleck. „The History of Electronic Mail“. http://www.multicians.org/thvv/mail-history.html. 
  25. Version 3 Unix mail(1) manual page from 10/25/1972
  26. Version 6 Unix mail(1) manual page from 2/21/1975
  27. APL Quotations and Anecdotes, including Leslie Goldsmith's story of the Mailbox
  28. History of the Internet, including Carter/Mondale use of email
  29. Gordon Bell's timeline of Digital Equipment Corporation
  30. Ray Tomlinson. „The First Network Email“. http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html. 
  31. Version 7 Unix manual: "UUCP Implementation Description" by D. A. Nowitz, and "A Dial-Up Network of UNIX Systems" by D. A. Nowitz and M. E. Lesk
  32. with various vendors supplying gateway software to link these incompatible systems
  33. 33,0 33,1 Email History
  34. "The Technical Development of Internet Email" Craig Partridge, April–June 2008, p.5
  35. The First Email
  36. Wave New World,Time Magazine, October 19, 2009, p.48
  37. RFC 5322, 3.6. Field Definitions
  38. RFC 5322, 3.6.4. Identification Fields
  39. Microsoft, Auto Response Suppress, 2010, microsoft reference, 2010 Sep 22
  40. RFC 5064
  41. Шаблон:Cite IETF
  42. John Levine (14 јануари 2012). „Trace headers“. „email message“. IETF. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04115.html. конс. 16 јануари 2012. „there are many more trace headers than those two“ 
  43. This extensible field was defined by RFC 5451, that also defined a IANA registry of Email Authentication Parameters.
  44. RFC 4408.
  45. Defined in RFC 3834, and updated by RFC 5436.
  46. RFC 5518.
  47. Craig Hunt (2002). „TCP/IP Network Administration“. O'Reilly Media. стр. 70. ISBN 978-0596002978. 
  48. „Email policies that prevent viruses“. http://advosys.ca/papers/mail-policies.html. 
  49. "When posting to a RootsWeb mailing list..."
  50. "...Plain text, 72 characters per line..."
  51. How to Prevent the Winmail.dat File from Being Sent to Internet Users
  52. In practice, some accepted messages may nowadays not be delivered to the recipient's InBox, but instead to a Spam or Junk folder which, especially in a corporate environment, may be inaccessible to the recipient
  53. „File Extension .EML Details“. „FILExt - The File Extension Source“. http://filext.com/file-extension/EML. конс. 26 септември 2009. 
  54. RFC 2368 section 3 : by Paul Hoffman in 1998 discusses operation of the "mailto" URL.
  55. Barrett, Grant. „All We Are Saying.“, New York Times, 23 декември 2007 (конс. 24 декември 2007).
  56. „Email Right to Privacy - Why Small Businesses Care“. Anita Campbell. 19 јуни 2007. http://www.smallbiztrends.com/2007/06/email-has-right-to-privacy-why-small-businesses-care.html. 
  57. C. J. Hughes. „E-Mail May Be Binding, State Court Rules“, New York Times, 17 февруари 2011 (конс. 20 февруари 2011).
  58. „Exchange 2007: Attachment Size Increase,...“. TechNet Magazine, Microsoft.com US. 25 март 2010. http://technet.microsoft.com/en-us/magazine/2009.01.exchangeqa.aspx?pr=blog. 
  59. Lohr, Steve. „Is Information Overload a $650 Billion Drag on the Economy?“, New York Times, 20 декември 2007 (конс. 1 мај 2010).
  60. Stross, Randall. „Struggling to Evade the E-Mail Tsunami“, New York Times, 20 април 2008 (конс. 1 мај 2010).
  61. Radicati, Sara. „Email Statistics Report, 2010“. http://www.radicati.com/wp/wp-content/uploads/2010/04/Email-Statistics-Report-2010-2014-Executive-Summary2.pdf. 
  62. Rich Kawanagh. The top ten email spam list of 2005. ITVibe news, 2006, january 02, ITvibe.com
  63. How Microsoft is losing the war on spam Salon.com
  64. Spam Bill 2003 (PDF)
  65. M. Toorani, SMEmail - A New Protocol for the Secure E-mail in Mobile Environments, Proceedings of the Australian Telecommunications Networks and Applications Conference (ATNAC'08), pp.39-44, Adelaide, Australia, December 2008. (arΧiv:1002.3176)
  66. Amy Harmon. „Software That Tracks E-Mail Is Raising Privacy Concerns“, The New York Times, 22 ноември 2000 (конс. 13 јануари 2012).
  67. About.com
  68. Webdevelopersnotes.com
  69. Microsoft.com

Понатамошни информации[уреди]

Надворешни линкови[уреди]