SMTP(MTA, MUA, MSA, MDA)

System/Protocol 2013. 4. 6. 10:34


Blue arrows can be implemented using SMTP variations.



간이 전자 우편 전송 프로토콜(Simple Mail Transfer Protocol, SMTP)은 인터넷에서 이메일을 보내기 위해 이용되는 프로토콜이다. 사용하는 TCP 포트번호는 25번이다. 상대 서버를 지시하기 위해서 DNS의 MX레코드가 사용된다. RFC2821에 따라 규정되어 있다. 메일 서버간의 송수신뿐만 아니라, 메일 클라이언트에서 메일 서버로 메일을 보낼 때에도 사용되는 경우가 많다.

SMTP는 텍스트 기반의 프로토콜로서 요구/응답 메시지뿐 아니라 모든 문자가 7bit ASCII로 되어있어야 한다고 규정되어 있다. 이 때문에 문자 표현에 8비트 이상의 코드를 사용하는 언어나 첨부파일과 자주 사용되는 각종 바이너리는 마임(MIME)이라고 불리는 방식으로 7비트로 변환되어 전달된다.

SMTP는 메세지를 생성하는 방법을 규정하지 않는다. 메세지 생성을 위하여 로컬 편집이나 단순한 전자 우편 응용이 사용된다. 메세지가 생성되면 호출된 SMTP가 메세지를 받고 TCP를 이용하여 다른 호스트의 SMTP에게 전달한다.

목차

  [숨기기] 

[편집]SMTP 개요

Connected: An Overview(영문)에서 SMTP의 개요에 대해 설명하고 있다.

[편집]SMTP 통신의 예

메일을 보내는 송신자(클라이언트)와 메일을 받는 수신자(서버)간의 연결이 성립된 후 이루어지는 합법적인 SMTP 세션은 다음과 같다. 아래 대화과정에서 클라이언트가 보내는 메시지는 "C:"를 맨 앞에 써서, 서버가 보내는 메시지는 "S:"를 맨 앞에 써서 표시하기로 하자. 대부분의 컴퓨터 시스템에서 연결은 다음과 같이 텔넷 명령어를 사용하여 만들 수 있다.

telnet www.example.com 25

이 명령으로 보내는 클라이언트에서 호스트인 www.example.com으로 SMTP 연결이 시작될 수 있다.

S: 220 www.example.com ESMTP Postfix
C: HELO mydomain.com
S: 250 Hello mydomain.com
C: MAIL FROM: <sender@mydomain.com>
S: 250 Ok
C: RCPT TO: <friend@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: test message
C: From: sender@mydomain.com
C: To: friend@example.com
C:
C: Hello,
C: This is a test.
C: Goodbye.
C: .
S: 250 Ok: queued as 12345
C: quit
S: 221 Bye

[편집]SMTP에서의 인증

원래는 사용자 인증절차가 규정되지 않았었지만, 인터넷의 보급과 함께 그 필요성이 요구되어, SASL 메커니즘을 이용한 인증기구가 SMTP-AUTH(SMTP Authentication)으로 표준화되었다. 인증방식으로 PLAIN, LOGIN, DIGEST-MD5, CRAM-MD5 등이 널리 이용되고 있다.

또, SMTP-AUTH 표준화 이전에 POP_before_SMTP로 불리는 SMTP 밖의 기구에 의한 사용자 제한방법이 고안되어 현재까지 사용되고 있다..

[편집]RFC

  • RFC 2821 - Simple Mail Transfer Protocol
  • RFC 1869 - SMTP Service Extensions (ESMTP)
  • RFC 1891 - SMTP Service Extension for Delivery Status Notifications (DSN)
  • RFC 2554 - SMTP Service Extension for Authentication




Simple Mail Transfer Protocol (단순 메일 전송 프로토콜, SMTP ) 또는 단순 메일 전송 프로토콜 은 인터넷 에서 전자 메일 을 전송하는 프로토콜 이다. 보통 TCP 의 포트 번호 25을 사용한다. 대상 서버를 식별하기 위해 DNS 의 MX 레코드 가 사용된다. RFC 5321로 표준화되어있다.

목차

  [ 숨기기 ] 

개요 [ 편집 ]

SMTP는 IETF에서 표준화 된 메일 전송을위한 프로토콜이다. 1980 년 9 월 메일 전송 프로토콜 (Mail Transfer Protocol)라는 이름의 프로토콜이 RFC 772 에서 제안 된 두 번의 개정을 거쳐 1982 년 8 월에 단순 메일 전송 프로토콜 (SMTP)라는 명칭으로 RFC 821 / STD0010 [ 1] 으로 표준 (Standard)되었다.

그 후 2001 년 4 월에 SMTP 다른 RFC의 내용도 함께 개정되어 RFC 2821 [2] 로 제안 표준 (Proposed Standard)되었다. RFC 821 에서 약 20 년을 거쳐 개정판이 발행 된 것은 주로 인터넷의 보급에 따라 다양한 메일 확장 기능이 구현되어 그들을지지하는 부분을 정리할 필요가 있었기 때문이다. 서버 외부에서의 공격이나 IPv6 주소에 대응할 수 있도록, 또한 SPF ( RFC 4408 ), DKIM ( RFC 4871 ) 등에도 대응하기 위해 2008 년 10 월에 다시 개정 ( ​​RFC 5321 ) [3] 된 .

SMTP는 메일 서버 의 MTA 사이의 전송뿐만 아니라 MUA 에서 메일 서버에 메일을 보낼 때에도 사용되는 경우가 많다.

그러나이 경우 수신 한 서버 측의 행동이 서버 간의 전송과 다른 점이 많기 때문에, 서버 측을 MSA이라고 포트 번호 587을 이용하여 일반 MTA 와 나눌 많아지고있다 (RFC 5321 에서 RFC 4409 이 권장되었다).

SMTP는 원래 텍스트 기반 프로토콜이며, 요청 / 응답 메시지뿐 아니라 모든 문자가 7 비트 ASCII 이어야한다는 제한이 있었다. 현재는 확장 기능 8 bit 이상을 요구하는 언어와 첨부 파일에 사용되는 것이 많은 이진 도 그대로 전송하는 것도 가능하지만, 호환성을 고려하면 MIME 하는 방식으로, 7 bit에 맞게 하는 것이 바람직하다.

또한 일본어 는 일반적으로 ISO-2022-JP 라는 문자 코드 를 사용하면 모든 바이트 가 7 bit에 맞게하고있다.

SMTP에서는 서버와 클라이언트의 역할이 명확하게 구분되어있다. RFC 5321 에 따르면 그들은 아래와 같이 설명된다.

  + -------- + + --------- + + --------- +
  | User | <-> | | | |
  + -------- + | | SMTP | |
                | Client-| Commands / Replies | Server-|
  + -------- + | SMTP | <----------------> | SMTP | + -------- +
  | File | <-> | | and Mail | | <-> | File |
  | System | | | | | | System |
  + -------- + + --------- + + --------- + + -------- +
                SMTP client SMTP server

SMTP에서는 클라이언트가 서버에 접속하면 곧바로 서버 - 클라이언트 사이에 "SMTP 세션 "이 설치되고 그 둘 사이에서 FTP 와 같은 대화식 명령 및 그에 대한 응답이나 메일 교환된다. 우편 거래 는 그중 DATA 명령을 이용한 데이터 전송이기 때문에 하나의 SMTP 세션 동안 여러 메일 트랜잭션이 포함 수있다. 세션 종료하려면 QUIT 명령이 사용되는데,이 점에서도 FTP 와 유사하다.

SMTP에서는 전송 프로토콜로 일반적으로 TCP 가 사용되지만 이에 국한되는 것은 아니다.

SMTP 인증 메커니즘 [ 편집 ]

처음에는 사용자 인증 메커니즘을 제공 않았지만 인터넷의 보급에 따라 그 필요성을 느끼고 때문에 SASL 메커니즘을 이용한 인증 메커니즘을 RFC 2554 - SMTP Service Extension for Authentication ( SMTP-AUTH )로 표준화 된 . 이 표준의 최신 문서는 RFC 4954 이다.

또한 SMTP-AUTH 표준화 이전에 POP before SMTP 라는 메일 보내기 전에 POP3 로그인 을 요구하는 사용자 제한 방법이 고안되어 보급되었다.

RFC [ 편집 ]

  • RFC 5321 - Simple Mail Transfer Protocol - obsoletes RFC 2821 , RFC 1869
  • RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) - obsoletes RFC 1891
  • RFC 4954 - SMTP Service Extension for Authentication - obsoletes RFC 2554
  • RFC 6409 - Message Submission for Mail - obsoletes RFC 4409
  • RFC 4408 - Sender Policy Framework (SPF) Authorizing Use of Domains in E-Mail, Version 1
  • RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures - obsoletes RFC 4871 , RFC 5672

각주 [ 편집 ]

  1. ^ JB Postel 글 : Simple Mail Transfer Protocol
  2. ^ J. Klensin 편 : Simple Mail Transfer Protocol
  3. ^ J. Klensin 편 : Simple Mail Transfer Protocol

관련 항목 [ 편집 ]

카테고리 :



출처 - http://ko.wikipedia.org/wiki/%EA%B0%84%EC%9D%B4_%EC%9A%B0%ED%8E%B8_%EC%A0%84%EC%86%A1_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C





메일 전송 에이전트

메일 전송 에이전트 ( 영어 : Mail Transfer Agent 또는 Message Transfer Agent, 약칭 : MTA )는 전자 메일 을 상대방에게 보내는 메일 서버 기능의 핵심 기능이다.

전자 메일 클라이언트 에서 SMTP 등으로 메일을 수신하고 상대별로 배분 메일 전송 에이전트 (MDA)으로 배분하는 기능을 가지고있다.

MDA와 MTA는 세트와 일체가되어있는 경우도 많아, 메일 서버 전체를 MTA하는 경우도있다.

DNS 에서 지시하는 경우에는 MX (Mail eXchanger)로 표기한다.

주요 비상업적 MTA [ 편집 ]

주요 상용 MTA [ 편집 ]

외부 링크 [ 편집 ]







전자 메일 클라이언트 , 메일 사용자 에이전트 ( 영어 : mail user agent , MUA )는 이메일 을 보내거나 관리하는 응용 프로그램 소프트웨어 . 일반적으로 ( 전자 ) 메일 소프트 등으로 불린다. 메일러 로 불리는 경우도 있지만, 그 경우에는 메일 전송 에이전트 (MTA)을 가리키는 경우도있다.

전자 메일을 보내고에는 메일 서버 에서 움직이고있는 메일 전송 에이전트에 접속한다. 전송을위한 통신 프로토콜 로 SMTP [1] 이 수신을 위해서는 POP3 나 IMAP 가 사용된다.

목차

  [ 숨기기 ] 

기능 [ 편집 ]

개요 [ 편집 ]

전자 메일 클라이언트의 기본적인 기능은 이메일 작성 · 송신 · 수신, 수신 한 전자 메일 관리 및 열람 등이다. 소프트웨어는 이러한 기능은 통합되어있는 경우도 있고, 일부 기능을 다른 소프트웨어 (예를 들면 내용 문 작성에 다른 텍스트 편집기 등을 사용, HTML 형식의 메일 열람 외부 웹 브라우저 를 호출 등)에서 실행하거나 단일 기능의 소프트웨어를 함께 사용할 수있다.

메일 사용자 에이전트로 전자 메일 클라이언트는 일반적으로받는 서버, 보내는 서버의 호스트 이름 ( FQDN )과 계정 ( 이메일 주소 와 로그인 ID , 비밀번호 ) 사용하는 통신 프로토콜 등을 미리 설정해 둔다.

이메일을 취급하는 기능 외에도 인터넷 뉴스 ( 뉴스 그룹 )의 열람 · 투고하는 뉴스 리더 기능, RSS 등을 열람하는 피드 리더 기능, 일정 관리 기능 등이 통합 된 전자 메일 클라이언트 소프트웨어도있다.

이메일 수신 [ 편집 ]

수신 메일 서버의 사용자 사서함에서받은 수신 메일이 결국 거기에서 전자 메일 클라이언트에서 전송되는 방식은 밀기와 끌기 형으로 분류된다.

푸시 형
푸시 이메일 (푸시 메일, 푸시 형 메일)는 수신 메일 서버가 능동적으로 전자 메일 클라이언트에 즉시 전송하는 방식을 말한다.
전원이 켜진 상태에서는 항상 무선 네트워크 연결되는 휴대 기기 는 푸시 형이 효과적이다. 일본에서는 1999 년부터 i 모드 메일 과 휴대 전화 의 전자 메일 푸시를 사용하고있다.
풀형
전자 메일 클라이언트 가 수신 메일 서버에 로그인 할 때와 그 후 일정한 간격으로 폴링 하고 새로운 수신 메일이 있는지를 검사하고 있으면 그것을 사용자의 컴퓨터에있는 사서함에 다운로드하기도한다.
전자 메일 클라이언트가 네트워크에 상시 연결 하지 않으면 네트워크 주소 가 자주 변경되므로 푸시 형에는 맞지 않으므로 일반적으로 폴링한다. 예를 들어, Wi-Fi 연결하는 노트북은 DHCP 서버에서 일회성 주소를 부여하고 네트워크 이름도 일정하지 않습니다. 따라서 수신 메일 서버에 새로운 메일이 도착해도 그 대상이되는 클라이언트 당시의 주소 불명이다.
대중적 수신 프로토콜에는 Post Office Protocol (POP3) 및 Internet Message Access Protocol (IMAP)가있다. 일반적으로 POP3를 사용하면 수신 메일을 로컬로 다운로드하여 저장하고 서버에서 삭제한다. IMAP을 이용한 경우받는 메일을 서버에 저장 한 채로 전자 메일 클라이언트 관리 표시한다.

이메일 전송 [ 편집 ]

만든 전자 메일은 SMTP 를 사용하여 메일 전송 에이전트에 보내는 [1] .

전자 메일보기 [ 편집 ]

헤더에 지정된 인코딩 지정에 따라 메일 본문을 표시하거나 첨부 파일 의 처리를한다. 회신 된 메일의 본문 중 글 머리에 인용을 나타내는 기호 (일반적으로 " > ")가 추가 된 부분의 색상을 변경하여 표시하는 기능을 가진 것도있다. 원래, SMTP 제한으로 인해 7bit 문자 밖에 사용할 수 없었던 ( RFC 821) 이메일에서는 이진 데이터를 첨부 할 경우 MIME 표준에 따라 인코딩되지만 전자 메일 클라이언트는 이것을 해독하고 원래 데이터를 복원합니다.

여러 전자 메일 관리 및보기 [ 편집 ]

메일 파일 저장 형식은 mbox 와 eml 형식 등이있다. 전자 메일 클라이언트는 다른 형식과의 가져 오기 , 내보내기 기능이있어 이전을 지원하고있다.

전자 메일 클라이언트는받은 전자 메일 목록을 만들고 정렬보기 정렬 기능이있다. 로컬 사서함을 다 작성하고 이메일을 정리마다 관리하는 것 외에 표시 색을 변경하거나 플래그 의 개념을 사용하여 메일을 분류하고 저장하는 일도 자주 일어난다. 전자 메일의 헤더 정보에 따라 회신 한 메일을 스레드 표시 기능을 가진 이메일 클라이언트도있다.메일 헤더와 본문 등에 포함 된 특정 문자열에 따라 자동으로 분류하거나, 베이지안 필터 등을 이용하여 스팸 (이른바 스팸 메일) 를 추출하는 기능을 가진 것도있다.

이메일 작성 [ 편집 ]

이메일을 작성할 때 SMTP ( RFC 5321 )에 따라 형식으로 작성해야한다. 일반적으로 전자 메일은 7 bits 문자만을 이용한 텍스트 파일 로 작성된다. 이진 파일 을 첨부하려면 전자 메일 클라이언트가 코딩 을한다. 대상 ( To , Cc , Bcc )와 제목 ( Subject )를 비롯한 헤더를 추가하는 것도 전자 메일 클라이언트 기능이다. 회신 메일의 인용 부분에 인용 부호의 추가와 주소 목록 서명 의 관리 템플릿 적용 등의 기능을 가진 것도있다.

주의점 [ 편집 ]

2009 년 초 시점에서 많이 사용되고있는 주요 전자 메일 클라이언트는받은 편지함의 누적 용량이 2 기가 바이트 정도에 도달하면 작동 불량의 원인 [2] [3] [4] . 특히, 이미지 등 용량이 큰 첨부 파일과 함께 메일이 많으면 수신 사서함 누적 용량의 증가가 빨라진다. 적당한 용량이 시점에서 새 폴더를 만들고받은 편지함에서 과거 데이터를 분할하는 등의 작업을 수행하지 않으면주고받을 수 없게된다.

각주 [ 편집 ]

[ 도움말 ]
  1. ^ a b SMTP ( RFC 5322 )는 RFC4409의 서브 미션 프로토콜을 권장하고있다. 서브 미션 프로토콜의 기본 포트 번호는 587 번이다.
  2. ^ Thunderbird 예
  3. ^ Outlook Express의 예
  4. ^ Mac OS X 함께 메일 소프트 (Mail.app)의 예

관련 항목 [ 편집 ]

외부 링크 [ 편집 ]






Mail submission agent

A mail submission agent (MSA) is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

Many MTAs perform the function of an MSA as well, but there are also programs that are specially designed as MSAs without full MTA functionality. Historically in Internet mail, both MTA and MSA functions use port number 25. The MTA accepts locally-destined mail from other domains, and an MSA accepts submitted mail from local users.

The computer running an MSA is also known as theoutgoing mail server.

Contents

  [hide] 

[edit]Benefits

Separation of the MTA and MSA functions produces several benefits:

One benefit is that an MSA, since it is interacting directly with the author's MUA, can correct minor errors in a message's format (such as a missing Date, Message-ID, To fields, or an address with a missing domain name) and/or immediately report an error to the author so that it can be corrected before it is sent to any of the recipients. An MTA accepting a message from another site cannot reliably make those kinds of corrections, and any error reports generated by such an MTA will reach the author (if at all) only after he has already sent the message.

One more benefit is that with a dedicated port number, 587, it is always possible for users to connect to their domain to submit new mail. Many Internet service providersand enterprise or institutional networks restrict the ability to connect to remote MTAs on port 25. The accessibility of a Mail Submission Agent on port 587[1] enables nomadic users to continue to send mail via their preferred submission servers even from within others' networks. Using a specific submission server is a requirement whensender policies or signing practices are enforced.

Another benefit is that separating the MTA and MSA functions makes it easier for an MTA to deny relaying, that is to refuse any mail that is not addressed to a recipient at a domain that is served locally. By contrast, an MSA must generally accept mail for any recipient on the Internet, though it only accepts such mail from authors who are authorized to use that MSA and who have established their identity to the MSA via authentication. In times when both mail submission and acceptance of incoming mail were usually accomplished using the same protocol and the same server, the ability to send mail to arbitrary destinations without authentication allowed spammers to use MTAs as a means of distributing spam (since a single message transaction can request that an MTA relay a message to a large number of recipients), and also made it more difficult to trace a message to its origin.

Yet another benefit is that MSAs and MTAs can have different policies for filtering of spam. Most MSAs require authentication in the form of a username and password provided by the author. Any messages received by such an MSA are therefore traceable to an author who has a direct relationship with the MSA, and who can be held accountable for his actions. This allows the MSA to have either no spam filtering, or more permissive spam filtering than an MTA that exists for the purpose of accepting incoming email from other domains. It is difficult to establish trust in mail sent between arbitrary domains, because there is generally no direct relationship between those domains via which trust, or even identity, can be established. In the absence of such trust, an MTA must generally rely on heuristics and third-party reputation services to distinguish spam from legitimate traffic, and both of these mechanisms have a history of being error-prone.[2][3] The separation of MSA and MTA therefore avoids the use of unreliable spam recognition mechanisms during mail submission, and increases the probability for legitimate mail to be delivered successfully.

[edit]Protocol

[edit]Mandatory authentication

Main article: SMTP Authentication

RFC 6409 requires that clients are authorized and authenticated to use the mail submission service, e.g., as described in SMTP-AUTH (ESMTPA), or by other means such asRADIUS, public key certificates, or (the mostly obsolete) POP before SMTP.

[edit]Policy enforcement

The MSA must check that the submitted mail is syntactically valid and conforms to the relevant site policies. RFC 6409 contains some optional features:

  • Enforce submission rights guarantees that the envelope sender address is valid and authorized with the used authentication. This in essence complies with the SPF model specified in RFC 4408.
  • May add sender permits to add a Sender address header field if the envelope sender address does not match any author address in the "From" header field. This roughly complies with the Sender ID model specified in RFC 4406 - ignoring the tricky case of Resent-From header fields not covered in RFC 6409.

[edit]See also

[edit]References

  1. ^ C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (November 2007). Email Submission Operations: Access and Accountability Requirements. IETF. RFC 5068. Retrieved 13 February 2013. "Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587."
  2. ^ Amir Herzberg (19 May 2009). "DNS-based email sender authentication mechanisms: A critical review". Computers & Security (ScienceDirect). doi:10.1016/j.cose.2009.05.002.
  3. ^ Jeremy Blosser and David Josephsen (November, 2004). "Scalable Centralized Bayesian Spam Mitigation with Bogofilter". Proceedings of LISA '04: Eighteenth Systems Administration Conference. USENIX. Retrieved 24 June 2010.







Mail delivery agent

A mail delivery agent or message delivery agent (MDA) is a computer software component that is responsible for the delivery of e-mail messages to a local recipient'smailbox.[1] Also called an LDA, or local delivery agent.[2]

Within the Internet mail architecture, local message delivery is achieved through a process of handling messages from the message transfer agent, and storing mail into the recipient's environment (typically a mailbox).

Contents

  [hide] 

[edit]Implementation

Many Mail Handling Software products bundle multiple message delivery agents with the message transfer agent component, providing for site customization of the specifics of mail delivery to a user.

[edit]Unix

On Unix-like systems, procmail and maildrop are the most popular MDAs. The Local Mail Transfer Protocol (LMTP) is a protocol that is frequently implemented by network-aware MDAs.[citation needed]

[edit]Invocation

The mail delivery agent is generally not started from the command line, but is usually invoked by mail delivery subsystems, such as a mail transport agent, or a mail retrieval agent.

[edit]List of message delivery agent software for Unix-like platforms

[edit]See also

[edit]References

  1. ^ RFC 5598, Internet Mail Architecture, D. Crocker (July 2009)
  2. ^ http://en.wikipedia.org/wiki/Dovecot_%28software%29





Email agent (infrastructure)

An email agent is a program that is part of the email infrastructure, from composition by sender, to transfer across the network, to viewing by recipient. The best-known aremail user agents (MUAs, aka, email clients) and mail transfer agents (MTAs, programs that transfer email between clients), but finer divisions exist.

More precisely, this is a technical way of referring to functions performed by various programs, considering them as software agents: a given program may perform several functions, but while it is performing a given function (such as mail transfer), it is referred to as a mail transfer agent. These terms are most often used within internet standards, and technical discussions of email infrastructure, not by end-users.

While the individual terms are widely used in internet standards and RFCs, there is no widely used umbrella term for these programs, though such a program may informally be referred to generically as an MxA, 'x' being a wildcard, as the programs are referred to by acronyms of this form, such as MUA and MTA, with 'x' depending on role.

[edit]Classification

The finest and most expansive classification in current use is into five functions:

The traditional division is into client-side (MUA) and server-side (MTA, notably sendmail), with the flow given as:

MUA → MTA → … → MTA → MUA,

Other divisions have been made to draw distinctions that some have found useful, which are detailed as follows.

A detailed flow of a message through these various agents is given at MuttWiki: MailConcept/Flow, and may be summarized as

MUA → MSA → MTA → … → MTA → MDA →→ MRA →→ MUA,

with the arrow styles changing to distinguish between push steps (→) and pull steps (→→).

Programs such as fetchmail which retrieve email from a server but do not provide a human interface for viewing or other client tasks are referred to as MRAs – they provideretrieval but no other client functions. Traditionally and in internet standards (such as the recent RFC 5598) these are referred to as a type of MUA, because they are client-side and hence outside the scope of internet standards, and indeed many MUAs perform MRA functions. However, traditional Unix email readers such as elm, Pine, or mutt would often not include MRA functions (or only optionally), reading email that had already been delivered to a mailbox file (formally, delivered by an MDA).

Broadly and traditionally, any program that transfers mail between the ends (all server-side functions) is an MTA. More finely and more recently, the endpoints of the chain have been distinguished, with the initial client-server step referred to as submission, and the final server-client step referred to as delivery. The motivation for distinguishing the MSA role has largely been security, with MUA-MSA interactions (initial submission) receiving greater scrutiny than MTA-MTA (server-server) transfers. The delivery (MDA) stage is where such tasks as filtering (of undesired emails) and filing (into separate folders) occur, and are the start of the user agent; traditionally this was done via procmail, while today it may be done via server-side programs, often using spam filters such as SpamAssassin. The MDA can be said to work "before the message hits the user's mailbox".

[edit]References





저작자표시

'System > Protocol' 카테고리의 다른 글

tcp - TIME_WAIT를 남기지 않는 세션종료 (Graceful Shutdown)  (0) 2013.07.02
POP & IMAP  (0) 2013.04.06
Posted by linuxism
,

티스토리툴바