Blue arrows can be implemented using SMTP variations.

telnet www.example.com 25

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

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

카테고리 :

• 전자 메일 프로토콜
• RFC
• 응용 프로그램 계층 프로토콜

출처 - 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 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)의 예

관련 항목 [ 편집 ]

• 메일 매거진
• 전자 메일 클라이언트 목록
• 사용자 에이전트
• 인터넷
• 웹 브라우저
• X-Face
• Outbound Port 25 Blocking (OP25B)

외부 링크 [ 편집 ]

• 영어권에서 mailer의 의미 (영어)

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.

[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

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

• E-mail authentication
• SMTP AUTH
• Simple Mail Transfer Protocol
• List of mail servers
• Comparison of mail servers
• Smart host
• E-mail agent (infrastructure) (MxA)
• Mail delivery agent (MDA)
• Mail transfer agent (MTA)
• Mail user agent (MUA)

[edit]References

• R. Gellens, J. Klensin, Message Submission for Mail, RFC 6409, April 2006. (obsoleted RFC4409, RFC 2476)
• J. Klensin, ed. Simple Mail Transfer Protocol. RFC 2821, April 2001.
• "SMTP is not secure". Kasoft Central. Retrieved 2008-06-14.

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).

[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

• bin/mail, the MDA part of Sendmail
• deliver
• fdm - A combined mail retrieval agent and mail delivery agent
• maildrop
• postdrop
• postfix-maildrop - A mail delivery agent for use with the postfix mail transport agent
• smtp, local, virtual - Postfix daemons
• procmail
• courier-maildrop
• dovecot - A mail server suite that includes a mail delivery agent
• dystill - A filtering MySQL database driven mail delivery agent
• Cyrus IMAP - A mail server suite that includes a mail delivery agent

[edit]See also

• Message transfer agent (MTA)
• Mail retrieval agent (MRA)
• Mail submission agent (MSA)
• Mail user agent (MUA) a.k.a. email client
• E-mail agent (infrastructure) (MxA)

[edit]References

Email agent (infrastructure)

리눅스 시스템 언어 설정 방법입니다.
콘솔에서 여기서 설정된 코드를 기준으로 문자를 뿌려줍니다.
즉 utf-8로 설정할 경우 utf-8로 뿌려주기 때문에 eucKR 콘솔에서는 깨져서 나옵니다.

파일은 /etc/sysconfig/i18n 입니다.

파일을 여시면

LANG="ko_KR.eucKR"
SUPPORTED="en_US.UTF-8:en_US:ko_KR.eucKR:ko_KR:ko"
SYSFONT="lat0-sun16"
SYSFONTACM="iso15"

이렇게 써있을 것 입니다.
한글 코드를 변환시키고 싶으시면 위에 밑줄 친 부분을 바꾸시면 됩니다.
ko_KR.utf-8  로 하셔도 되고요..
한글을 사용하는 곳에서는 보통 eucKR을 많이 사용합니다..
아직은 utf-8 을 많이 사용 안하는 듯 싶더라고요.

내용을 변경하셨으면

# source /etc/sysconfig/i18n   명령을 통해 설정내용을 적용 시켜주셔야 됩니다.

출처 - http://sofriend.tistory.com/28

의존의 scope: compile, runtime, provided, test

앞의 pom.xml 파일에서 <dependency> 부분을 보면 <scope>를 포함하고 있는 것과 그렇지 않은 것이 존재한다는 것을 알 수 있다. <scope>는 의존하는 모듈이 언제 사용되는 지를 설정할 때 사용되며, <scope>에 올 수 있는 값은 다음의 네 가지가 존재한다.

• compile - 컴파일 할 때 필요. 테스트 및 런타임에도 클래스패스에 포함된다. <scope>를 설정하지 않을 경우 기본 값은 compile 이다.
• runtime - 런타임에 필요. JDBC 드라이버 등이 예가 된다. 프로젝트의 코드를 컴파일 할 때는 필요하지 않지만, 실행할 때 필요하다는 것을 의미한다. 배포시 포함된다.
• provided - 컴파일 할 때 필요하지만, 실제 런타임 때에는 컨테이너 같은 것에서 기본으로 제공되는 모듈임을 의미한다. 예를 들어, 서블릿이나 JSP API 등이 이에 해당한다. 배포시 제외된다.
• test - 테스트 코드를 컴파일 할 때 필요. Mock 테스트를 위한 모듈이 예이다. 테스트 시에 클래스패스에 포함되며, 배포시 제외된다.

출처 - http://easymicro.egloos.com/5477280

Maven 2에서는 dependency를 가지는 대상에 대해서 다음과 같이 scope을 지정하고 있다.

Maven 2에서는 다음과 같이 POM에 설정된다.

기존 Maven1 에서는 이러한 설정이 없지만, Maven2로의 변경이나, Maven2로 만들어진 POM을 사용하는 경우에 유용하게 하기 위해서 다음과 같이 설정하면 된다.

</dependency>

출처 - http://homo-ware.tistory.com/43

source - https://blog.naver.com/PostView.naver?blogId=dktmrorl&logNo=222418137899&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView

메이븐의 scope는 compile, runtime, test, provided, system 이 있습니다. 이 중에서 custom jar를 관리하기 위해서 system scope를 지정해서 사용했었는데, war파일 패키징에서 누락되게 됩니다. WEB-INF/lib 폴더에 복사되지 않는다는 뜻입니다. 이 때문에 다음과 같이 코드를 작성했다면, in-project 저장소를 구성해서 변경하는 것이 좋습니다.

위 세팅을 다음과 같이 변경합니다.

libs 폴더 구성도 다음과 같이 바뀝니다.

참고: http://stackoverflow.com/questions/5597099/maven-add-jars-through-systempath-system-but-not-added-to-war-or-anywhere-else

source - https://okjsp.tistory.com/1165644118