이메일 전달

Email forwarding

이메일 전달은 일반적으로 한 이메일 주소로 배달된 이메일 메시지를 하나 이상의 다른 이메일 주소로 다시 보내는 작업을 말한다.

전자통신 이전부터 메일에 사용되는 포워딩이라는 용어는 특별한 기술적 의미는 없지만,[1] 이메일이 새로운 목적지로 '전송'되었다는 것을 암시한다.

또한 이메일 포워딩은 특정 주소로 가는 메일을 리디렉션하여 하나 이상의 다른 주소로 보낼 수 있다. 반대로, 여러 개의 다른 주소로 가는 이메일 항목은 포워딩을 통해 하나의 주소 입력란에 통합될 수 있다.[clarification needed]

이메일 사용자와 이메일 시스템의 관리자는 서버 기반 전달과 클라이언트 기반 전달을 모두 말할 때 같은 용어를 사용한다.

서버 기반 전달

도메인 이름(전자 메일 주소에서 @의 오른쪽에 나타나는 부분)은 해당 주소 클래스에 대한 대상 서버를 정의한다.[2] 도메인은 또한 백업 서버를 정의할 수 있다; 그들은 우편함이 없고 봉투의 일부를 변경하지 않고 메시지를 전달한다.[3] 반면 주 서버는 사용자의 우편함에 메시지를 배달하거나 일부 봉투 주소를 변경하여 전달할 수 있다. ~/.forward 파일(아래 참조)은 다른 수신자에게 서버 기반 전달의 전형적인 예를 제공한다.

전자 메일 관리자는 리디렉션이라는 용어를 서버 기반 전자 메일 전달의 동의어로 사용하는 경우가 있다. 프로토콜 엔지니어들은 포워딩 서버를 지칭하기 위해 중재자라는 용어를 사용하는 경우가 있다.[4]

스팸 때문에 서로 다른 도메인에 걸쳐 메일을 신뢰성 있게 전달하기가 점점 어려워지고 있으며, 가능하면 피하는 것이 좋다고 조언하는 사람도 있다.[5]

다른 수신인에게 서버 기반 전달 사용

역할 주소
정보, 판매, 우체부 및 유사한 이름이 이메일[6] 주소에서 @의 왼쪽에 나타날 수 있다. 조직은 주어진 역할을 위해 의도된 메시지를 해당 역할 또는 사무실에서 현재 활동하고 있는 사람의 주소로 전달할 수 있다.
가명 주소
대부분의 도메인 네임 호스팅 시설은 사용자의 인터넷 서비스 제공자의 우편함과 같은 다른 이메일 주소로 메일을 전달할 수 있는 시설을 제공한다. 또한 메일 전달 서비스 제공업체도 따로 있다. 이를 통해 사용자는 우편함 제공자를 변경해도 변경되지 않는 이메일 주소를 가질 수 있다.
여러 주소 또는 중단된 주소
사용자가 전자 메일 주소를 변경하거나 여러 개의 주소를 가진 경우, 사용자 또는 관리자는 메시지 손실을 방지하기 위해 이 주소에서 현재 주소 하나로 전달을 설정할 수 있다.

전달 대 리마인팅

일반 메시지 전달은 봉투 수신인을 변경하고 봉투 발송인 필드를 변경하지 않은 상태로 유지한다. "Envelope 발송인" 필드는 Email 클라이언트 소프트웨어가 일반적으로 표시하는 From 헤더와 동일하지 않다. 즉, SMTP 프로토콜의 초기 단계에서 사용된 필드를 나타내고, 이후 Return-Path 헤더로 저장된다. 이 필드는 메일 시스템이 반송 메시지(배달 실패(또는 성공) 보고)를 보내야 하는 주소를 가지고 있다.

이와는 대조적으로, 리메이크 또는 재분배라는 용어는 때때로 메시지를 다시 보내고 "envelope 보낸 사람" 필드를 다시 쓰는 것을 의미할 수 있다. 전자우편 목록은 대표적인 예를 제공한다. 작성자는 각 목록 주소로 리메이킹을 수행하는 반사경에 메시지를 제출한다. 그렇게 하면 바운스 메시지(어떤 목록 구독자에게 메시지를 배달하는 실패를 보고하는 메시지)는 메시지의 작성자에게 도달하지 못할 것이다. 그러나, 짜증나는 잘못된 구성의 휴가 자동 복제는 작가들에게 다가온다.

일반적으로, 일반 메시지 전달은 별칭 확장 기능을 하는 반면, 적절한 메시지 전달은 우편물 목록을 위해 전달이라는[1] 이름의 전달 코트도 제공한다. 새로운 메시지를 제출하는 메일 사용자 에이전트의 행동과 유사하게 메시지에 대한 추가 수정 작업이 수행될 때, 전달이라는 용어는 기만적이 되고 재통보하는 것이 더 적절해 보인다.

발송인 정책 프레임워크(SPF)에서 봉투 발송인의 도메인 이름은 정책 제한의 적용을 받는다. 따라서 SPF는 일반적으로 일반 메시지 전달을 허용하지 않는다. 내부 도메인 리디렉션은 관련 서버가 일관된 구성을 공유하는 한 SPF를 준수한다. 도메인 간 메시지 전달을 실천하는 메일 서버는 SPF 자체를 구현하지 않더라도 SPF를 파기할 수 있다. 즉, SPF 검사를 적용하거나 SPF 레코드를 게시하지 않는다.[7] Sender Rewriting Scheme은 SPF와 호환되는 일반적인 전달 메커니즘을 제공한다.

클라이언트 기반 전달

클라이언트 기반 자동 전달

클라이언트 포워딩은 메일 검색 에이전트와 같은 비인터랙티브 클라이언트를 사용하여 자동으로 수행될 수 있다. 검색 에이전트가 클라이언트 프로토콜을 사용하지만, 이 전달은 동일한 메시지 ID를 유지한다는 점에서 서버 전달과 유사하다. 봉투판매인에 대한 우려가 적용된다.[7]

수동 클라이언트 기반 전달

최종 사용자는 이메일 클라이언트를 사용하여 수동으로 메시지를 전달할 수 있다. 인라인 전달은 새 메시지의 기본 텍스트 아래에 메시지를 인용하며, 일반적으로 원본 첨부 파일과 선택한 헤더 선택(예: 원본 보낸 사람 및 회신 받는 사람)을 보존한다. 이렇게 전달된 메시지의 수신인은 여전히 원본 메시지에 회신할 수 있다. 이 기능은 원래 헤더의 존재 여부에 따라 달라지며 관련 대상 주소를 수동으로 복사하고 붙여넣는 것을 암시할 수 있다.

첨부 파일로 전달은 모든 헤더와 첨부 파일을 포함하여 전체 원본 메시지를 포함하는 MIME 첨부 파일(rfc822 유형)을 준비한다. 모든 헤더를 포함하면 메시지를 전송한 서버 및 편지함에 추가된 클라이언트 태그와 같은 메시지에 대한 많은 정보가 노출된다는 점에 유의하십시오. 이런 방식으로 전달된 메시지의 수신인은 첨부된 메시지를 열고 원활하게 회신할 수 있다.

This kind of forwarding actually constitutes a remailing from the points of view of the envelope-sender and of the recipient(s). The message identity also changes.

Historical development of email forwarding

RFC 821, Simple Mail Transfer Protocol, by Jonathan B. Postel in 1982, provided for a forward-path for each recipient, in the form of, for example, @USC-ISIE.ARPA, @USC-ISIF.ARPA: Q-Smith@ISI-VAXA.ARPA — an optional list of hosts and a required destination-mailbox. When the list of hosts existed, it served as a source-route, indicating that each host had to relay the mail to the next host on the list. Otherwise, in the case of insufficient destination-information but where the server knew the correct destination, it could take the responsibility to deliver the message by responding as follows: 

S: RCPT TO:<Postel@USC-ISI.ARPA> R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>

The concept at that time envisaged the elements of the forward-path (source route) moving to the return-path (envelope sender) as a message got relayed from one SMTP server to another. Even if the system discouraged the use of source-routing,[8] dynamically building the return-path implied that the "envelope sender" information could not remain in its original form during forwarding. Thus RFC 821 did not originally allow plain message-forwarding.

The introduction of the MX record[9] made source-routing unnecessary. In 1989, RFC 1123 recommended accepting source-routing only for backward-compatibility. At that point, plain message forwarding[7] became the recommended action for alias-expansion. In 2008, RFC 5321 still mentions that "systems may remove the return path and rebuild [it] as needed", taking into consideration that not doing so might inadvertently disclose sensitive information.[10] Actually, plain message-forwarding can be conveniently used for alias expansion within the same server or a set of coordinated servers.

~/.forward files

The reference SMTP implementation in the early 1980s was sendmail, which provided for ~/.forward files, which can store the target email-addresses for given users. This kind of server-based forwarding is sometimes called dot-forwarding.[11] One can configure some email-program filters to automatically perform forwarding or replying actions immediately after receiving. Forward files can also contain shell scripts, which have become a source of many security problems. Formerly only trusted users could utilize the command-line switch for setting the envelope sender, -f arg; 일부 시스템은 보안상의 이유로 이 기능을 비활성화했다.[12]

이메일은 1990년대에 클라이언트-서버 아키텍처의 공식화보다 앞선다.[13] 따라서 클라이언트와 서버의 구분이 불가피해 보인다. 원래의 구별은 같은 기계에서 실행되는 데몬과 사용자 제어 프로그램을 대조했다. sendmail 데몬은 메일을 관리해야 하는 모든 사용자를 가장할 수 있도록 루트 권한으로 실행하는데 사용되었다. 한편, 사용자는 다음을 포함한 자신의 개별 메일 파일과 구성 파일에 접근할 수 있다. ~/.forward클라이언트 프로그램은 주어진 사용자의 서버 구성 파일을 편집하는 데 도움을 줄 수 있으며, 따라서 각 프로그램이 어떤 역할을 하는지 혼동을 일으킬 수 있다.

가상 사용자

"가상 사용자"란 메일 서버 시스템에 로그인하지 않고 원격 클라이언트를 이용하여 우편함에 접속만 하는 이메일 사용자를 말한다. 메일 서버 프로그램은 가상 사용자와 일반 사용자 모두에 대해 작동하거나, 가상 사용자가 동일한 시스템 ID를 자주 공유한다는 점을 이용하기 위해 사소한 수정을 요구할 수 있다. 후자의 상황은 서버 프로그램이 시스템 액세스 제한을 준수할 필요가 없기 때문에 일부 기능을 보다 쉽게 구현할 수 있게 한다. 동일한 운영 원칙이 적용된다. 그러나 가상 사용자는 좋든 나쁘든 자신의 구성 파일에 액세스하는 데 더 많은 어려움을 겪는다.

메일 전달을 촉진하는 상용 제품

참고 항목

메모들

  1. ^ a b 3.9.2 RFC 5321의 목록에서 포워딩이라는 용어는 모호하게 사용된다. "별칭을 취급하는 것(제3.9.1절)과 전달(이 하위섹션)의 주요 차이점은 [반환 경로 헤더]에 대한 변경"이라고 언급한다. 동일한 용어를 동일한 하위섹션의 시작 부분에 반대의 의미로 사용하지 않은 경우, 새로운 W.R.t. RFC 2821이라는 문구는 전달의 정의로 해석될 수 있다. RFC 5321의 기여자가 동의함에 따라, Tony Finch (2008-11-03). "English terms for forwarded addresses". IETF. Archived from the original on 2008-12-11. Retrieved 2008-11-07. [forwarding is] a fuzzy (non-technical) term in SMTP
  2. ^ 관련 도메인의 기본 MX 레코드는 일반적으로 메일 서버의 이름을 게시한다. 그렇지 않으면 도메인 이름에 IP 주소가 있어야 한다.
  3. ^ 메시지의 봉투는 메시지의 내용을 전송하기 전에 SMTP 트랜잭션에서 전송되는 데이터다. 봉투는 메시지의 헤더에 수신 서버에 의해 저장될 수 있지만, 메시지가 배달될 때 분실된다. 특히, 봉투에는 반송 경로(예: 바운스 주소, MAIL FROM 인수, 메일 보낸 사람 또는 보낸 사람)와 하나 이상의 수신자(Bcc 포함)가 들어 있다.
  4. ^ Dave Crocker (July 2009). "Mediators". Internet Mail Architecture. IETF. sec. 5. doi:10.17487/RFC5598. RFC 5598. Retrieved 19 March 2013. A Mediator forwards a message through a re-posting process. The Mediator shares some functionality with basic MTA relaying, but has greater flexibility in both addressing and content than is available to MTAs.
  5. ^ John Levine (2008-10-15). "Users Don't Like Forwarded Spam". CircleID. Retrieved 2008-11-07.
  6. ^ RFC 2142, "공통 서비스, 역할 및 기능의 우편함 이름", 1997년에는 마케팅, 지원, 남용, 보안, 웹마스터 등에 대해서도 언급하고 있다.
  7. ^ a b c 다음 정방향 경로를 고려하십시오.
    도메인 B가 A의 정책이나 C의 필터링을 제어하지 않는 한, 도메인 A에서 도메인 C로 메시지를 쉽게 전달해서는 안 된다. 실제로 A가 B의 이름을 사용하지 못하도록 하는 SPF 정책을 공표하고, C가 발신인의 정책 확인을 적용하는 경우, C는 RFC 7208에 따라 메시지를 거부할 수 있다. 즉, 일반 메시지 전달과 불법 도메인 이름 남용을 공식적으로 구분할 수 없다.
  8. ^ 섹션 6.2.7 RFC 822의 명시적 경로 사양에 있는 참고 사항을 참조하십시오.
  9. ^ MX 레코드는 RFC 974와 함께 도입되었다. MX record#A로의 예비역사를 참조한다.
  10. ^ 일반 메시지 전달은 사용자의 의도를 존중하지 않고 최종 목적지 주소를 공개할 수 있다. 메시지 전달의 섹션 7.7 정보 노출 및 RFC 5321의 4.4 추적 정보를 참조하십시오.
  11. ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (September 2016). "Alias". Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. IETF. sec. 3.2.1. doi:10.17487/RFC7960. RFC 7960. Retrieved 14 March 2017.
  12. ^ Hunt, Craig (2002). TCP/IP Network Administration. O'Reilly. p. 606. ISBN 0-596-00334-X. 현재(2006년 버전 8.708)의 sendmail 문서에는 사용상의 제약이 없다. -f 그리고 봉투 발신인 데이터에 대한 그것의 작용을 설명하기 위해 오버라이드하기 보다는 동사 집합을 사용한다.
  13. ^ 이 책의 연대는 1990년대 초반부터 클라이언트-서버-faq의[permanent dead link] 범위에 있다. 원격 절차 호출은 1970년대에 시작되었지만, 네트워크가 꽤 보편화되기 전까지는 널리 사용되지 않았다.