메시지 크기 거부는 수신 서버가 모든 메시지 인증을 평가하기 전에 발생할 수 있습니다. 업스트림 서버가 메시지를 수락하고 이후 홉이 더 작은 제한을 적용한 후에도 나타날 수도 있습니다. 모든 영구불량을 하나의 불량품으로 취급하기보다는 불량 홉의 사이즈 상태를 진단합니다. SPF, DKIM 또는 DMARC 결함.
정책 및 스토리지와 크기 구별
RFC 3463 X.3.4를 수신 시스템에 비해 너무 큰 메시지로 정의하고 X.2.3을 사서함에 대한 관리 제한을 초과하는 메시지 길이로 정의합니다. 이는 X.2.2 메일박스가 가득 찬 것과 다릅니다. 제품에 자체 한계, 단위 및 설명 문구가 추가될 수 있으므로 전체 진단 내용을 읽어보세요. 일반 "552" 레이블만으로는 정확하게 구성된 제한 사항을 설정할 수 없습니다. RFC 3463 섹션 3.3 및 3.4.
인증 실패는 메시지 옥텟 수보다는 ID, 서명 또는 정책과 관련이 있습니다. 크기를 줄이는 것은 DKIM 복구가 아닙니다. 서명된 콘텐츠를 변경하면 서명이 무효화될 수 있으므로 승인된 교체는 일반 서명 작업 흐름을 통과해야 합니다. 반대로, SPF 에서 다른 IP를 인증해도 수신자에게 허용되는 메시지 크기는 늘어나지 않습니다. 독립적인 증거가 둘 다 실패했음을 보여주지 않는 한 두 조사를 별도로 유지하십시오.
광고된 SIZE 기능을 올바르게 읽으세요.
SMTP SIZE 확장을 사용하면 서버가 지원을 알리고 선택적으로 최대 메시지 크기를 EHLO 응답. 지원 클라이언트는 다음과 같이 예상 크기를 제공할 수 있습니다. 메일 보낸 사람, 전체 메시지를 전송하기 전에 거부를 허용합니다. 숫자가 없는 SIZE는 고정된 최대 정보를 전달하지 않습니다. SIZE 0은 고정된 최대값이 적용되지 않음을 명시적으로 나타냅니다. 둘 다 승인을 보장하지 않습니다. 이후의 처리 및 기타 홉은 여전히 제약을 가할 수 있습니다. RFC 1870 섹션 3 및 4.
RFC 1870 SIZE의 경우 CRLF 줄 끝, 헤더, MIME 구조 및 인코딩된 콘텐츠를 포함한 메시지 옥텟을 계산하지만 DATA 종료 점 및 추가 점 채우기 바이트는 제외합니다. 첨부파일만 카운트하지 마세요. Base64 인코딩은 이진 데이터를 확장하고 줄 바꿈 및 주변 메시지 부분은 더 많은 바이트를 추가합니다. 보다 RFC 2045 섹션 6.8. 공급자 인터페이스는 반올림 단위를 다르게 표시할 수 있습니다. 설명되지 않은 두 개의 "MB" 레이블을 비교하기보다는 측정된 옥텟과 정확한 광고 또는 문서화된 제한을 기록하십시오.
통제된 변형 비교
크기 관련 콘텐츠만 다른 승인된 변형 두 개를 만듭니다. 더 작고 더 큰 직렬화된 크기와 각 결과의 SMTP 단계를 유지합니다. 예시 쌍에는 승인된 액세스 제어 파일 링크로 대체된 큰 첨부 파일과 함께 동일한 짧은 설명 텍스트가 포함될 수 있습니다. 파일 링크가 기밀 자료에 적합하거나 수신자가 액세스할 수 있다고 가정하지 마십시오.
RFC 5321 섹션 4.5.3.1 .7에서는 헤더를 포함하여 최소 64K 옥텟의 메시지 크기를 지원해야 합니다. 다음 100,000옥텟 제한은 해당 프로토콜 최소값보다 높으며 권장되는 공급자 설정이 아닙니다.
가상 산술 검사의 경우 동일한 끝점이 SIZE 100000을 광고한다고 가정합니다. 가정된 115,900옥텟 메시지는 해당 제한을 15,900옥텟만큼 초과합니다. 가정된 20,100옥텟 대체는 그 아래 79,900옥텟입니다. 첫 번째는 MAIL FROM에서 거부될 수 있습니다. 두 번째는 추가 처리가 가능하지만 승인이 보장되지는 않습니다. 이 숫자는 고안된 것이지 측정이나 실행된 SMTP 결과가 아닙니다. 이는 제공자의 첨부 한도를 설명하지 않습니다.
가장 좁은 관련 제약 조건을 복구합니다.
크기가 의도적인 서비스 제한인지 아니면 조직에서 제어하는 설정인지 거부 시스템의 소유자에게 문의하십시오. 더 작은 파일로 비즈니스 요구 사항을 충족할 수 있는 경우 전체 메일 시스템에 걸쳐 제한을 늘리는 대신 해당 경로를 사용하십시오. 제한 변경이 승인된 경우 적용하기 전에 리소스 소비, 맬웨어 검사 및 다운스트림 호환성을 고려하세요.
영구적으로 거부된 동일한 콘텐츠를 변경하지 않고 계속 재시도하지 마세요. 원본이 다른 홉이나 다른 수신자에 대해 승인되지 않았는지 확인한 다음 이전 시도와의 명확한 관계를 포함하여 승인된 교체를 제출하세요. 자체 메시지 및 대기열 식별자를 유지합니다. 사용자가 이를 동일한 첨부 파일로 간주하더라도 새 메시지는 새 배달 이벤트입니다.
측정된 메시지 크기, 식별된 거부 제한 및 수정된 시도의 결과로 닫습니다. 받은편지함 배치와 링크된 콘텐츠에 대한 수신자 액세스는 별도의 확인으로 남겨두세요.
해결 방법과 한도를 분리하세요.
- 측정: 첨부 파일뿐만 아니라 SIZE 정의를 사용하여 직렬화된 전체 메시지를 계산합니다.
- 찾기: 거부 홉, 명령 단계, 진단 및 적용 가능한 제한을 캡처합니다.
- 수리: 승인된 더 작은 메시지 또는 액세스 제어 전달 방법을 선택합니다.
- 재확인: 교체 크기와 수신자별 결과를 기록합니다. 모든 다운스트림 제한이 일치한다고 가정하지 마십시오.
- 닫기: SMTP 수락과 별도로 수신자 액세스를 확인합니다.