☰

스패머처럼 보이는 것을 방지하기 위한 모범 사례

tag-icon • tag-icon email-server spam spf spam-filter mx-record
스패머처럼 보이는 것을 방지하기 위한 모범 사례

오탐과 관련하여 고객을 위한 메일 설정에 좀 더 자신감을 갖고 싶습니다. 내가 아는 것은 다음과 같습니다.

  1. SPF 레코드는 양호하지만 모든 스팸 필터 서비스/소프트웨어(SFSS)가 이를 사용하는 것은 아닙니다.

  2. 역방향 DNS(PTR) 레코드는 거의 필수입니다.

  3. 오픈 릴레이는 좋지 않습니다.

    (내가 읽은 "다른 팁"은 다음과 같습니다):

  4. 메일 서버의 IP 주소를 역방향으로 조회하면 메일을 보내는 도메인이 확인되어야 합니다.

  5. 귀하의 서버는 다른 메일 서버와 통신할 때 HELO FQDN.of.your.mail.server.com을 표시해야 합니다.

  6. MX 레코드의 A 호스트 레코드는 FQDN.of.your.mail.server.com이어야 합니다(또는 IP 주소로 확인되어야 함).

1과 3에 대해서는 꽤 괜찮습니다. 여기에 몇 가지 설명/제안이 필요합니다.

2와 4: 저는 많은 정보를 조사했는데 대부분의 스팸 필터가 PTR을 찾기 때문에 이것은 잘못된 것 같습니다.일반적인ISP가 일반적으로 할당하지 않은 것; 메일을 보내는 도메인이 이와 관련이 없는 것 같습니다(예: 메일에 사용한 두 개의 도메인을 소유한 경우 각각에 대한 PTR이 있는 두 개의 IP 주소에서 메일을 보내야 합니까?)

  1. 이는 의미가 있지만 해당 FQDN이 무엇을 확인하는지에 관심이 있습니까? 현재 해당 HELO를 보내는 IP 주소로 확인되어야 합니까?

  2. 다시 말하지만, 다양한 Google 검색에서 얻은 또 다른 것입니다. Postini를 ​​게이트웨이 서비스(또는 해당 문제에 대한 다른 스마트호스트)로 사용한 경우 이것이 어떻게 작동하는지 알 수 없습니다.

그리고 귀하에게 권한이 없는 다른 도메인을 대신하여 보내는 경우는 어떻게 됩니까? @some.corporatedomain.tld로 메일을 보내야 하는 일부 클라이언트(some.branchdomain.tld)가 있습니다. 회사 본사에서 사용할 릴레이/스마트 호스트를 설정하지 않더라도 말입니다. Corporatedomain.tld는 some.branchdomain.tld가 메일을 보낼 수 있음을 보여주기 위해 SPF 레코드를 생성할 수 있지만, 특히 SFSS가 SPF 레코드를 확인하지 않는 경우 여전히 "스푸핑"을 고려하고 있습니까? 이것에 대해 걱정해야합니까?

답변1

#2(역방향 PTR)가 중요하지만 #4("from"과 일치하는 메일 서버 도메인)는 중요하지 않다는 점을 보증할 수 있습니다. 우리는 항상 메일 서버를 설정하는데, 대부분의 메일 호스트는 #2에 전혀 관심이 없습니다.

가장 큰 가시는 항상 AOL이며, 그들은 목록에 있습니다.표준확인하실 수 있습니다.

답변2

언급된 HELO 문자열과 DNS PTR 레코드를 제외하고 도움이 될 대부분의 작업은 전송 서버와 관련된 것이 아니라 콘텐츠와 관련된 것입니다.

  • 피할 수 있다면 HTML 이메일을 보내지 마세요.
  • 의심스러운 문구("구독을 취소하려면 클릭하세요", "개인정보는 중요합니다" 등)를 포함하지 마세요.
  • "답장" 헤더를 사용하지 말고 응답을 받으려는 주소에서 보내세요.
  • ...그리고 더. 더 많은 좋은 예를 보려면 SpamAssassin 규칙 세트를 읽어보세요.

"FQDN이 무엇을 해결하는지가 중요합니까?"라는 질문에 대해 이것은 전적으로 수신 메일 서버가 수행하는 작업에 따라 달라지며 물론 다양할 수 있지만 일반적으로 FQDN에 의존하는 메일 서버가 너무 많지는 않습니다. 라운드 로빈 설정으로 여러 컴퓨터를 구성할 수 있으므로 FQDN 조회는 엄격하고 빠른 규칙입니다.

답변3

콘텐츠 가이드라인은 어떻습니까? 이메일을 현명하게 유지하면 다양한 시스템에서 스팸 생성자로 표시되는 것을 방지하는 데 도움이 됩니다. 연락처 목록에 있는 모든 사람에게 "재미있는 내용"을 전달하지 않도록 클라이언트를 교육하고, 이메일 요약이나 뉴스레터에 가입하지 말고, 합리적인 맬웨어 보호 메커니즘을 사용하여 스팸 봇넷의 일부가 되는 것을 방지하세요.

답변4

4는 실제로 완전히 거짓입니다. 당신은 다음과 같이 더 많이 생각할 수도 있습니다.발신자 정책 프레임워크, 도메인의 DNS에는 해당 도메인 이름의 From: 헤더가 포함된 메일을 보낼 수 있는 SMTP 서버를 나타내는 레코드가 포함되어 있습니다. 그러나 문제는 호스트된 도메인에는 일반적으로 발신 메일 서버가 있다는 것입니다.~ 아니다도메인 이름과 동일하지만 보낸 사람의 ISP입니다. 예를 들어 myvanitydomain.com과 이메일 주소가 있는 경우[이메일 보호됨], 그러나 인터넷 공급자로 Sprint를 사용하는 경우 일반적으로 이메일을 보내려면 Sprint의 발신 메일 서버를 사용해야 합니다. 이를 해결할 수 있는 방법(예: 웹메일 또는 POP-then-SMTP 인증)이 있지만 이는 좋은 예입니다.

"이메일을 스팸처럼 보이지 않게 만드는 방법"에 관해서는 음... 물론 스팸처럼 보이도록 만들 수는 없습니다. 오픈 릴레이 사용을 고려한다는 사실조차 의심스럽습니다. 나는 당신이 그런 짓을 한 정당한 이유를 단 하나도 생각할 수 없습니다.원하다모든 ISP에 SMTP 서버가 있는 경우. 메일을 보내는 서버 호스팅 비용을 지불하는 경우 다양한 기관에서 IP 주소를 나열하지 않는 방법은 스팸을 보내지 않는 것입니다.

관련 정보