MX 레코드와의 통신 [닫기]

MX 레코드와의 통신 [닫기]

MX 레코드 주제에 대해 간단한 질문이 있습니다.

DNS 레코드에 여러 개의 메일 서버가 있다고 가정해 보겠습니다. 누군가 메일을 보내면 보내는 메일 서버는 MX를 확인하고 비용이 가장 저렴한 서버에 먼저 연락합니다.

이것이 교환 서버라고 가정합니다. 요청한 이메일 주소가 서버에 없으면 어떻게 되나요? 보내는 메일 서버가 MX 레코드의 두 번째 메일 서버로 메일을 보내나요? 아니면 첫 번째 메일 서버의 오류 메시지에 따라 달라지나요?

Exchange는 "알 수 없는 주소"로 전송된 메시지를 어떻게 처리합니까?

답변1

도메인의 MX 레코드에 나열된 모든 메일 서버는 도메인의 모든 사용자에게 메일을 완전히 전달할 수 있다고 가정합니다. 서버가 "알 수 없는 주소" 메시지로 응답하는 경우 Exchange[또는 다른 메일 서버]는 메시지를 전달할 수 없는 것으로 간주하고 해당 설정에 따라 처리합니다.

IIRC 기본적으로 Exchange는 보낸 사람에게 반송 메시지를 생성하지만 메시지를 삭제하도록 구성할 수도 있습니다.

참고: 보내는 메일 서버는 선택한 서버가 도메인의 MX 레코드에 있는 대체 서버인 경우에만 연결을 시도합니다.응답하지 않음.

답변2

메일 배달을 처리하는 SMTP 및 ESMTP(기본 프로토콜)에는 광범위한 RFC(원래 RFC822, 최신 업데이트인 RFC2822 및 RFC5322의 인터넷 표준 추적 프로토콜)가 있습니다.

메일 서버가 배달 중 오류를 처리하는 방법은 메일 서버마다 다릅니다. 문제를 더욱 복잡하게 만드는 것은 이들 중 다수가 구성 가능하며 RFC에 설명된 기본 동작을 쉽게 변경할 수 있다는 점입니다.

위의 고려 사항을 고려하여 일반적인 경험 법칙은 다음과 같습니다.

우선순위가 가장 높은 MX 레코드가 선택되거나, 우선순위가 동일한 레코드가 여러 개 있는 경우 MX 레코드가 무작위로 선택됩니다(무작위 동작이 라운드 로빈 알고리즘인 경우도 있음). 선택한 호스트에 "접근할 수 없음"(호스트에 대한 경로 없음, 연결 거부 등)인 경우 우선순위가 동일하거나 낮은 다음 MX 레코드를 시도하십시오. msw가 언급했듯이 이는 직관에 반하는 것입니다. 가장 높은 우선순위는 0이고 더 많은 수의 레코드가 고려됩니다.더 적은할인.

연결이 설정되거나 모든 호스트가 응답하지 않을 때까지 이 작업이 반복됩니다. 이 경우 나중에 재전송을 시도하기 위해 이메일이 다시 대기열에 추가됩니다. 대부분의 메일 서버는 포기하고 NDR(배달 못 함 보고서)로 이메일을 반환하기 전에 한동안(보통 1~2일) 이 작업을 시도합니다.

연결된 경우성공하면 RFC 프로토콜의 개별 단계에 따라 연결 MTA의 일반적인 동작이 결정됩니다. 원격 메일 서버가 보낸 초기 배너부터 해당 메일 서버에 실행된 모든 명령(from EHLO/ HELO, to MAIL FROM및 문)을 통해 일반적인 경험 법칙은 다음과 같습니다.RCPT TODATA

4xx 일시적인 오류입니다. 나중에 다시 시도해 주세요.

이 코드를 사용하면 이메일이 로컬 메일 서버에 의해 다시 대기열에 추가되고 나중에 전송이 시도됩니다(해당 로컬 메일 서버의 설정에서 구성됨).

5xx 치명적인 오류, 이메일을 전달할 수 없습니다

이 코드를 사용하면 이메일은 배달할 수 없는 것으로 간주되며 로컬로 보내는 메일 서버는 (항상 그런 것은 아니지만 대부분의 서버에서) NDR(배달 못 함 보고서)을 생성합니다.

"이 서버에 요청한 메일 주소가 없는 경우"라는 질문에 대해서는 RCPT TO단계에서 대부분의 서버가 5xx코드로 응답하고 로컬 메일 서버가 NDR을 생성합니다.

모든 이메일 서버가 동일한 것은 아닙니다

이에 대한 몇 가지 주의 사항이 있습니다. MS Exchange는 잘못된 수신자, 라우팅할 수 없는 도메인 등에 관계없이 가장 오랫동안 모든 전자 메일을 수락한 다음 사실 이후에 NDR을 생성합니다. 일부 ISP에는 스팸 문제가 있으며 다음과 같이 알려져 있습니다.후방 산란, NDR을 생성하지 않아도 메일이 "자동으로 실패"합니다(배달 실패 알림을 전혀 받지 못함).

또한 MTA(메일 전송 에이전트 또는 메일 서버)가 항상 배달 끝점인 것은 아니며 MDA(메일 배달 에이전트 - 예: procmail) 및 MUA(메일 사용자 에이전트) 또는 "메일 클라이언트"(예: Thunderbird/Outlook)가 아니라는 점도 고려해야 합니다. 이러한 이메일은 자체 NDR과 같은 응답으로 "반환"되도록 구성할 수 있습니다. .forwardMTA가 이메일을 수락한 후 다른 주소로 리디렉션할 수 있도록 하는 파일과 같은 메커니즘 도 있습니다 (일부 메일 서버). Exim의 경우)는 .forwardSMTP 세션 단계 동안 확장을 시도하며, 라우팅할 수 없는 주소로 확장하면 위의 일련의 오류 코드로 응답합니다.RCPT TO5xx

보다 정확하고 심층적인 설명을 보려면 위에 언급된 RFC와 사용 중인 MTA에 대한 설명서를 읽어보세요(구성 방법이 동작에 영향을 미칠 수 있다는 점을 기억하세요).

관련 정보