ความคิดที่ดี? ปฏิเสธอีเมลขาเข้าที่โดเมนของเราลงท้ายด้วยใช่หรือไม่ (เพราะต้องเป็นของปลอม)

33

ฉันมีคำถามเกี่ยวกับ Exchange Server ของเรา: คุณคิดว่าเป็นความคิดที่ดีหรือไม่ที่จะปฏิเสธอีเมลภายนอกขาเข้าที่มีโดเมนของเราในตอนจบ

ชอบอีเมลภายนอกfake@example.comใช่หรือไม่

เพราะถ้ามันมาจากผู้ส่งที่แท้จริงใน บริษัท ของเราอีเมลจะไม่มาจากข้างนอกใช่มั้ย

ถ้าใช่วิธีที่ดีที่สุดในการทำเช่นนี้คืออะไร?

security email-server exchange-2013

— Steffen Maier
แหล่งที่มา

3

คุณมีโซลูชันการกรองสแปมประเภทใดบ้างในตอนนี้?

— ewwhite

14

คุณควรตรวจสอบอีกครั้งว่าคุณไม่มีผู้ขายแอปพลิเคชันเว็บใด ๆ ที่พยายามส่งจากโดเมนของคุณเอง เช่นถ้าคุณมีระบบบัญชีเงินเดือนที่อาจส่งอีเมลถึงพนักงานของคุณจาก "payroll@example.com" ตรวจสอบด้วยว่าการตลาดหรือ HR อาจใช้บริการอีเมลขยะภายนอกหรือไม่และพวกเขาต้องการให้พนักงานรับข้อความเหล่านั้น โดยปกติข้อความเหล่านั้นจะมีผู้ส่งหรือที่อยู่ตอบกลับอย่างน้อยของใครบางคนในตลาดหรือทรัพยากรบุคคล ในสถานการณ์เหล่านั้นโดยปกติคุณจะสามารถวางเซิร์ฟเวอร์อีเมลของบริการไว้ในรายการอนุญาตและยังบล็อกโดเมนของคุณที่เข้ามา (นั่นคือสิ่งที่เราทำ)

— ทอดด์วิลคอกซ์

6

@NeilMcGuigan มันจะสำคัญยังไง เมลควรมาจากเซิร์ฟเวอร์อีเมลภายในหรือไม่ มันจะไม่มาจากนอกเครือข่ายเพียงเพราะเขาไม่ได้มีอยู่จริง

— Matt

@ Matt gotya, brainfart

— Neil McGuigan

1

หากคุณมีการแจ้งเตือนอีเมลอัตโนมัติที่มาจากเซิร์ฟเวอร์ตัวใดตัวหนึ่งของคุณตัวอย่างเช่นการแจ้งเตือนงาน cron ที่ล้มเหลวหรือพยายามละเมิดจาก IDS หรือการตรวจสอบการใช้ทรัพยากรและพวกเขาถูกกำหนดค่าเพื่อให้ที่อยู่ From ของพวกเขาอยู่กับชื่อโดเมนของคุณ คุณจะต้องระมัดระวังในการกำหนดเส้นทางอีเมลเหล่านั้นผ่านทาง Mailserver ภายในของคุณหรือเพื่ออนุญาตเซิร์ฟเวอร์เหล่านั้นในฐานะผู้ส่งที่อนุญาต

— โกหกไรอัน

53

ใช่ถ้าคุณรู้ว่าอีเมลสำหรับโดเมนของคุณควรมาจากเซิร์ฟเวอร์ของคุณเองเท่านั้นคุณควรบล็อกอีเมลใด ๆ สำหรับโดเมนนั้นที่มาจากเซิร์ฟเวอร์อื่น แม้ว่าไคลเอนต์อีเมลของผู้ส่งจะอยู่ในโฮสต์อื่นพวกเขาควรลงชื่อเข้าใช้เซิร์ฟเวอร์ของคุณ (หรือเซิร์ฟเวอร์อีเมลใดก็ตามที่คุณใช้) เพื่อส่งอีเมล

คุณสามารถกำหนดค่าเซิร์ฟเวอร์ของคุณเพื่อตรวจสอบระเบียน SPF ได้ นี่คือจำนวนโฮสต์ที่ป้องกันการเรียงลำดับของกิจกรรมอีเมล ระเบียน SPF เป็นระเบียน DNS ซึ่งเป็นระเบียน TXT ซึ่งให้กฎเกี่ยวกับเซิร์ฟเวอร์ที่อนุญาตให้ส่งอีเมลสำหรับโดเมนของคุณ วิธีเปิดใช้งานการตรวจสอบระเบียน SPF จะขึ้นอยู่กับบริการอีเมลของคุณและจะเกินขอบเขตของสิ่งที่จะกล่าวถึงในที่นี้ โชคดีที่สภาพแวดล้อมการโฮสต์และซอฟต์แวร์ส่วนใหญ่จะมีเอกสารสำหรับการทำงานกับระเบียน SPF คุณอาจต้องการเรียนรู้เพิ่มเติมเกี่ยวกับค่า SPF โดยทั่วไป นี่คือบทความ Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
แหล่งที่มา

3

@Kurtovic เซิร์ฟเวอร์อีเมลที่มีการกำหนดค่าดีควรเด้งอีเมลที่มันปฏิเสธดังนั้นผู้ส่งจะได้รับแจ้ง

— Calimo

8

@Calimo ไม่ใช่เมื่อมันปฏิเสธอีเมลว่าเป็นสแปม การทำเช่นนั้นจะทำให้ผู้ส่งสแปมพยายามต่อไปจนกว่าเขาจะได้เรียนรู้ว่าอัลกอริทึมของคุณอนุญาตและไม่อนุญาต

— Jon Bentley

27

@Calimo - ไม่ ยอมรับและตีกลับเป็นสิ่งที่เลวร้ายที่สุดที่เป็นไปได้ที่จะทำคุณมีส่วนทำให้สแปมกระจายกลับและจะถูกขึ้นบัญชีดำอย่างรวดเร็ว เพียงแค่ปฏิเสธอีเมลที่ไม่ต้องการ - การจัดการกับนั่นคือปัญหาของโฮสต์ที่ส่ง หากคุณไม่สามารถทำเช่นนั้นให้ยอมรับตรวจสอบและทิ้งว่าสแปมหรือมัลแวร์ ไม่เคยยอมรับและเด้ง

— cas

2

@cas: มีทางเลือกที่สาม: ปฏิเสธเมื่อถึงเวลายอมรับ SMTP ซึ่งทำให้ภาระในการสร้างการตอบสนองข้อผิดพลาดบนเซิร์ฟเวอร์ SMTP ที่ส่งหากต้องการและช่วยให้ผู้ส่งที่ถูกกฎหมายหลายคนดูว่าจดหมายของพวกเขาถูกปฏิเสธในขณะที่รับรองว่าคุณจะไม่สร้างจดหมายขยะด้วยตนเอง

— ..

2

@R .. ฉันคิดว่าคุณจะพบว่าไม่ใช่ทางเลือกที่สามมันเป็นการถอดความสิ่งที่ฉันพูดว่า "เพียงแค่ปฏิเสธอีเมลที่ไม่ต้องการ - จัดการกับปัญหาที่เป็นปัญหาของโฮสต์ที่ส่ง"

— cas

31

มีมาตรฐานสำหรับการทำเช่นนี้อยู่แล้ว มันเรียกว่า DMARC คุณใช้มันด้วยการลงนาม DKIM (ซึ่งเป็นความคิดที่ดีที่จะใช้ต่อไป)

ภาพรวมระดับสูงคือคุณลงชื่อในอีเมลทุกฉบับที่ทำให้โดเมนของคุณมีส่วนหัว DKIM (ซึ่งเป็นแนวปฏิบัติที่ดีอยู่แล้ว) จากนั้นคุณกำหนดค่า DMARC ให้ปฏิเสธอีเมลทุกฉบับที่ส่งถึงเซิร์ฟเวอร์อีเมลของคุณจากโดเมนที่คุณเป็นเจ้าของซึ่งไม่ได้เซ็นชื่อด้วยส่วนหัว DKIM ที่ถูกต้อง

ซึ่งหมายความว่าคุณยังสามารถให้บริการภายนอกส่งอีเมลไปยังโดเมนของคุณ (เช่นซอฟต์แวร์ช่วยเหลือที่โฮสต์ ฯลฯ ) แต่สามารถบล็อกความพยายามฟิชชิงหอก

อีกสิ่งที่ยอดเยี่ยมเกี่ยวกับ DMARC คือคุณได้รับรายงานความล้มเหลวที่ส่งมอบเพื่อให้คุณสามารถจัดการข้อยกเว้นตามที่ต้องการ

ข้อเสียคือคุณต้องแน่ใจว่าคุณมีทุกอย่างแยกออกก่อนหรือคุณอาจเริ่มทิ้งอีเมลที่ถูกกฎหมาย

— มาร์คเฮนเดอร์สัน
แหล่งที่มา

3

ขอแนะนำอย่างยิ่งให้ติดตั้ง SPF และ DKIM ก่อนทดสอบ DMARC

— Todd Wilcox

DMARC ทำงานกับอีเมลได้อย่างไรมาจากเซิร์ฟเวอร์ที่แตกต่างจากของคุณเองเช่นกับบริการภายนอกเนื่องจากเซิร์ฟเวอร์เหล่านั้นจะไม่ได้รับการลงนามโดยเซิร์ฟเวอร์ของคุณ

— jpaugh

1

@jpaugh คุณเพิ่มพับลิกคีย์เซิร์ฟเวอร์อื่นไปยังระเบียน DMARC ของคุณใน DNS ของคุณ พวกเขาจะสามารถเพิ่มระเบียนให้คุณได้

— 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 คอมผู้ส่ง:

หากเซิร์ฟเวอร์ของคุณดูที่หัวข้อ "จาก:" (แทนที่จะเป็น "ผู้ส่ง:") เซิร์ฟเวอร์อาจปฏิเสธข้อความนี้เนื่องจากคุณได้รับจากภายนอก

เนื่องจากทั้งหมดข้างต้นการมีนโยบายแบบครอบคลุมของ "... จากผู้ส่งที่แท้จริงใน บริษัท ของเราอีเมลจะไม่มาจากข้างนอก" จึงเป็นไปไม่ได้เสมอไป

— เดวิดเกลฮาร์
แหล่งที่มา

2

คุณสามารถทำสิ่งนี้ได้ใน PowerShell โดยอัปเดตการอนุญาตรับ Connector ของคุณเพื่อไม่ให้ผู้ใช้ที่ไม่ระบุชื่อส่งเป็นผู้ส่งโดเมนที่มีสิทธิ์:

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