이메일은 어떻게 작동합니까? 자신의 메일 서버를 만드는 방법 이메일이 작동하는 방식. 이메일 헤더 검사

메일 서버는 메일 요청을 처리하고 한 시스템에서 다른 시스템으로 메시지를 전송하는 특수 에이전트입니다.

전자 메일 서버는 봉투에 든 종이 메시지와 같이 바이트를 처리하는 우리에게 친숙한 실제 우체국 역할을 합니다.

친구에게 편지를 보내려면 내용을 작성하고 받는 사람의 이메일 주소를 표시하고 모든 데이터를 이메일 서버 주소로 전송해야 합니다. 전송 프로세스는 컴퓨터 또는 에서 자동화됩니다. 보내는 서버는 필요한 계산을 하고 서신을 받는 사람의 서버로 리디렉션하여 편지를 행복한 친구에게 보냅니다.



메일 서버 프로토콜이란

중단되지 않고 동기식으로 작동하기 위해 전 세계의 모든 메일 서버는 세 가지 주요 작업 프로토콜을 준수합니다.

SMTP Simple Mail Transfer Protocol 메일 보내기

SMTP라는 프로토콜은 항상 메일 전송을 담당하며, 첫 번째 버전은 1982년 표준에 설명되어 있습니다. 2008년에는 기능이 확장된 ESMTP 버전으로 업그레이드되었습니다. 클래식 프로토콜 접근 포트: 25 TCP, SSL 셸을 사용하는 경우 포트가 465 TCP로 변경됩니다.

SMTP 프로토콜이 작동하는 방식의 일반적인 예는 다음과 같은 일련의 작업입니다.

  • 컴퓨터의 이메일 클라이언트는 바인딩하도록 구성된 SMTP 서버와 연결을 설정합니다.
  • 서버는 귀하로부터 수신한 하나의 매개변수, 즉 수신자에만 관심이 있습니다. DNS 서비스에 쿼리하여 배달 IP 주소를 얻습니다.
  • SMTP 서버가 주소 공간에서 받는 사람의 위치를 ​​찾은 후 포트 25에서 받는 사람의 서버에 직접 연결을 시도합니다.
    받는 사람의 SMTP 서버는 데이터베이스에서 클라이언트의 존재를 확인하고 일치하는 경우 사용자의 사서함에 배치하기 위해 데이터를 내부 POP3 서버로 전송합니다.
  • 수신자의 SMTP 호스트에 연결하는 데 문제가 있는 경우 일정한 간격으로 몇 번 더 전송을 시도합니다. 거부하면 오류 메시지가 다시 수신됩니다.

POP3 우체국 프로토콜 3 메일 수신 및 저장

사서함에 대한 원격 액세스를 위한 최초의 클래식하고 간단한 프로토콜입니다. 이메일이 서버에 저장된다는 것은 비밀이 아니며 화면에 보이는 것은 로컬 사본일 뿐입니다. 1988년에 클라이언트가 서버에서 통신을 수집할 수 있는 프로토콜의 세 번째 최종 버전이 만들어졌습니다. 기본적으로 메시지는 POP3 프로토콜을 사용하여 로컬 저장소에 복사된 후 서버에서 영구적으로 삭제됩니다. 표준 액세스 포트: 110 TCP

POP3 서버가 있는 템플릿 세션을 고려하십시오.

  • 권한 부여. 접속한 클라이언트는 이름과 비밀번호로 인증 절차를 거칩니다. 이 이메일 주소가 그의 소유인지 확인합니다.
  • 거래. 우편함의 현재 상태에 대한 데이터 교환, 편지 수락 및 통신 작업이 있습니다.
  • 업데이트. 서버는 저장소에서 읽은 메시지를 제거하고 세션을 닫습니다.

고급 메일 처리 IMAP 인터넷 메시지 액세스 프로토콜

원격 메일 서버 작업을 위한 더 복잡하고 복잡하며 현대적인 프로토콜입니다. 1986년에 등장, 2003년 마지막 판의 볼륨이 크게 증가했습니다. POP3 통신과의 가장 큰 차이점은 작업이 모든 콘텐츠를 전송하지 않고 수행되고 서버에서 바로 정보를 편집할 수 있다는 것입니다. 프로토콜의 단점은 인터넷 연결이 끊겼을 때 메일을 사용할 수 없다는 것입니다. 일부 전문가들은 IMAP가 이메일을 보내는 기능을 평범하게 구현하지 않았다면 메일 프로토콜의 독점이 되었을 것이라고 생각합니다. 주 연결 포트: 암호화된 SSL 채널을 통해 연결할 때 143 TCP 또는 993 TCP.

IMAP 서버는 4가지 상태일 수 있습니다.

  • 인증 없이. 서버는 사용자의 로그인 및 비밀번호 전송을 기다리고 있습니다.
  • 인증됨. 추가 작업을 위해 사서함을 선택할 수 있습니다.
  • 선택 상태입니다. 우편함을 선택하면 그 안에 있는 편지 작업이 시작됩니다.
  • 출구. 오류 또는 클라이언트 요청으로 연결 닫기

자체 메일 서버

일반 사용자의 경우 Google, Yandex 등의 메일 서비스로 충분하지만 메일 포워딩 소프트웨어를 올려야 하는 포털 및 회사의 관리자에게는 훨씬 더 어렵습니다. 어떤 회사도 다른 사람의 도메인 이름으로 고객으로부터 주문을 받고 싶어하지 않을 것입니다. 즉, 자신의 메일 노드를 만들 때가 되었습니다. 여기에 몇 가지 옵션이 있습니다

준비된 솔루션

Yandex 및 MAIL.ru는 도메인에 무료 메일 제공업체 서비스를 제공합니다. 이것은 당신이 우편물을 받는다는 것을 의미합니다 [이메일 보호됨], 자신의 메일 서버를 수동으로 만든 경우에도 마찬가지였습니다. 그러나 회사는 편리한 웹 인터페이스와 직원을 위한 별도의 주소를 제공하여 통신 처리를 처리합니다.

또 다른 장점은 회사 메일 서버의 서버 주소가 항상 클라이언트의 신뢰에 있으므로 스팸에 들어갈 가능성이 훨씬 적다는 것입니다.

수동으로 자체 구성

이것은 어려운 길입니다. 이러한 서버를 설정하는 데 오랜 시간이 걸립니다. 그리고 특별한 회사에 연락하는 것이 더 쉽고 저렴할 것입니다.

Windows Server의 경우 클래식은 Microsoft Exchange Server입니다. Windows 환경에 완전히 통합되어 모든 프로토콜과 호환되며 빠르고 쉽게 설정할 수 있습니다.

Linux를 위한 여러 가지 본격적인 솔루션이 있지만 전문가들은 최근 Postfix 서버를 가장 안전하고 편리한 작업 방법으로 언급했습니다. 플러그인 가능한 스팸 필터, 건너뛴 메일 제어 및 데이터베이스 지원은 Postfix의 필수적인 부분입니다.

메일 서버(이메일 서버, 메일 서버)- 이메일 전달 시스템에서 일반적으로 메시지 전송 에이전트(영어 메일 전송 에이전트, MTA)의 이름입니다. 한 컴퓨터에서 다른 컴퓨터로 메시지를 전송하는 컴퓨터 프로그램입니다. 일반적으로 메일 서버는 "뒤에서" 작동하고 사용자는 다른 프로그램인 이메일 클라이언트(영어 메일 사용자 에이전트, MUA)를 처리합니다.

고유한 메일 서버를 구성하면 메일 메시지를 보내고 받는 정책을 보다 유연하게 구성할 수 있습니다. 메시지 설정 및 처리를 위한 메일 도메인 호스트의 기능은 제한적이지만 ICS 필터를 사용하면 다양한 상황을 시뮬레이션할 수 있을 뿐만 아니라 전송된 메시지의 기록 및 통계 등을 유지할 수 있습니다.

모듈에 들어가면 모든 메일 및 Jabber 서버 서비스의 상태와 "비활성화" 버튼(또는 서비스가 비활성화된 경우 "활성화")이 표시됩니다. 주요 작업 선택, 메일 통계 및 메일러 피드 그래프, 최신 로그 이벤트가 포함된 위젯도 있습니다.

설정

"설정" 탭에서 다음 메일 서버 설정을 정의할 수 있습니다.

SMTP/POP3/IMAP 포트- 메일 메시지 수신 및 전송을 위한 표준 포트를 변경할 수 있습니다.

SMTP/POP3/IMAP용 인터페이스- 메일 메시지를 받고 보내는 서버 인터페이스를 선택할 수 있습니다. 기본적으로 모든 인터페이스가 활성화되어 있습니다.

다음 필드를 사용하여 최대 메시지 크기(MB), IP 주소당 분당 최대 메시지 수, 전송 시도 간격, 메일 대기열의 최소 및 최대 대기 시간을 설정할 수 있습니다.

기본적으로 릴레이. 릴레이 - 메시지(이메일)를 수신/전달하는 노드로, 이 경우 ICS가 기본 역할을 합니다. 경우에 따라 ICS가 메일을 보낼 다른 서버를 등록해야 할 수도 있습니다(예: 공급자의 메일 서버에 구성된 멀티드롭 사서함의 경우).

전달이 허용되는 주소- 이것은 ICS가 정방향 및 역방향 레코드의 일치 여부를 그레이리스팅하고 확인하지 않고 항상 메일을 수락하는 주소 및 도메인 이름 목록입니다.

전달이 금지된 주소- 이것은 ICS가 항상 거부하는 메일 메시지, 주소 및 도메인 이름의 목록입니다.

RBL 블랙리스트. RBL, 실시간 블랙홀 목록(또는 DNSBL - DNS 블랙리스트 또는 DNS 차단 목록) - DNS 아키텍처 시스템을 사용하여 저장된 호스트 목록입니다. 일반적으로 스팸과 싸우는 데 사용됩니다. 메일 서버는 DNSBL에 액세스하여 메시지를 받는 클라이언트의 IP 주소가 있는지 확인합니다. 응답이 긍정적이면 스팸 메시지 수신을 시도하는 것으로 간주됩니다. 보낸 사람의 서버에 5xx 오류(치명적인 오류)가 보고되고 메시지가 수락되지 않습니다. 대부분의 경우 이 목록을 변경할 필요가 없습니다.

인증 기본 도메인사용자 권한 부여 중에 자동으로 대체될 메일 도메인을 정의합니다. 기본 도메인을 지정하면 이 도메인의 사용자는 도메인을 지정하지 않고 사서함 이름을 사용하여 로그인할 수 있습니다.

사서함 생성 시 자동으로 폴더 생성- 사서함에 생성된 표준 폴더 목록이 포함되어 있습니다. 필요한 경우 구성을 변경할 수 있습니다.

바이러스 백신 Clamav /Dr.Wed /Kaspersky로 메일 확인- 이 플래그를 설정하면 메일 서버에 신호를 보내 수신 및 발신 메시지에 바이러스가 있는지 확인합니다. 결과가 긍정적이면 편지 자체가 아닌 받는 사람에게 수표 결과에 대한 메시지가 표시되고 편지 자체가 메시지에 첨부됩니다.

그레이리스팅 사용. 그레이리스팅은 스팸 소프트웨어의 "동작"이 일반 이메일 서버의 동작과 다르다는 사실을 기반으로 스팸을 자동으로 차단하는 방법입니다. 받는 사람의 메일 서버가 편지 수락을 거부하고 "일시적인 오류"를 보고하는 경우 보낸 사람의 서버는 나중에 다시 시도해야 합니다. 스팸 소프트웨어는 일반적으로 이러한 경우에 이를 시도하지 않습니다. 향상된 메일 스팸 검사를 위해 이 모드를 활성화할 수 있습니다. 이 옵션을 활성화하면 그레이리스트 매개변수를 편집할 수 있게 됩니다. 재전송 무시 시간(초), 재전송 대기 시간(시간), 발신자를 허용 목록에 유지하는 시간(일).

SMTP용 서버 이름 SMTP 배너 접미사 옵션을 정의합니다.

SMTP/POP3/IMAP용 인증서- 다른 ICS 서비스와 마찬가지로 메일 서버는 파일을 전송할 때 데이터가 암호화되지 않는 표준 프로토콜(안전하지 않음)과 보안 프로토콜 모두에 따라 작동할 수 있습니다. 이러한 목적을 위해 SSL 인증서가 사용됩니다. […] 버튼을 클릭하면 해당 모듈에서 이전에 생성한 인증서를 프로토콜별로 할당할 수 있습니다.

DLP 사용- 기밀 정보의 지문으로 메일 메시지를 확인하는 서비스를 시작합니다.

메일 저장용 하드 드라이브메일 저장소를 별도의 하드 드라이브로 이동할 수 있습니다. 기본적으로 메일은 시스템 파티션에 저장됩니다.

서명웹 인터페이스의 경우 메일 서버 설정에서 활성화되어 있으므로 "서명 사용" 상자를 선택하고 "html 편집" 버튼을 클릭하여 열리는 창에 서명을 입력한 다음 설정을 저장해야 합니다.

서명은 wysiwyg 모드와 html 모드 모두에서 입력할 수 있습니다.

[변수 이름] 형식의 변수를 서명에 사용할 수 있으며 가능한 값은 다음과 같습니다.

Cn - 사용자 이름 ou - 그가 위치한 그룹 mail - 우편 주소 설명 - 사용자 메모의 "설명" 필드 - 사용자 전화번호의 "설명" 필드 - 사용자 제목의 "전화" 필드 - " 사용자 URL의 "위치" 필드 - 사용자 우편 주소의 "웹사이트" 필드 - 사용자 호출기의 필드 "주소" - 사용자 ounotes의 필드 "ICQ" - 그가 위치한 그룹의 필드 "설명"

이미지를 삽입하기 위해 data: url의 이미지 인코딩을 사용합니다. 이것은 다음과 같이 수행됩니다. http://dataurl.net/#dataurlmaker(또는 이와 유사한) 서비스를 사용하여 이미지가 형식으로 변환됩니다. , 결과 텍스트가 서명 html 코드에 삽입됩니다.

중요: Roundcube에서 이 메커니즘의 특징은 서명을 설정한 후 생성된 새 계정에 대해서만 서명이 자동으로 생성된다는 것입니다. 생성 후에는 서명을 자동으로 변경하는 것도 불가능하므로 생성 시 자동 서명을 신중하게 계획하십시오.

Roundcube 로고 업로드- 이 버튼을 사용하면 메일 웹 인터페이스의 왼쪽 상단 모서리에 위치할 이미지를 선택할 수 있습니다. 예를 들어 조직의 로고가 있습니다.

마지막 세 개의 확인란을 사용하면 DKIM 서명을 활성화하고, 수신 메시지의 DKIM을 확인하고, 이메일 헤더를 UTF-8로 자동 인코딩할 수 있습니다.

주소록

도메인 및 사서함

사용자 지정 사서함을 추가하려면 먼저 메일 도메인을 만들어야 합니다. "도메인 및 편지함" 탭으로 이동하여 "추가" → "메일 도메인" 버튼을 클릭하십시오. 메일 교환이 회사 네트워크 내에서 발생하는 경우 존재하지 않는 이름으로 도메인 이름을 지정할 수 있습니다. 또는 조직에 등록된 실제 도메인에서 메시지 전달을 설정할 수 있습니다. 설정에서 "DKIM 서명 만들기" 확인란을 선택하면 자동으로 추가됩니다.

생성된 계정을 다시 더블 클릭하면 이미 생성된 DKIM 키로 계정이 열리며 필요한 경우 복사할 수 있습니다.

그런 다음 생성된 도메인을 강조 표시하여 사용자 지정 사서함을 추가할 수 있습니다. 서버는 사서함 이름, 암호를 입력하고 이 사서함이 할당될 사용자를 선택하도록 요청합니다. 필요한 경우 할당량(이 사용자의 메시지를 저장하기 위해 ICS의 하드 디스크에 예약된 최대 공간)을 지정할 수 있습니다. 이 할당량을 초과하면 사용자에게 보내는 편지가 허용되지 않습니다. 기본적으로 할당량이 없습니다.

필요한 각 이메일 이름에 대해 별도의 사서함을 만들 필요는 없습니다. 대신 지정된 사서함에 대한 링크를 만들 수 있습니다. 그런 다음 상자에 오는 모든 문자 [이메일 보호됨], 실제 사서함으로 리디렉션됩니다. [이메일 보호됨]

중요: 메일 도메인 및 사서함을 생성할 때 해당 도메인 및 계정이 jabber 서버 섹션에 나타납니다. 그 반대도 사실입니다.

외부 네트워크에서 메일 도메인에 접근할 수 있고 다른 외부 서버와 데이터를 교환할 수 있으려면 DNS 레코드를 구성해야 합니다.

사용자의 사서함이 생성된 후 이메일 클라이언트(예: Mozilla Thunderbird 또는 Microsoft Outlook)를 사용하여 ICS에 연결하거나 다음을 사용할 수 있습니다. 메일용 웹 인터페이스.

"필터" 탭은 보내고 받은 메시지를 처리하는 데 사용됩니다. 크기, 발신자, 수신자, 제목 등의 조건에 따라 메일을 처리합니다. 조건은 엄격하거나 엄격하지 않을 수 있습니다. 조건의 수는 제한이 없지만 필터는 모든 조건이 완전히 일치할 때와 첫 번째 일치가 발생할 때 메일을 모두 처리할 수 있습니다. 조건이 일치하면 필터가 메시지를 삭제하거나 다른 사서함으로 이동하거나 복사본을 만들 수 있습니다.

위의 예에서 크기가 5000kB 이상이고 편지 제목에 "스팸 아님"이라는 표현이 포함된 동일한 주소로 보낸 모든 편지는 다른 ICS 사서함으로 복사됩니다.

새 필터를 생성하려면 먼저 트리거 조건을 선택해야 합니다. 모든 조건이 일치하는 경우 조건 중 하나를 선택하거나 조건에 관계없이 모든 메시지에 적용합니다.

이메일 제목, 발신자, 수신자 및 크기(KB)별로 수신 및 발신 이메일을 필터링할 수 있습니다. 조건 일치를 확인하는 것은 엄격하거나("다음과 일치") 엄격하지 않을 수 있으며("포함", "다음으로 시작", "다음으로 끝남") 역("포함하지 않음")입니다. 하나의 필터에 여러 조건을 할당할 수 있습니다.

마지막 단계는 필터가 트리거된 후 수행할 작업을 선택하는 것입니다. 편지를 이동하거나 다른 주소로 복사하거나 삭제할 수 있습니다. 처음 두 조건에서는 사서함 이름을 입력하거나 ICS에서 만든 목록에서 선택할 수 있습니다.

필터를 구성할 수 있는 방법에 대한 예는 을 참조하십시오.

메일링은 동일한 필터이지만 메일링이 배포될 메일박스를 표시하기에 충분한 단순화된 인터페이스가 있습니다. 원본 편지가 시스템에 도착한 상자는 링크이므로 열면 안됩니다.

안티스팸

다른 서버에 있는 메일 계정을 관리하려면 ICS "메일 수집기" 기능을 사용할 수 있습니다. 도움을 받아 ICS는 선택한 로그인 및 비밀번호로 지정된 메일 서버에 연결하고 포함된 메일을 ICS 사용자의 사서함으로 이동하거나 복사합니다.

서버에서 메시지로 수행할 작업을 지정할 수 있습니다. 모두 수집, 새 메시지만 수집, 서버에 메시지 남기기 또는 삭제하기. 수집기의 간격 및 세션당 다운로드되는 문자 수도 설정됩니다.

자동 수신자 감지 및 조립용 사서함 지정의 두 가지 모드에서 작동합니다. 조직에 공급자의 서버에 하나의 외부 사서함이 있고 나머지 사서함이 별칭으로 사용되는 경우 자동 검색이 작동합니다. 다른 경우에는 조립 상자의 직접 표시가 사용됩니다. 즉, 대부분의 경우 수집기를 만들 때 스위치를 "Forward to" 위치로 설정해야 합니다.

메일 수집기는 조직에서 소위 "멀티드롭" 메일 방법을 사용하는 경우에도 사용할 수 있습니다. 모든 메일이 공급자 또는 호스트의 서버로 와서 사용자 사서함으로 분할되지 않고 거기에 저장된다는 사실로 구성됩니다. 이 경우 메일 수집기를 설정할 때 "받는 사람" 필드를 변경할 필요가 없습니다(기본값은 받는 사람 주소). 따라서 수집된 편지는 ICS 사용자의 사서함에 있는 받는 사람에 따라 자동으로 배포되며, 해당 받는 사람이 없을 경우 기본적으로 선택된 사서함에 추가됩니다.

메일 대기열

이 탭에는 전송 대기 중이거나 어떤 이유로 전송되지 않은 메시지가 표시됩니다(예: 업스트림 메일 서버의 그레이리스트에 의해 거부됨). 목록에서 개체를 선택하면 배달되지 않은 오류 코드를 볼 수 있습니다. "대기열 지우기" 및 "모두 보내기" 버튼을 사용하여 메일 대기열을 관리할 수 있습니다. 또한 각 편지를 개별적으로 보내거나 대기열에서 제거할 수 있습니다.

통계

스팸 및 원치 않는 이메일은 물론 수신 및 발신 메일 트래픽을 제어하려면 "통계" 섹션을 사용할 수 있습니다.

또한 사용자 통계에서와 같이 제어판에서 ICS 메일 트래픽에 대한 일반 정보에 다양한 필터를 적용하여 표로 표시할 수 있습니다. 테이블 열은 적용된 필터에 따라 다릅니다.

보고서 생성기는 사용자 통계와 매우 유사합니다. 기본 필터는 다음 기준에 따라 그룹화하여 사용자 트래픽에 대한 정보를 표시할 수 있습니다.

    발신자 도메인별,

    수신자 도메인별,

    우편함으로,

    시간/일/월,

    편지의 세부 사항;

잡지

로그 탭에는 메일 서버의 모든 시스템 메시지 요약이 포함됩니다. 잡지는 페이지로 나뉘며 "앞으로" 및 "뒤로" 버튼을 사용하여 페이지에서 페이지로 이동하거나 필드에 페이지 번호를 입력하고 즉시 전환할 수 있습니다.

로그 항목은 메시지 유형에 따라 색상으로 강조 표시됩니다. 일반 시스템 메시지는 흰색으로 표시되고 오류는 빨간색으로 표시됩니다.

모듈의 오른쪽 상단 모서리에 검색 표시줄이 있습니다. 이를 통해 필요한 항목에 대한 로그를 검색할 수 있습니다.

로그는 항상 현재 날짜에 대한 이벤트를 표시합니다. 다른 날의 이벤트를 보려면 모듈의 왼쪽 상단 모서리에 있는 달력을 사용하여 원하는 날짜를 선택하십시오.

사우스 우랄 주립 대학교

미아스 기계공학부

품질경영표준화학과

코스 작업

정보학

"메일 서버" 주제에 대해

소개 _____________________________________________________________________________________3

메일 서버 __________________________________________________________________________4

이메일 _______________________________________________________________________________________5

이메일 주소 구조 __________________________________________________________6

도메인이란 _________________________________________________________________7

기호의 역사 @________________________________________________________________9

이메일 소프트웨어 __________________________________________________________________________________11

Mail.ru__________________________________________________________________________________________________12

야후! 메일 ________________________________________________________________________________15

Rambler.ru __________________________________________________________________________________17

주요 이메일 클라이언트 __________________________________________________________________17

결론 ________________________________________________________________________________18

참조 _____________________________________________________________________________________19

소개

고대에도 사람들은 정보를 교환하고 국가 차원에서 조직화해야 할 필요성을 느꼈습니다. 따라서 우체국은 세계에서 가장 잘 조직된 기관 중 하나입니다.

전자 메일은 정보 전송의 새로운 현대적인 수단입니다. 일반 우편과 달리 메시지, 파일, 프로그램, 다양한 데이터의 전자 사본은 전자 메일을 통해 전송됩니다. 컴퓨터가 처리하는 정보.

이메일 시스템을 구성하는 주요 개체는 메일 서버라고 하는 특수 컴퓨터입니다.

메일 서버

메일 서버는 이메일 메시지를 받고 보내는 서버입니다.

이메일 메시지를 수신하는 서버는 POP(Post Office Protocol) 프로토콜을 사용합니다.

이메일을 보내는 서버는 SMTP(Simple Mail Transfer Protocol) 프로토콜을 사용합니다.

메일 서버, 메일 서버, 메일 서버- 이메일 전달 시스템에서 일반적으로 메시지 전달 에이전트의 이름(eng. 메일 전송 에이전트, MTA). 한 컴퓨터에서 다른 컴퓨터로 메시지를 전송하는 컴퓨터 프로그램입니다. 일반적으로 메일 서버는 "뒤에서" 작동하며 사용자는 다른 프로그램인 이메일 클라이언트(eng. 메일 사용자 에이전트, MUA).

상호 작용 방식

예를 들어, 일반적인 구성에서 사용자 에이전트는 Outlook Express입니다. 사용자가 메시지를 입력하고 받는 사람에게 보낼 때 메일 클라이언트는 SMTP 프로토콜을 사용하여 메일 서버와 통신합니다. 보낸 사람의 메일 서버는 받는 사람의 메일 서버와 상호 작용합니다(직접 또는 중간 릴레이 서버를 통해). 받는 사람의 메일 서버에서 메시지는 사서함으로 들어가고, 여기에서 메시지 배달 에이전트(MDA)를 사용하여 받는 사람의 클라이언트로 배달됩니다. 특히 스팸 필터링을 처리하는 특수 MDA가 있지만 마지막 두 에이전트가 하나의 프로그램에 결합되는 경우가 많습니다. 수신된 메시지의 최종 배달을 위해 사용되는 것은 SMTP가 아니라 대부분의 메일 서버에서도 지원되는 다른 프로토콜(종종 POP3 또는 IMAP)입니다. MTA의 가장 간단한 구현에서는 수신된 메시지를 중앙 서버의 파일 시스템("사서함")에 있는 사용자의 개인 디렉터리에 넣는 것으로 충분합니다.

이메일

전자 메일(이메일, 라틴어 "전자 메일"에서).

전자 메일은 일반 메일과 마찬가지로 전자 "우체국" 시스템과 함께 작동합니다. 즉, 글로벌 네트워크를 통해 메일을 전달하는 메일 서버입니다. 그들은 네트워크에서 전송되는 정보의 전달 및 인식을 제공하는 메일 프로토콜을 사용하여 상호 작용합니다. 메일 서버 클라이언트 컴퓨터는 이메일 사용자에게 서비스를 제공합니다. 모든 사람은 이 컴퓨터에서 자신의 우편 주소와 "사서함"을 얻습니다. 메모리 영역 및 액세스 암호.


메일 프로그램의 도움으로 메시지 작성, 메일 서버에서 읽기, 주소록 작업, "mailbox" 폴더에 편지 저장 및 구성, 보낼 파일 준비 및 수신 후 원하는 형식으로 변환, 등.

메일 프로그램을 사용하여 사용자는 수신자에게 메시지를 작성하고 주소를 설정하고 메시지를 보내 메일 서버에 연결합니다. 연결하는 동안 메일 서버는 사용자 이름과 암호를 묻습니다. 그렇지 않으면 세션이 진행되지 않습니다. 연결 후 준비된 메일은 자동으로 서버로 전송되고, 한 메일 서버에서 다른 메일 서버로의 전송을 통해 수신자에게 도달합니다. 서신을 보낸 직후 메일은 클라이언트에 의해 자동으로 수신됩니다. 메모리 영역으로 읽은 메시지와 파일은 사용자 사서함에 정렬 및 정렬됩니다. 받는 사람은 사서함을 로드할 때 새 메시지, 이전 메시지, 보낸 메시지 폴더로 정렬된 메시지를 봅니다. 그는 적절하다고 생각하는 대로 그것들을 삭제, 정렬 및 분류할 수 있습니다.

이메일 주소 구조

정보를 보낼 때 주소 지정이 없으면 수신자를 찾을 수 없기 때문에 주소 지정이 매우 중요합니다. "할아버지 마을에"편지를 보낸 Vanka Zhukov의 슬픈 이야기는 누구나 알고 있습니다. 일반 우편 주소는 특정 우편 규칙에 따라 발행됩니다.

기존의 이메일 주소 발급 규칙은 다릅니다. 이메일 주소는 논리적 구조가 더 명확합니다. 도메인의 계층적 시퀀스로 구성됩니다. 예를 들면 다음과 같습니다.

[이메일 보호됨]

[이메일 보호됨]

[이메일 보호됨]

모든 주소는 @ 기호("at"로 읽음)로 구분된 두 부분으로 구성됩니다. 이 문자까지 왼쪽에서 오른쪽으로 읽으면 사용자(받는 사람)의 이름이 표시됩니다. 이것은 우체국 책임자의 이름일 수 있습니다 - "우체국 책임자"(우체국 책임자), 서신이 도착하는 이메일 사용자의 가상 또는 실제 이름입니다. 같은 컴퓨터에 여러 개 등록될 수 있습니다. @ 오른쪽 주소 부분은 네트워크에 연결된 컴퓨터, 도시 및 국가 또는 사용자가 등록된 네트워크 이름을 식별합니다. 주소는 도메인이라는 부분으로 나뉩니다.

도메인이란?

오른쪽에서 왼쪽으로 도메인을 고려하고 지점별로 별도의 단어로 나누면 이 사서함을 찾을 위치를 하나씩 지정하는 하위 도메인이 생깁니다. 일반 우편과 유사하게 도메인은 주소(봉투의 "받는 사람" 줄)이고 하위 도메인은 국가, 도시, 거리, 집 번호의 이름입니다.

도메인은 메시지를 보내야 하는 경로를 설명하지 않고 수신자가 있는 위치만 설명합니다. 마찬가지로 우편 봉투의 주소는 우편 배달부가 편지를 배달하기 위해 거쳐야 하는 길이 아니라 최종적으로 배달해야 하는 장소에 대한 설명입니다. 두 경우 모두 시간과 비용을 절약하기 위해 우편 서비스 자체에서 경로를 선택합니다. 일반적으로 지정된 장소에 메시지를 전달할 수 있는 방법은 여러 가지가 있는데, 편지를 보낼 때 이번에는 어떤 방향으로 갈지 모릅니다.

맨 오른쪽 하위 도메인(이 경우 ru)은 최상위 도메인이라고 하며 가장 자주 서버가 위치한 국가의 코드를 나타냅니다. 코드 ru는 러시아, kz는 카자흐스탄입니다. 각 코드는 두 개의 라틴 문자로 구성됩니다. 예를 들어, 코드 uk는 Great Britain을 나타내고 우편함에는 주소가 있습니다. [이메일 보호됨]영어 네트워크 JANET에서 검색해야 합니다.

최상위 도메인이 항상 국가 코드는 아닙니다. 예를 들어 미국에는 edu(과학 및 교육 기관) 또는 gov(정부 기관)와 같은 최상위 도메인이 있습니다.

[이메일 보호됨] rge.arc.nasa.gov

메일 서비스가 도메인 오른쪽에 이러한 종류의 하위 도메인이 있는 경우 수신자가 미국에 있다는 것을 이미 알고 있으므로 미국 국가 코드가 필요하지 않습니다. 이러한 지정은 다른 국가의 네트워크와 연결되기 전에도 미국 과학 네트워크 ARPANET에서 개발되었으며 이제는 습관적으로만 유지됩니다. 일반적으로 조직 유형별로 주소가 지정된 모든 장소는 국가 코드를 사용하여 연결할 수 있습니다. 단순성과 일관성을 위해 국가 코드와 함께 주소를 사용하는 것이 좋습니다.

일반적으로 이러한 주소는 해당 네트워크가 RFC822가 아닌 다른 형식의 주소를 이해하는 경우 사용됩니다. 그런 다음 [email protected]와 같은 주소를 작성하면 네트워크와 수신자 네트워크 사이의 브리지가 이를 원하는 형식으로 변환합니다.

최상위 도메인의 오른쪽에 위치한 하위 도메인은 이 도메인(ru의 경우 러시아 내부, mil의 경우 미군 조직, 또는 bitnet의 경우 BITNET 네트워크) 내에서 수신자의 위치를 ​​지정합니다. 예를 들어 주소에서 [이메일 보호됨] demos 하위 도메인은 러시아 내의 조직을 나타내고 hq는 데모 내의 머신 그룹을 나타냅니다.

주소에서 [이메일 보호됨] gov 최상위 도메인은 수취인이 미국 정부 기관 중 하나에 있음을 의미합니다. 첫 번째 nasa 하위 도메인은 어느 것이 NASA인지 지정하고, 두 번째 arc 하위 도메인은 NASA 부서(Ames Research Center)의 이름을 지정하고, George는 특정 시스템을 가리킵니다. 이 부문에서.

문자가 보내져야 하는 네트워크 이름으로 주소가 지정되는 경우 주소(도메인)는 최상위 도메인(네트워크 이름 및 하나 이상의 하위 도메인)으로만 구성됩니다. . 이 기계가 있는 위치를 찾는 것은 이 네트워크의 우편 서비스에 속합니다.

예를 들어 주소에 도달해야 하는 경우 욱스. . UIUC. 교육, 컴퓨터는 주소로 변환해야 합니다. 이를 위해 컴퓨터는 이름의 오른쪽에서 시작하여 왼쪽으로 이동하여 DNS 서버(컴퓨터)에 도움을 요청하기 시작합니다. 먼저 로컬 DNS 서버에 주소를 찾도록 요청합니다. 여기에는 세 가지 가능성이 있습니다.

소개

고대에도 사람들은 정보를 교환하고 국가 차원에서 조직화해야 할 필요성을 느꼈습니다. 따라서 우체국은 세계에서 가장 명확하게 조직된 기관 중 하나입니다.

전자 메일은 정보 전송의 새로운 현대적인 수단입니다. 일반 우편과 달리 메시지, 파일, 프로그램, 다양한 데이터의 전자 사본은 전자 메일을 통해 전송됩니다. 컴퓨터가 처리하는 정보.

이메일 시스템을 구성하는 주요 개체는 메일 서버라고 하는 특수 컴퓨터입니다.

메일 서버

메일 서버는 이메일 메시지를 받고 보내는 서버입니다.

이메일 메시지를 수신하는 서버는 POP(Post Office Protocol) 프로토콜을 사용합니다.

이메일을 보내는 서버는 SMTP(Simple Mail Transfer Protocol) 프로토콜을 사용합니다.

메일 서버, 전자 메일 서버, 메일 서버 - 전자 메일 전달 시스템에서 일반적으로 메시지 전송 에이전트(영어 메일 전송 에이전트, MTA)의 이름입니다. 한 컴퓨터에서 다른 컴퓨터로 메시지를 전송하는 컴퓨터 프로그램입니다. 일반적으로 메일 서버는 "뒤에서" 작동하고 사용자는 다른 프로그램인 이메일 클라이언트(영어 메일 사용자 에이전트, MUA)를 처리합니다.

쌀. 하나.

예를 들어, 일반적인 구성에서 사용자 에이전트는 Outlook Express입니다. 사용자가 메시지를 입력하고 받는 사람에게 보낼 때 메일 클라이언트는 SMTP 프로토콜을 사용하여 메일 서버와 통신합니다. 보낸 사람의 메일 서버는 받는 사람의 메일 서버와 상호 작용합니다(직접 또는 중간 서버 - 릴레이). 받는 사람의 메일 서버에서 메시지는 사서함으로 들어가고, 여기에서 메시지 배달 에이전트(MDA)를 사용하여 받는 사람의 클라이언트로 배달됩니다. 특히 스팸 필터링을 처리하는 특수 MDA가 있지만 마지막 두 에이전트가 하나의 프로그램에 결합되는 경우가 많습니다. 수신된 메시지의 최종 전달은 SMTP가 아니라 대부분의 메일 서버에서도 지원되는 다른 프로토콜(대개 POP3 또는 IMAP)입니다. MTA의 가장 간단한 구현에서는 수신된 메시지를 중앙 서버의 파일 시스템("사서함")에 있는 사용자의 개인 디렉터리에 넣는 것으로 충분합니다.

많은 시스템 관리자는 전자 메일 시스템으로 작업할 때 특정 문제를 경험합니다. 이것은 놀라운 일이 아닙니다. 메일 서버는 파일 서버, 라우터 또는 터미널 서버보다 훨씬 더 복잡한 구조를 가지고 있습니다. 이 기사에서는 이메일 시스템을 설정하는 것이 탬버린과 함께 무속 춤으로 변할 수 있는 것을 이해하지 않고 메일 서버의 구조와 작동 원리를 고려할 것입니다.

이 자료에는 시스템 관리자에게 필요한 최소한의 지식을 제공하기 위해 상당히 많은 단순화 및 일반화가 포함되어 있습니다. 우리의 의견으로는 하나 또는 두 개의 보급형 메일 서버를 관리하기 위해 전자 메일 전문가가 될 필요가 전혀 없습니다.

대부분의 사용자와 초보 관리자에게 메일 서버는 일종의 "블랙박스"로, 편지를 받은 후 "알 수 없는" 방식으로 수신자에게 전달하거나 그 반대의 경우도 마찬가지입니다. 이러한 서버와의 모든 상호 작용은 메일 클라이언트를 특정 포트 또는 웹 인터페이스를 통해 주소 지정하는 것으로 구성됩니다. 그러나 내부에는 전체 메커니즘이 숨겨져 있으며 전자 메일 시스템을 성공적으로 설정하고 유지 관리하기 위해서는 작동을 이해하는 것이 중요합니다. 이것은 Linux 플랫폼에서 서버를 관리하는 데 특히 중요합니다. 메일 서버가 완전한 소프트웨어 솔루션이고 개발자가 이미 내부 상호 작용을 처리한 Windows와 달리 Linux에서는 메일 서버 구성 요소가 별도의 프로그램이며 상호 작용을 직접 구성해야 합니다.

메일 서버의 구조와 사용자가 메일을 보내려고 하면 어떻게 되는지 살펴보자.

메일 서버에서 가장 중요한 부분은 MTA (메일 전송 에이전트-- 메일 전달 에이전트)의 작업에는 메일 수신 및 전송이 포함됩니다. 매우 자주(Linux/UNIX에서) MTA는 메일 서버라고도 합니다. MTA는 SMTP 프로토콜에서 작동하며 그 중 하나는 원칙적으로 이미 전자 메일 시스템을 만드는 데 충분합니다. 옛날 옛적에 이것이 사실이었고 사서함에 액세스하려면 특정 기술 지식이 필요했습니다.

그러나 진행 상황은 멈추지 않습니다. 편지를 받은 MTA는 편지를 사용자가 액세스해야 하는 서버의 사용자 사서함에 가장 간단하고 이해하기 쉬운 방법으로 배치합니다. 여기 무대가 온다 MDA (메일 배달 에이전트-- 메일 배달 에이전트)의 작업은 메일 클라이언트의 요청에 따라 서버의 사서함에서 메일을 전송하는 것입니다. MDA는 POP3 또는 IMAP 프로토콜을 사용하여 작동할 수 있으며 경우에 따라 메일 클라이언트와 배달 에이전트를 "통신"하기 위해 MAPI(Exchange Server)와 같은 확장 기능이 있는 자체 프로토콜을 사용할 수 있습니다.

일반적인 오해와 달리 MDA는 메일 전송 프로세스와 관련이 없습니다. 이것은 MTA의 특권입니다. 비유를 하자면, MTA는 우편물을 받고 보내는 우체국으로 생각할 수 있고, MDA는 들어오는 서신을 집으로 가져오는 우편 배달부를 말합니다. 우편 배달부가 아프면 우체국 업무에 영향을 미치지 않으며 집에서 편지를받지 못할 것입니다. 또한 MDA의 실패는 메일 서버의 작동 불능으로 이어지지 않으며 메일 클라이언트에 의한 메일 수신만 사용할 수 없게 되며 동시에 예를 들어 웹 인터페이스를 통해 다른 방법으로 쉽게 액세스할 수 있습니다.

메일을 보낼 때 어떤 일이 일어나는지 봅시다. 이 예에서 example.org 도메인( [이메일 보호됨]), 도메인 example.com( [이메일 보호됨]). Ivanov의 경우 메일을 보내는 프로세스는 메시지를 만들고 메일 클라이언트에서 "보내기" 버튼을 누르는 것으로 구성됩니다. 메일 클라이언트는 SMTP 프로토콜을 사용하여 MTA에 연결하고 먼저 자격 증명을 전달합니다. 사용자에게 권한을 부여한 후 MTA는 메시지를 수락하고 추가 전달을 시도합니다.

실제로 승인은 MTA의 필수 절차는 아니지만 승인 없이는 공개 릴레이, 즉 누구나 우리 서버를 사용하여 메일을 보낼 수 있으며 스패머는 기뻐할 것입니다! 현재 오픈 릴레이는 주로 서버 구성 오류로 인해 발생합니다. 그러나 MTA가 승인 없이 신뢰할 수 있는 사용자(예: 회사의 로컬 네트워크)로부터 메일을 수신할 수 있습니다.

MTA는 인증을 위해 자체 사용자 목록, 시스템 목록, LDAP 또는 AD 사용자 목록을 사용할 수 있습니다. 또한 방법이 있습니다. SMTP 전에 POP 인증, 사용자가 메일을 보내기 전에 MDA에 로그인하면 MTA에 대한 사용자 인증이 확인됩니다.

MTA의 다음 단계는 편지의 서비스 정보를 분석하여 받는 사람의 도메인을 결정합니다. 편지가 MTA에서 서비스하는 도메인에 속하는 경우 받는 사람을 검색하여 편지를 그의 사서함에 넣습니다. Ivanov가 Petrov 또는 Sidorov에게 편지를 썼다면 이런 일이 일어났습니다.

받는 사람의 도메인이 MTA에서 제공되지 않는 경우 해당 도메인에 대한 MX 레코드를 요청하는 DNS 쿼리가 생성됩니다. MX 레코드는 특정 도메인의 수신 메일을 처리하는 메일 서버의 이름을 포함하는 특별한 종류의 DNS 레코드입니다. 둘 이상의 MX 레코드가 있을 수 있으며, 이 경우 MTA는 우선 순위가 가장 높은 서버부터 시작하여 순차적으로 연결을 설정하려고 합니다. MX 레코드가 없으면 A 레코드(도메인 이름을 IP 주소에 매핑하는 주소 레코드)가 요청되고 거기에 지정된 호스트로 메일을 배달하려고 시도합니다. 메시지를 보낼 수 없으면 오류 메시지와 함께 보낸 사람(사용자의 사서함에 있음)에게 반환됩니다.

우리는 수신 서버의 작업을 고려하지 않고 모든 것이 잘 진행되었다고 가정하고 Kozlov가 Ivanov로부터 편지를 받고 응답을 썼습니다. example.com 도메인을 제공하는 서버는 똑같은 일을 하고 우리 서버로 메일을 보내려고 합니다. 들어오는 메시지를 받으면 MTA는 로컬 발신자의 경우와 같이 받는 사람의 도메인을 확인합니다. 서비스되는 MTA에 있으면 메시지 처리가 계속되고, 그렇지 않으면 서버가 메일 수락을 거부합니다. 도메인을 확인한 후 수신자를 확인하고 사용자 목록에 있으면 메시지가 자신의 사서함으로 배달되고 그렇지 않으면 메시지 수신 거부 또는 일반 사서함(관리자 사서함)에서 메시지 수신의 두 가지 옵션이 있습니다. ). 한편으로 이 설정은 수신된 스팸의 수를 늘리고 다른 한편으로는 철자가 잘못된 주소를 가진 편지를 잃지 않도록 합니다.

또 다른 스팸 방지 조치는 PTR 기록을 요청하는 것입니다. PTR 레코드(포인터 레코드)는 IP 주소를 도메인 이름과 연결합니다. PTR을 요청할 때 MTA는 보낸 사람의 도메인이 보내는 서버의 도메인과 일치하는 경우에만 메일을 수락합니다.

예를 더 자세히 살펴보겠습니다. 일부 spam.com 서버가 우리에게 알려진 example.com 서버에서 보낸 가짜 발신자에게 이메일을 보내려고 합니다. 화이트/블랙 리스트로 필터링하는 경우 보낸 사람이 신뢰할 수 있는 도메인(스패머가 믿고 있던 도메인)의 사용자이기 때문에 이러한 편지가 배달됩니다. 스팸을 방지하기 위해 MTA는 보내는 서버의 IP 주소에 대한 PTR 요청을 생성하고 SMTP 세션 중에 이를 보고합니다. 주소 y.y.y.y의 경우 PTR 요청은 보낸 사람의 도메인과 일치하지 않는 spam.com 도메인 이름을 반환하므로 메시지가 거부됩니다. 동시에 x.x.x.x(example.com)에 대한 PTR 레코드의 도메인이 보낸 사람의 도메인과 일치하기 때문에 서버 x.x.x.x에서 메시지가 수신됩니다.

따라서 메시지가 수신되었으며 사용자의 사서함에 있습니다. 그것을 읽는 방법? 사용자 상자가 있는 메일 저장소는 평범한 폴더와 파일에서 데이터베이스에 이르기까지 다양한 방식으로 구성될 수 있습니다. 기술 지식이 없으면 자신의 메일을 읽을 수 없을 것입니다. 그러나 사용자 Ivanov가 이에 대해 걱정해야 합니까? 그를 위해 메일 수신 프로세스는 메일 클라이언트에서 "받기" 버튼을 누르는 것으로 축소됩니다.

메일을 수신하기 위해 클라이언트는 POP3 또는 IMAP 프로토콜을 통해 MDA와 연결을 설정하고 반드시 인증을 위해 데이터를 전달해야 합니다. MDA는 사용자가 목록에 있는지 확인하고 성공하면 클라이언트에게 사서함의 모든 새 메시지를 보냅니다. 사용자 Ivanov는 그의 서신을 받고 편리한 방식으로 작업할 수 있습니다.

이것이 우리 기사가 끝나는 곳이며, 여기에 제시된 자료를 사려 깊게 읽고 동화할 것을 강력히 권장합니다. 앞으로 메일 서버의 실제 구현을 고려할 때 독자가 최소한 이 기사의 양에 대한 지식을 가지고 있다는 것을 기준으로 자료를 제출할 것입니다.



관련 기사: