이메일 박스

Email box

우편함[1](전자 우편함,[1] 전자 우편함, 전자 우편함, 전자 우편함)은 전자 우편 메시지가 배달되는 대상이다. 우편 제도에서 편지함에 해당하는 것이다.

정의들

우편함은 이메일 주소로 식별된다. 그러나 모든 이메일 주소가 저장 시설에 해당하는 것은 아니다. 사이비 우편함이라는 용어는 때때로 확정 우편물 저장소에 해당하지 않는 주소를 지칭하는 데 사용된다. 이메일 전달은 그러한 주소로부터 최종 수신자에게 도달하기 위해 적용될 수 있다. 전자우편 목록과 전자우편 별칭이 대표적인 예다.

RFC 5321은 전자우편 주소를 메일을 보낼 사용자 또는 메일을 보관할 위치를 식별하는 문자열로 정의한다.[2] 우체통이라는 용어는 저 예금고를 가리킨다. 그런 의미에서 우편함과 주소라는 용어는 서로 바꾸어 사용할 수 있다.

RFC 5322는 우편함을 다음과 같이 정의한다.[3] 우편함은 우편물을 받는다. 파일 저장과 반드시 관련된 것은 아닌 '개념적 실체'이다. 그것은 또한 일부 사이트들이 전통적인 팩스 송수신처럼 프린터로 우편물을 인쇄하여 수취인의 책상으로 출력물을 배달하는 것을 선택할 수 있다는 것을 예시한다.

접근

주요 기사: 이메일 클라이언트

우편함에 대한 액세스는 우편함 공급자에 의해 제어된다. 보통 인증된 사용자만이 자신의 우편함을 읽거나 삭제할 수 있는 반면, 누구나 우편함에 메시지를 보낼 수 있다. 전자 메일 클라이언트가 하나 이상의 편지함에서 메시지를 검색하는 경우 클라이언트가 메시지를 저장하는 데이터베이스(파일, 디렉토리, 저장 시스템)를 로컬 사서함이라고 함.

읽기 액세스

메시지를 검색하는 데 널리 사용되는 클라이언트-서버 프로토콜:

  • POP(Post Office Protocol): 단일 클라이언트 컴퓨터의 메시지를 읽는 데 가장 적합한 방법. 일반적으로 메시지는 검색 후 서버 사서함에서 제거된다. 어쨌든, 메시지의 마스터 복사본은 로컬 우편함에 있는 것이다.
  • IMAP(Internet Message Access Protocol): 서버 사서함의 원격 관리를 허용하여 여러 클라이언트로부터 메시지를 검색하도록 설계되었다. 마스터 복사본은 서버에 남아 있지만 복사본은 로컬로 저장할 수 있다.
  • HTTP를 통한 웹메일: 메시지는 서버 정의 형식으로 사용자의 브라우저에 제공된다. 마스터 복사본은 서버에 유지되며, 다운로드 가능한 원본 형식일 수 있다.

IMAP과 웹메일은 다소간 서로 잘 어울릴 수 있다. POP은, 서버에 메시지를 남겨두도록 구성된 경우, 그것들과 호환될 수 있다.

현재 RFC 5322에 의해 정의된 인터넷 메시지 형식은 1982년(RFC 822)으로 거슬러 올라간다. 그것이 POP와 IMAP 고객들이 회수하기를 기대하는 것이다.

쓰기 액세스 권한

우편함에 전송된 메시지는 메일 배달 에이전트에 의해 서버의 로컬 우편함에 기록되며, 원격 사용자의 경우 해당 서버에 소유한 원격 우편함이다. IMAP 클라이언트는 원격 우편함의 메시지를 복사, 이동 및 삭제할 수 있다.

크기 할당량

우편함에는 사용 가능한 메모리에 의해 암묵적으로 결정되거나 우편함 또는 폴더에 대한 할당량 정의 후에 크기 제한이 있다. 행정상의 사소한 문제 이외에도, 할당량 제한은 이메일 폭탄 공격을 완화하는데 도움이 된다.[4]

IMAP 할당량 연장은 1997년에 표준화되었다.[5]

저장 형식

모든 종류의 데이터베이스를 이메일 메시지를 저장하는 데 사용할 수 있다. 그러나 일부 표준화는 다른 컴퓨터 프로그램에 의해 주어진 우편함에 접근할 수 있도록 몇 가지 잘 알려진 파일 형식을 만들어냈다. 널리 사용되는 형식에는 두 가지 종류가 있다.

  • mbox는 모든 메시지를 하나의 파일에 저장하는 원래의 기술이다.
  • Maildir는 디렉토리 트리에 모든 메시지를 저장할 수 있는 새로운 사양으로, 각 메시지에 대해 하나의 파일을 제공한다.

사서함 이름

주요 기사: 이메일 주소

편지함 이름은 이메일 주소의 첫 번째 부분이며, 로컬 부분이라고도 하며, 즉 @ 기호 앞의 부분을 가리킨다. 형식은 RFC 5322 및 RFC 5321에 의해 공식적으로 지정된다. 메일 서버 또는 대상 도메인에서 수신인의 사용자 이름인 경우가 많다.

국소 부분은 최대 64자까지 길 수 있으며 이론적으로는 대소문자를 구분한다. 유효한 문자 순서(아래 설명) 또는 따옴표로 묶인 문자열로 구성될 수 있으며, 공백과 특수 문자를 포함할 수도 있다. SMTP의 SMTPUTF8 확장을 사용하여 비 ASC도 사용할 수 있다.II 문자.[6] 일반적인 함정을 피하기 위해 새로운 우편함 이름을 만들 때 약간의 상식이 필요하다. RFC 5321의 말에 따르면, 제한을 가하는 것을 매우 경계한다.

Local-part에 대한 위의 정의는 비교적 허용되지만, 최대 상호운용성을 위해 메일을 수신할 것으로 예상되는 호스트는 Local-part가 인용 문자열 양식을 요구하거나 사용하는 우편함이나 Local-part가 대/소문자를 구분하는 우편함의 정의를 피해야 한다.

— John Klensin, RFC 5321

유효한 문자

다음 문자는 인용 없이 로컬 파트에 표시될 수 있다.

  • SMTPUTF8을 사용하는 경우 영문 대문자 및 소문자(a–z, A–Z) 및 UTF-8 시퀀스
  • 숫자 0 로 9
  • 성격. ! # $ % & ' * + - / = ? ^ _ ` { } ~
  • 캐릭터 . (점) 첫 번째 문자 또는 마지막 문자가 아니며 연속적으로 두 번 이상 나타나지 않는 경우(예: John).Doe@example.com).

예약 이름

「우편사」, 「남용」 등의 명칭은 잘 알려진 역할과 기능에 해당하며, 유효성이 요구된다.[7]

어떤 이름은 문제를 일으키는 것으로 알려져 있는데, 아마도 메일 필터를 포함한 메일 소프트웨어의 (일부) 내부에서 사용하는 이름과 충돌하거나, 기본 저장 시스템이 이를 자극하기 때문일 것이다. 예를 들어 GitHub에는 많은 목록이 있다.[8][9]

참조

  1. ^ a b ISO/IEC 2382:2015
  2. ^ RFC 5321, Simple Mail Transfer Protocol, J. Klensin, Internet Society(2008년 10월), 섹션 2.3.11 (메일함 및 주소)
  3. ^ RFC 5322, 인터넷 메시지 형식, P. 레스닉(Ed.), 인터넷 소사이어티(2008년 10월), 섹션 3.4(주소 사양)
  4. ^ Nick Christenson; Tim Bosserman; David Beckemeyer (December 9, 1997). "A Highly Scalable Electronic Mail Service Using Open Systems". USENIX. Retrieved December 12, 2015. In addition to authentication and mailbox location, the mail delivery agent also knows about mailbox quotas which we impose on our subscribers. If the current mailbox size is over the quota for that user, the default being 10 MB, then the message is bounced back to the MTA with reason, "User npc, mailbox full." In addition to preventing resource abuse on the part of subscribers, this also helps mitigate possible damaging effects of mail bombing by malicious people on the Internet. We believe that a 10 MB quota is quite generous, especially considering over a 28.8 modem using very high quality line speeds and no network bottlenecks, one could expect to take over an hour to download the contents of a 10 MB mailbox.
  5. ^ John G. Myers (January 1997). IMAP4 QUOTA extension. IETF. doi:10.17487/RFC2087. RFC 2087.
  6. ^ Jiankang YAO; Wei MAO (February 2012). "The SMTPUTF8 Extension". SMTP Extension for Internationalized Email. IETF. sec. 3.2. doi:10.17487/RFC6531. RFC 6531. Retrieved December 12, 2015.
  7. ^ Dave Crocker (May 1997). Mailbox names for common services, roles and functions. IETF. sec. 3,4,5. doi:10.17487/RFC2142. RFC 2142. Retrieved December 12, 2015.
  8. ^ Casey O'Hara (2011). "A list of reserved usernames to avoid vanity URL collision with resource paths". GitHub. Retrieved December 12, 2015.
  9. ^ Michael Mahemoff (2011). "Reserved username list".