이메일 작동 방식

이것은 메일 서버 작업에 관한 대규모 과정의 시작입니다. 내 목표는 누군가에게 메일 서버 작업 방법을 빨리 가르치는 것이 아닙니다. 나는 주로 첫발을 내딛는 사람들을 위해 코스를 만들려고 노력하고 있기 때문에 우리가 도중에 직면하게 될 질문에 관한 많은 추가 정보가 여기에 있을 것입니다.

머리말마침 제가 리눅스 관리 교사로 시간제로 일하게 되었습니다. 그리고 숙제로 학생들에게 다양한 리소스에 대한 XNUMX개의 링크를 제공합니다. 어떤 곳에서는 자료가 충분하지 않고 다른 곳에서는 너무 복잡하기 때문입니다. 그리고 다른 리소스에서는 자료가 종종 복제되고 때로는 분기되기 시작합니다. 또한 대부분의 내용이 영어로 되어 있어 이해하는데 어려움을 겪는 학생들도 있습니다. Semaev와 Lebedev 및 아마도 다른 사람들의 훌륭한 코스가 있지만 제 생각에는 일부 주제는 충분히 다루지 않았고 일부는 다른 주제와 충분히 연결되지 않았습니다.

그래서 어느 날 나는 어떻게든 자료에 메모를 하고 학생들에게 편리한 형태로 전달하기로 결정했습니다. 하지만 내가 뭔가를 하고 있으니 모두와 공유해 보는 건 어떨까요? 처음에는 텍스트로 만들고 링크로 희석하려고 했는데 그런 리소스가 수백만 개나 있는데 무슨 의미가 있나요? 명확성과 설명이 부족한 곳, 학생들이 너무 게으른 곳에서 (그들뿐만 아니라) 전체 텍스트를 읽지 못하고 지식에 격차가 있는 곳도 있습니다.

하지만 이는 학생들만의 문제가 아닙니다. 저는 경력 전반에 걸쳐 IT 통합업체에서 일했는데, 이는 다양한 시스템을 다루는 데 있어서 엄청난 경험이었습니다. 그 결과 저는 종합엔지니어가 되었습니다. 저는 다양한 회사의 IT 전문가를 자주 만나는데, 그들의 지식에 격차가 있다는 것을 자주 발견합니다. IT 분야에서는 저를 포함해 많은 사람들이 독학을 하고 있습니다. 그리고 나에게는 이러한 격차가 충분하며, 다른 사람들과 나 자신이 이러한 격차를 없애도록 돕고 싶습니다.

저는 정보가 담긴 짧은 영상이 더 흥미롭고 소화하기 쉽기 때문에 이 형식을 사용해 보기로 했습니다. 그리고 나는 내 혀가 정지되지 않았고 내 말을 듣는 것이 어렵지만 더 나아지려고 노력하고 있다는 것을 잘 알고 있습니다. 이것은 제가 개발하고 싶은 새로운 취미입니다. 예전에는 마이크가 더 나빴는데 이제는 주로 소리와 음성 문제를 해결합니다. 양질의 콘텐츠를 만들고 싶고 객관적인 비판과 조언이 꼭 필요합니다.

PS 영상 형식이 전혀 적합하지 않고 텍스트로 하는 것이 더 낫다고 생각하는 분들도 계셨습니다. 전적으로 동의하지는 않지만 비디오와 텍스트 모두 선택 가능합니다.

비디오

다음> 메일 서버 작동 모드

이메일로 작업하려면 이메일 클라이언트가 필요합니다. 이는 gmail, owa, roundcube와 같은 웹 클라이언트이거나 컴퓨터의 응용 프로그램(outlook, Thunderbird 등)일 수 있습니다. 이미 일부 이메일 서비스에 등록했고 이메일 클라이언트를 설정해야 한다고 가정해 보겠습니다. 프로그램을 열면 계정 이름, 이메일 주소, 비밀번호 등의 데이터를 묻는 메시지가 나타납니다.

이 정보를 입력하면 이메일 클라이언트가 이메일 서버에 대한 정보를 찾으려고 시도합니다. 대부분의 사용자가 주소와 연결 프로토콜을 모르기 때문에 이는 서버 연결 설정을 단순화하기 위해 수행됩니다. 이를 위해 이메일 클라이언트는 다양한 방법을 사용하여 서버 및 연결 설정에 대한 정보를 검색합니다. 이러한 방법은 이메일 클라이언트에 따라 다를 수 있습니다.

예를 들어 Outlook은 "자동 검색" 방법을 사용하며, 클라이언트는 DNS 서버에 접속하여 메일 클라이언트 설정에서 지정한 메일 도메인과 연결된 특정 자동 검색 레코드를 요청합니다. 관리자가 DNS 서버에서 이 항목을 구성한 경우 웹 서버를 가리킵니다.

메일 클라이언트는 웹 서버의 주소를 알아낸 후 웹 서버에 접속하여 XML 형식의 메일 서버 연결 설정이 포함된 미리 준비된 파일을 찾습니다.

Thunderbird의 경우 메일 클라이언트는 자동 검색 DNS 레코드 검색을 우회하고 즉시 자동 구성 웹 서버에 연결을 시도합니다. 그리고 지정된 도메인의 이름입니다. 그리고 웹 서버에서 XML 형식의 연결 설정이 있는 파일을 찾으려고 시도합니다.

메일 클라이언트가 필요한 설정이 포함된 파일을 찾지 못하면 가장 자주 사용되는 설정 중에서 추측을 시도합니다. 예를 들어, 도메인이 example.com이라고 하면 메일 서버는 imap.example.com 및 smtp.example.com이라는 서버가 있는지 확인합니다. 찾으면 설정에 등록해 줍니다. 메일 클라이언트가 어떤 방식으로든 메일 서버 주소를 확인할 수 없는 경우 사용자에게 연결 데이터를 직접 입력하라는 메시지가 표시됩니다.

그러면 서버에 대해 수신 메일 서버 주소와 발신 메일 서버 주소라는 2개의 필드가 표시됩니다. 일반적으로 소규모 조직에서는 이러한 주소가 다른 DNS 이름을 통해 지정되더라도 동일하지만 대규모 회사에서는 서버가 다를 수 있습니다. 그러나 이들이 동일한 서버인지 아닌지는 중요하지 않습니다. 그 뒤에 있는 서비스는 다릅니다. 가장 인기 있는 메일 서비스 번들 중 하나는 Postfix & Dovecot입니다. Postfix는 발신 메일 서버(MTA - 메일 전송 에이전트) 역할을 하고 Dovecot은 수신 메일 서버(MDA - 메일 배달 에이전트) 역할을 합니다. 이름에서 짐작할 수 있듯이 Postfix는 메일을 보내는 데 사용되고 Dovecot은 메일 클라이언트에서 메일을 받는 데 사용됩니다. 메일 서버 자체는 SMTP 프로토콜을 사용하여 서로 통신합니다. 사용자에게는 Dovecot(MDA)이 필요합니다.

메일 서버에 대한 연결을 구성했다고 가정해 보겠습니다. 메시지를 보내보도록 하겠습니다. 메시지에는 주소와 수신자의 주소가 표시됩니다. 이제 메시지를 전달하기 위해 이메일 클라이언트가 보내는 메일 서버로 메시지를 보냅니다.

서버가 메시지를 받으면 메시지를 전달할 사람을 찾으려고 시도합니다. 귀하의 서버는 모든 메일 서버의 주소를 암기할 수 없으므로 특정 도메인의 메일 서버를 가리키는 특수 MX 레코드를 찾기 위해 DNS를 찾습니다. 이러한 항목은 하위 도메인마다 다를 수 있습니다.

수신자의 서버 주소를 알아낸 후 SMTP를 통해 이 주소로 메시지를 보냅니다. 그러면 수신자의 메일 서버(MTA)가 메시지를 수락하고 특수 디렉터리에 저장합니다. 이 디렉터리도 담당 서비스에서 확인합니다. 클라이언트(MDA)에게 메시지를 수신합니다.

다음에 수신자의 메일 클라이언트가 수신 메일 서버에 새 메시지를 요청할 때 MDA는 해당 서버에 메시지를 보냅니다.

그러나 메일 서버는 인터넷에서 작동하며 누구나 접속하여 메시지를 보낼 수 있고 메일 서버는 다양한 회사에서 중요한 데이터를 교환하는 데 널리 사용되기 때문에 이는 공격자, 특히 스패머에게 매우 유용한 정보입니다. 따라서 최신 메일 서버에는 보낸 사람 확인, 스팸 확인 등을 위한 많은 추가 조치가 있습니다. 그리고 나는 다음 부분에서 이러한 주제 중 많은 부분을 다루려고 노력할 것입니다.

출처 : habr.com