제거 기록에 변경 사항을 설명하도록 하십시오.
믿을만한 차단 목록 제거 요청은 짧은 증거 체인입니다. 운영자는 특정 개체를 식별하고, 책임 있는 소유자는 관련 동작을 조사하고, 원인을 해결하는 시정 조치를 취하고, 후속 관찰을 통해 주장된 개선 사항을 뒷받침합니다. 회사가 합법적이라는 긴 선언은 해당 체인을 대체하지 않습니다. 관련 없는 인증 확인이 통과되었음을 보여주는 스크린샷도 없습니다.
제출 양식을 열기 전에 기록을 준비하십시오. 이 문서에서는 완료된 요청이 아닌 내부 준비 워크플로를 설명합니다. 목록 조회, 외부 메시지, 삭제 제출, 결제 또는 계정 변경이 수행되지 않았습니다. 책임 있는 소유자는 기술적 사실과 운영자와 공유할 수 있는 정보를 모두 검토해야 합니다.
연산자 및 나열된 개체 설정
운영자의 이름, 목록 또는 데이터 세트, 정확한 IP, 도메인 또는 기타 개체, 가능한 경우 목록 참조 및 타임스탬프를 기록합니다. 발신자는 동일한 메시지에 도메인, 공유 IP 및 포함된 링크 도메인을 사용할 수 있습니다. 그것들은 상호 교환 가능한 객체가 아닙니다. 공급자의 고객은 해당 공급자가 소유한 인프라 제거를 요청할 권한이 부족할 수도 있습니다. 통제권에 대한 청구 초안을 작성하기 전에 소유권과 연락 경로를 해결하세요.
Spamhaus 의 일반 지침은 검사기를 통해 요청을 지시하며 등록된 소유자가 조치를 취하거나 고객이 서비스 제공업체에 참여하도록 요구합니다. 이는 모든 목록에 적용되는 보편적인 규칙이 아닌 Spamhaus 고유의 절차입니다. 현재 운영자 지침에 따라 해당 채널과 요청된 증거가 결정되어야 합니다. Spamhaus 일반 질문.
입증된 원인과 그럴듯한 원인을 구별합니다.
기록에는 조사를 통해 실제로 밝혀진 내용이 나와 있어야 합니다. "손상된 사서함이 기록된 간격 동안 승인되지 않은 메시지를 보냈습니다."에는 계정 및 메시지 증거를 뒷받침하는 것이 필요합니다. "IP가 공유되었으며 공급자가 조사 중입니다"는 다른 불완전한 상태를 설명합니다. 단지 형태가 완전해 보이도록 하기 위해 의심을 확실성으로 전환하지 마십시오. 솔직하게 해결되지 않은 원인이 꾸며낸 교정 이야기보다 더 유용합니다.
원인과 행동 사이의 연결을 유지하십시오. 비밀번호 변경은 MX 메일을 직접 보내지 않는 주소 범위에 대한 정책 목록을 설명하지 않습니다. DNS 변경은 애플리케이션이 원치 않는 메일 전송을 중지한 이유를 설명하지 않습니다. 관찰된 문제가 공유 전송 서비스와 관련된 경우 공급자가 확인한 내용과 고객이 볼 수 없는 내용이 무엇인지 식별합니다.
각 시정 조치를 날짜가 기록된 관찰과 연결합니다.
청구된 모든 조치에 대해 소유자, 범위, 완료 시간 및 뒷받침하는 증거를 기록하십시오. 승인된 계획과 실행된 변경을 분리하고, 실행된 변경과 성공적인 검증을 분리하세요. “팀에서 전달 규칙을 검토할 것입니다.”는 “규칙을 검토했습니다.”와 동일하지 않으며, 둘 다 무단 전달이 중지되었음을 증명하지 않습니다.
Spamhaus 원인과 시정조치, 시기, 예방 조치를 요구하며, 요청한다고 해서 반드시 삭제가 보장되는 것은 아니라는 점을 경고합니다. 동일한 4개 필드가 모든 서비스를 충족한다는 약속이 아니라 운영자의 증거 기대에 대한 구체적인 예로 이를 사용하십시오. 더 좁은 의미의 진술이 뒷받침될 수 있는 경우에는 "모든 것이 해결되었습니다"와 같은 모호한 문구를 피하십시오. Spamhaus 일반 질문.
허구의 증거 패킷을 준비하세요
손상된 통합을 통해 애플리케이션 자격 증명이 남용된 가상의 발신자를 상상해 보십시오. 초안 패킷은 영향을 받은 스트림, 운영자가 확인한 목록 개체, 사고 창, 승인된 격리 결정 및 통합 수리를 식별합니다. 승인된 관련 증거만 첨부하고 모니터링 공백을 명시합니다. 이것은 레코드의 구조를 보여줍니다. 계정 손상이나 목록이 관찰되지 않았습니다.
강력한 패킷은 신원 소유자의 격리 증거를 메일 제공자의 전송 로그 및 목록 운영자의 상태와 구별합니다. 통합 액세스가 해결되지 않은 상태에서 팀이 하나의 비밀번호만 재설정한 경우 패킷은 불완전한 상태로 유지되어야 합니다. 공급자가 나열된 IP를 소유한 경우 허위 소유권 주장에 따라 제출하기보다는 해당 공급자의 검토를 위해 패킷을 준비해야 합니다.
제거와 수신자 승인을 혼동하지 마십시오.
목록에는 다양한 목적과 수명 주기가 있습니다. SpamCop 신고된 메일과 관련된 자동 IP 목록과 신고가 중단되면 자동으로 제거되는 기능을 설명합니다. 또한 해당 문서에서는 거짓 긍정을 인정하고 주의 깊게 사용할 것을 권고합니다. 다른 목록의 타이밍, 수동 프로세스 또는 상업적 제안을 적용하지 마십시오. 페이지 자체에는 자세한 설명이 변경될 수 있음이 명시되어 있습니다. SpamCop 차단 목록 설명.
영향을 받는 수신기는 운영자가 항목을 제거한 후 다른 신호를 사용할 수 있습니다. 전체 SMTP 응답, 공급자 또는 수신자 범위 및 관찰 시간을 보존합니다. 메시지 데이터 이후의 최종 긍정적 완료는 받은 편지함 배치나 이후 필터링 부재가 아닌 SMTP 핸드오프를 설정합니다. 따라서 운영자 상태 확인과 배송 재테스트는 서로 다른 분야에 속합니다. RFC 5321 , 섹션 4.2.5.
공개를 최소화하고 성급한 약속을 피하세요
작업 복사본에서 민감한 메시지 내용과 관련 없는 수신자 데이터를 제거하여 운영자에게 필요한 내용이 포함된 압축 기록을 준비합니다. 원본 로그를 보호하여 수정으로 인해 내부적으로 증거가 모호해지지 않도록 하세요. 삭제 설명에 비밀번호, 토큰, 개인 키 또는 결제 세부정보를 포함하지 마세요. 계정별 공개 또는 제출에는 적절한 승인이 필요합니다.
운영자가 유료 서비스를 제공하는 경우 비용, 조건 및 범위를 별도의 결정으로 취급하십시오. 결제는 원인이 해결되었다는 증거가 아니며 모든 제공자에게 배송을 보장할 수 없습니다. 마찬가지로, 반복적인 요청이 조사 완료를 대체해서는 안 됩니다. 나중에 검토자가 연락처 간에 변경된 내용을 이해할 수 있도록 하나의 명확한 연대기와 관련 사례 참조를 유지하십시오.
패킷을 제출할 준비가 되었는지 결정
소유자의 검토는 다음 세 가지 질문에 답해야 합니다. 주장이 뒷받침되는지, 이것이 운영자의 현재 경로인지, 제안된 공개가 승인되었는지? 해결되지 않은 사실은 숨겨지기보다는 라벨을 붙여 두어야 합니다. 올바른 운영자 경로에 접근할 수 없는 경우 해당 제출 단계를 중지하고 접근에 의존하지 않는 증거를 계속 준비하십시오.
운영자가 확인한 목록과 문서화된 원인, 시정 조치 및 배송 재테스트. 이 정확한 카탈로그 요구 사항은 계속 열려 있습니다. 아래의 맞춤형 패킷 맵에는 제안된 필드만 포함되어 있습니다. 운영자 확인 목록, 실행된 시정 조치, 승인된 제출 또는 제어된 배송 재테스트는 이 초안과 함께 제공되지 않으며 제거 또는 복구 결과도 약속되지 않습니다.