좋은 생각? 자체 도메인 엔딩으로 수신 이메일을 거부 하시겠습니까? (가짜 여야하기 때문에)

33

Exchange Server에 대한 질문이 있습니다. 엔딩에 자체 도메인이있는 외부 전자 메일 수신을 거부하는 것이 좋습니다.

의 외부 이메일처럼 fake@example.com?

회사의 실제 발신자에게서 온 것이면 이메일은 절대 외부에서 나오지 않습니까?

그렇다면이 작업을 수행하는 가장 좋은 방법은 무엇입니까?

security email-server exchange-2013

— 스테 펜 마이어
소스

3

현재 어떤 종류의 스팸 필터링 솔루션이 있습니까?

— ewwhite

14

자신의 도메인에서 보내려는 웹 응용 프로그램 공급 업체가 없는지 다시 확인해야합니다. "payroll@example.com"에서 직원에게 전자 메일을 보낼 수있는 급여 시스템이있는 것처럼. 또한 마케팅 또는 HR이 외부 대량 메일 서비스를 사용할 수 있고 직원이 해당 메시지를 받길 원하는지 확인하십시오. 일반적으로 이러한 메시지에는 마케팅 또는 HR 담당자의 발신자 또는 적어도 회신 주소가 있습니다. 이러한 상황에서는 일반적으로 서비스의 전자 메일 서버를 허용 목록에 배치하고 자신의 도메인 수신을 차단할 수 있습니다 (우리가하는 일).

— 토드 윌콕스

6

@NeilMcGuigan 그게 무슨 상관이야? 메일이 여전히 내부 메일 서버에서 시작되어야합니까? 그가 실제로 존재하지 않기 때문에 네트워크 외부에서 나오지 않을 것입니다.

— Matt

@ 매트 gotya, brainfart

— 닐 맥기 건

1

크론 작업 알림 실패, IDS 또는 자원 사용 모니터에서 실패를 시도하는 등 서버 중 하나에서 자동 이메일 알림을 수신 한 경우 발신 주소가 도메인 이름을 갖도록 구성되었습니다. 내부 메일 서버를 통해 해당 전자 메일을 라우팅하거나 해당 서버를 허용 된 발신자로 허용하도록주의해야합니다.

— Lie Ryan

53

예. 도메인의 이메일이 자신의 서버에서만 전송되어야한다는 것을 알고 있다면 다른 서버에서 발생하는 해당 도메인의 모든 이메일을 차단해야합니다. 발신자의 전자 메일 클라이언트가 다른 호스트에 있더라도 전자 메일을 보내려면 서버 (또는 사용하는 전자 메일 서버)에 로그인해야합니다.

한 단계 더 나아가 SPF 레코드를 확인하도록 서버를 구성 할 수 있습니다. 이러한 종류의 전자 메일 활동을 방해하는 호스트 수입니다. SPF 레코드는 TXT 레코드 인 DNS 레코드이며 도메인에 대한 전자 메일을 보낼 수있는 서버에 대한 규칙을 제공합니다. SPF 레코드 확인을 활성화하는 방법은 전자 메일 서비스에 따라 다르며 여기서 다루는 내용의 범위를 벗어납니다. 다행히 대부분의 호스팅 환경과 소프트웨어에는 SPF 레코드 작업에 대한 설명서가 있습니다. SPF에 대한 일반적인 정보를 원할 수도 있습니다. Wikipedia 기사는 다음과 같습니다. https://ko.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
소스

3

@Kurtovic 잘 구성된 전자 메일 서버는 거부 된 전자 메일을 반송해야 발신자에게 알릴 수 있습니다.

— Calimo

8

@Calimo 스팸으로 인해 이메일을 거부 할 때 아닙니다. 그렇게하면 스패머가 알고리즘에서 허용하는 것과 허용하지 않는 것을 알게 될 때까지 계속 시도 할 수 있습니다.

— 존 벤틀리

27

@Calimo-아니요. 수락 및 반송은 가능한 최악의 방법이며, 스팸을 분산시키는 데 기여하며 매우 빠르게 블랙리스트에 추가됩니다. 원치 않는 메일을 거부하면 발신 호스트의 문제가 해결됩니다. 그렇게 할 수 없으면 스팸이나 맬웨어인지 확인하고 폐기하십시오. 절대로 수락하고 반송하지 마십시오.

— cas

2

@cas : 세 번째 대안이 있습니다 : SMTP 수락시 거부. 이렇게하면 보내는 SMTP 서버에서 원하는 경우 오류 응답을 생성해야하므로 많은 합법적 인 보낸 사람이 자신의 메일이 거부되었는지 여부를 확인하면서 자신이 스팸을 만들지 않도록 할 수 있습니다.

— R ..

2

@R .. 나는 당신이 세번째 대안이 아니라고 생각할 것이다. 그것은 "원치 않는 메일을 거부하라-그 문제를 처리하는 것은 보내는 호스트의 문제"라는 말의 역설이다.

— cas

31

이 작업을 이미 수행하기위한 표준이 있습니다. DMARC라고 합니다. DKIM 서명으로 구현합니다 (어쨌든 구현하는 것이 좋습니다).

높은 수준의 개요는 도메인을 떠나는 모든 단일 전자 메일에 DKIM 헤더로 서명하는 것입니다 (어쨌든 좋은 방법입니다). 그런 다음 사용자가 소유 한 도메인에서 메일 서버에 도달 한 모든 전자 메일을 유효한 DKIM 헤더로 서명하지 않은 모든 전자 메일을 거부하도록 DMARC를 구성합니다.

즉, 호스팅 된 헬프 데스크 소프트웨어 등과 같은 외부 서비스가 도메인으로 전자 메일을 배달 할 수는 있지만 스피어 피싱 시도는 차단할 수 있습니다.

DMARC의 또 다른 장점은 실패 보고서를 전달하여 필요에 따라 예외 처리를 관리 할 수 있다는 것입니다.

단점은 모든 것을 사전에 철저히 정리했거나 합법적 인 이메일을 삭제하기 시작할 수 있다는 것입니다.

— 마크 헨더슨
소스

3

DMARC를 테스트하기 전에 SPF와 DKIM을 구현하는 것이 좋습니다.

— 토드 윌콕스

DMARC가 서버와 서명하지 않았기 때문에 외부 서비스와 같이 다른 서버에서 전자 메일로 작업하는 방법은 무엇입니까?

— jpaugh

1

@jpaugh는 다른 서버 공개 키를 DNS의 DMARC 레코드에 추가합니다. 그들은 당신에게 추가 할 레코드를 줄 수있을 것입니다.

— Mark Henderson

이 답변은 기술적으로 정확하기 때문에 +1했습니다. 즉, DMARC의 목적과 기능은 무엇입니까?하지만 DMARC는 RFC 및 일반적으로 오작동합니다.

— MadHatter는 Monica

11

이러한 차단은 스팸을 줄이고 사회 공학을 어렵게 만들 수 있지만 합법적 인 메일을 차단할 수도 있습니다. 메일 전달 서비스, 메일 목록, 잘못 구성된 메일 클라이언트 사용자, 기본 메일 서버 등을 사용하지 않고 웹 호스트에서 직접 메일을 보내는 웹앱이 있습니다.

Dkim은 네트워크에서 전송되고 메일 링리스트 또는 전달자를 통해 루핑 된 다음 메일로 수신 된 메시지를 식별하는 방법을 제공하여이를 어느 정도 완화 할 수 있습니다. 그러나 완벽한 치료법은 아닙니다. 합법적 인 메일 발신 지점을 모두 추적하여 dkim 서명자를 통과시키는 데 여전히 문제가 있습니다.

기존 도메인에서이를 구현하는 경우 특히주의하십시오.

— 피터 그린
소스

3

어쩌면 그러한 변경을하기 전에 고려해야 할 경우가 있습니다.

1) 회사의 누군가가 도메인에서 "보낸"것처럼 보이는 이메일을 보내기 위해 모든 종류의 외부 서비스 (예 : Survey Monkey, Constant Contact 등)를 사용합니까? 그들이 오늘하지 않더라도 미래에도 그렇게 할 수 있습니까?

2) 사용자에게 전달할 외부 주소가 있습니까? 예를 들어 Gmail 계정 "mycompany.sales@gmail.com"이 "sales@mycompany.com"으로 전달되고 사용자 "bob@mycompany.com"이 "mycompany.sales@gmail.com"으로 전송한다고 가정합니다. 이 경우 메시지는 "외부"에서 도착하지만 "@ mycompany.com"보낸 사람 : 주소와 함께 도착합니다.

3) 사용자 중 메시지의 원래 "보낸 사람 :"주소를 유지하는 외부 메일 그룹에 가입 한 사용자가 있습니까? 예를 들어 Bob이 "foo-list@lists.apple.com"을 구독하고 메시지를 보내면 다음과 같은 인바운드 메시지를받습니다. 보낸 사람 : bob@mycompany.com받는 사람 : foo-list@lists.apple com 발신자 :

서버가 "보낸 사람 :"대신 "보낸 사람 :"헤더를 순진하게 보면 외부에서받는 메시지이므로이 메시지를 거부 할 수 있습니다.

위의 모든 이유로 인해 "... 회사의 실제 발신자로부터 전자 메일은 절대 외부에서 나올 수 없습니다"라는 담요 정책이 항상 실현 가능한 것은 아닙니다.

— 데이비드 겔 하르
소스

2

익명 사용자가 신뢰할 수있는 도메인 발신자로 보내지 못하도록 수신 커넥터 권한을 업데이트하여 PowerShell에서이를 수행 할 수 있습니다.

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

그러나 일반적으로 보낸 사람 주소에 도메인 이름을 사용하므로 상태 전자 메일을 보내야하는 원격 응용 프로그램 서버가있는 경우 문제가 발생합니다. 실수로 제외하지 않도록 특정 IP 주소에 대해 추가 수신 커넥터를 만들 수 있습니다.

— 닐
소스

1

Gmail에는 이메일 주소가 처음 확인 된 경우 Gmail 이외의 도메인으로 이메일을 보낼 수있는 설정이 있습니다. 귀하의 결정은 해당 이메일을 차단합니다.

이 Gmail 기능을 사용할 수있는 사용자가 있는지 여부와 해당 기능을 제공하는 것이 적합한 지 여부는 회사 내부의 동작에 따라 다릅니다.

— 신자
소스

-1

SPF는 봉투 안에 전자 메일을 위조하는 동안 봉투에 적절한 SPF 패스 (예 : 손상된 서버를 사용하는 스패머)가있을 수 있으므로이를 치료하지 않습니다. 봉투에 원본 전자 메일 서버가있는 자신의 도메인 전자 메일 메시지에 대한 차단이 필요합니다.

— 짐
소스

"필요한 것은 봉투에 발신 전자 메일 서버가있어 자신의 도메인 전자 메일 메시지를 차단하는 것입니다." -정확하게 SPF를 사용하여 도메인에 합법적 인 발신 전자 메일 서버 목록을 만듭니다.

— GAThrawn