백업 메일 서버에서 많은 메시지를 처리하고 있으며 모든 메시지에 대해 보낼 간단한 서버를 구성하고 싶습니다 450.
그러나 재시도 시 보내는 서버가 우선 순위가 더 높은 서버로 전송을 시도하지 않으면 메시지가 전달될 수 없기 때문에 이것이 좋은 생각인지 확신할 수 없습니다.
이에 대한 RFC에서 아무것도 찾지 못했지만 서버는 우선 순위가 더 높은 서버에서 다시 시도합니까, 아니면 응답한 동일한 서버에서 영원히 시도합니까 450?
답변1
SMTP 전송이 실패하는 경우(영구적 수신 없이5xy부정적인 완료 SMTP 응답) 대체/백업 MX가 정의되어 있지 않습니다. IIRC는RFC는 발신자 구현에 맡깁니다.배송이 다시 시도되는지, 후속 배송 시도가 얼마나 자주, 얼마나 오래 지속되는지를 나타냅니다. 표준은 또한 다음과 같은 경우 발신자 구현에 맡깁니다.임시배송지연 알림은 언제쯤 오나요?원래 보낸 사람에게 반송되거나영구 배송 실패 오류 알림이 얼마나 빨리 전송되나요?반환됩니다.
1개 이상일 때MX 레코드수신자 도메인에 대해 정의된 경우 모든 배달 시도에 대해 표준을 준수하는 발신자는 하나의 MX가 메시지를 수락할 때까지 모든 MX 레코드에 차례로 전달을 시도하고 우선순위를 존중해야 합니다(발신자는2xx긍정적인 완료 SMTP 응답) 또는 한 MX가 메시지를 거부합니다(영구 5xy부정 완료 SMTP 응답) 또는 모든 사람이 연락을 받을 때까지.
(기본 및/또는 백업) MX 레코드 중 도메인에 대한 메일 메시지를 영구적으로 수락하거나 거부하지 않은 경우 대체 MX 레코드가 없는 경우와 동일한 발신자 구현별 실패 경로를 따를 것으로 예상됩니다. 다시 말하면:"발신자는 나중에 배달을 시도하기 위해 메시지를 대기열에 넣거나 포기할 수 있습니다.".
하든 안 하든
여러 MX 레코드와 백업 메일 서버를 사용자가 직접 제어할 수 있다는 전체 개념은 사용자가 이를 제어하고 원래 보낸 사람의 대기열 및 재시도 정책에 의존할 필요가 없거나 정책이 없다는 사실입니다.
당신이 그 통제를 원하지 않을 때;백업 MX가 메일을 대기열에 추가하는 것을 원하지 않지만 대기열 및 배달 재시도를 발신자에게 맡기고 싶다면 백업 MX 레코드를 전혀 구성하지 마세요.이는 오류만 생성하고 실제로는 이메일을 수락하고 대기열에 추가하지 않는 서버를 가리키는 백업 MX를 설정하는 것과 동일한 효과(더 나은 효과는 아니지만)를 가져야 합니다.
IMHO 백업 MX의 의도된 목적
기본 서버가 오프라인 상태가 되거나 중단 또는 계획된 유지 관리로 인해 사용할 수 없게 되는 경우 RFC와 보낸 사람의 SMTP 프로토콜의 올바른 구현을 통해 도메인으로 주소가 지정된 전자 메일 메시지가 백업 서버로 전송되도록 해야 합니다. MX, (계획된) 중단이 종료되는 동안 메일이 수락되고 대기열에 추가됩니다.
백업 메일 서버(발신자가 아님)는 메일 배달 지연/실패 알림이 원래 발신자에게 전송될지 여부와 시기를 제어합니다.
중단이 종료되고 기본 메일 서버와 사서함이 다시 온라인 상태가 되면 백업 MX의 대기열을 비우고 (거의) 대기열에 있는 모든 메일을 즉시 받을 수 있습니다. 와 더불어ETRN예를 들어 SMTP 명령.
답변2
jcaron의 의견에서 제안한대로 :
두 번째 MX가 450을 보내는 이유가 있나요? 아무 것도 없는 경우(예: 해당 포트에 서버가 응답하지 않거나 두 번째 MX가 전혀 나열되지 않은 경우) 결과는 동일하고 작업량이 줄어듭니다... 그러나 해결책이 무엇이든 보낸 사람이 메일을 영원히 보관할 수는 없다는 점에 유의하세요. 많은 사람들이 며칠 동안 다시 시도하지만 일부는 훨씬 짧은 시간 초과를 갖습니다. 일부는 첫 번째 오류 시 주소를 블랙리스트에 추가합니다!
XY 문제에 대한 올바른 해결책은 백업 MX를 보유하지 않는 것입니다. MX가 두 개 이상 있을 필요는 없습니다. 모든 합법적인 발신자는 하루 이상, 때로는 일주일 이상 배달을 다시 시도합니다. 서버에 다운타임이 발생하여 즉시 메일을 받을 수 없는 경우에는 개략적인 제3자 대기열 서비스보다는 이를 보내는 사람의 메일 시스템에 책임을 맡기는 것이 당연히 옳은 일입니다. 메일이 "먹히는" 것을 방지할 뿐만 아니라; 또한 귀하의 메일을 가로챌 권한이 있는 제3자를 신뢰하는 것을 방지하고, 장기간 중단으로 인해 메일을 배달할 수 없게 되는 경우 발신자에게 (자체 메일 시스템을 통해) 알림이 전달되도록 보장합니다.
실제 질문에 관해서는 SMTP의 재시도 작동 방식이 제대로 지정되지 않았으며 어떤 것이 있는지 잘 모르겠습니다.보장하다일시적인 실패를 보고하는 가짜 보조 MX로 전달을 계속 시도하는 대신, 일치하는 발신자가 연결할 수 없음을 확인한 후 기본 시도로 루프백할 것입니다. 따라서 위의 추론 없이도해서는 안 된다보조 MX가 있는 경우, 이 특정 해킹을 시도하는 것은 좋지 않은 생각이라고 생각합니다.
관련이 있는 경우, 이에 대한 나의 경험은 개인/소규모 사이트 메일 시스템을 22년 이상 지속적으로 운영해 왔으며 MX를 두 개 이상 사용한 적이 없습니다.