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

ЕТ знакот, дел од секој SMTP адреса на е -пошта

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

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

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

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

Електронски писма засновани на мрежа првично беа разменувани на ARPANET во екстензии на протокол за пренос на податотеки (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 до 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 (различни мрежи) и 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. Наводот journal бара |journal= (help)
  3. ↑ „Readers on (Wired News) Style“. Wired magazine. 24 October 2000. Архивирано од изворникот на 2011-08-18. Посетено на 2012-01-17. Наводот journal бара |journal= (help)CS1-одржување: бот: непознат статус на изворната URL (link)
  4. ↑ „RFC Editor Terms List“. IETF.
  5. ↑ „Yahoo style guide“. Архивирано од изворникот на 2013-05-09. Посетено на 2012-01-17.
  6. ↑ AP Stylebook editors share big changes Архивирано на 22 март 2011 г. from the American Copy Editors Society
  7. ↑ Gerri Berendzen; Daniel Hunt. „AP changes e-mail to email“. 15th National Conference of the American Copy Editors Society (2011, Phoenix). ACES. Архивирано од изворникот на 2011-03-22. Посетено на 23 March 2011.
  8. ↑ AskOxford Language Query team. „What is the correct way to spell 'e' words such as 'email', 'ecommerce', 'egovernment'?“. FAQ. Oxford University Press. Архивирано од изворникот на 2008-07-01. Посетено на 4 September 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. August 25, 2010. Посетено на September 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“.
  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“. Архивирано од изворникот на 2011-02-27. Посетено на 2012-01-17.
  29. ↑ Gordon Bell's timeline of Digital Equipment Corporation
  30. ↑ Ray Tomlinson. „The First Network Email“. Архивирано од изворникот на 2006-05-06. Посетено на 2012-01-17.
  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“. Архивирано од изворникот на 2008-05-15. Посетено на 2012-01-17.
  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" Архивирано на 12 мај 2011 г. Craig Partridge, April–June 2008, p.5
  35. ↑ „The First Email“. Архивирано од изворникот на 2006-05-06. Посетено на 2012-01-17.
  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. ↑ John Klensin (October 2008). "Trace Information". Simple Mail Transfer Protocol. Internet Engineering Task Force. sec. 4.4. RFC 5321. https://tools.ietf.org/html/rfc5321#section-4.4. 
  42. ↑ John Levine (14 January 2012). „Trace headers“. email message. IETF. Посетено на 16 January 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“. Архивирано од изворникот на 2007-05-12. Посетено на 2012-01-18.
  49. ↑ „"When posting to a RootsWeb mailing list..."“. Архивирано од изворникот на 2014-02-19. Посетено на 2012-01-18.
  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. Посетено на 2009-09-26.
  54. ↑ RFC 2368 section 3 : by Paul Hoffman in 1998 discusses operation of the "mailto" URL.
  55. ↑ Barrett, Grant (December 23, 2007). „All We Are Saying“. New York Times. Посетено на 2007-12-24.
  56. ↑ „Email Right to Privacy - Why Small Businesses Care“. Anita Campbell. 2007-06-19.
  57. ↑ C. J. Hughes (February 17, 2011). „E-Mail May Be Binding, State Court Rules“. New York Times. Посетено на 2011-02-20.
  58. ↑ „Exchange 2007: Attachment Size Increase,...“. TechNet Magazine, Microsoft.com US. 2010-03-25.
  59. ↑ Lohr, Steve (2007-12-20). „Is Information Overload a $650 Billion Drag on the Economy?“. New York Times. Посетено на May 1, 2010.
  60. ↑ Stross, Randall (2008-04-20). „Struggling to Evade the E-Mail Tsunami“. New York Times. Посетено на May 1, 2010.
  61. ↑ Radicati, Sara. „Email Statistics Report, 2010“ (PDF).
  62. ↑ Rich Kawanagh. The top ten email spam list of 2005. ITVibe news, 2006, january 02, ITvibe.com Архивирано на 20 јули 2008 г.
  63. ↑ How Microsoft is losing the war on spam Salon.com Архивирано на 13 август 2011 г.
  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. (arXiv:1002.3176)
  66. ↑ Amy Harmon (2000-11-22). „Software That Tracks E-Mail Is Raising Privacy Concerns“. The New York Times. Посетено на 2012-01-13.
  67. ↑ „About.com“. Архивирано од изворникот на 2016-08-27. Посетено на 2012-01-18.
  68. ↑ Webdevelopersnotes.com
  69. ↑ Microsoft.com

Понатамошни информации

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

Нормативна контрола

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!