3 คะแนน โดย GN⁺ 2024-04-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การวิเคราะห์เชิงลึกเกี่ยวกับความสามารถในการส่งอีเมล

  • ในเดือนตุลาคม 1971 Ray Tomlinson บัณฑิตจาก MIT ได้ส่งอีเมลฉบับแรกผ่านเครือข่าย
  • เมื่อปีที่แล้ว มีการส่งอีเมลประมาณ 121 ล้านล้านฉบับระหว่างผู้คนราว 4.3 พันล้านคน
  • อีเมลเป็นช่องทางการสื่อสารแบบลายลักษณ์อักษรที่สำคัญที่สุดบนโลก และจะยังคงเป็นเช่นนั้นในอนาคตอันใกล้

ภาพรวม

  • เมื่อวันที่ 3 ตุลาคม 2023 Google และ Yahoo ได้ประกาศมาตรฐานความปลอดภัยอีเมลใหม่เพื่อป้องกันสแปม ฟิชชิง และความพยายามแพร่มัลแวร์
  • ขณะที่ผู้ให้บริการอีเมลเริ่มบังคับใช้นโยบายเหล่านี้ การปฏิบัติตามแนวทางด้านความสามารถในการส่งอีเมลจึงกลายเป็นสิ่งจำเป็น
  • การเปลี่ยนแปลงที่ใหญ่ที่สุดคือการนำมาตรฐานการยืนยันตัวตนอีเมล เช่น SPF, DKIM และ DMARC มาใช้งาน
  • สำหรับ Gmail อีเมลที่ไม่ได้รับการยืนยันตัวตนจะถูกบล็อก

ผู้ที่ได้รับผลกระทบ

  • ผู้ส่งอีเมลจำนวนมากได้รับผลกระทบเป็นหลัก และต้องเปิดใช้งาน SPF, DMARC, DKIM บนโดเมนของตน
  • แม้จะไม่ใช่ผู้ส่งจำนวนมาก ก็อาจได้รับผลกระทบหากไม่ปฏิบัติตามแนวทาง

ไทม์ไลน์

  • Google กำหนดให้ผู้ส่งอีเมลจำนวนมากต้องยืนยันตัวตนอีเมลตั้งแต่เดือนกุมภาพันธ์ 2024
  • Yahoo ก็ใช้ข้อกำหนดเดียวกันตั้งแต่ไตรมาส 1 ของปี 2024

แนวทาง

  • การยืนยันตัวตนผู้ส่ง: นำโปรโตคอลการยืนยันตัวตนอีเมล เช่น SPF, DKIM, DMARC มาใช้งาน
  • ข้อกำหนดสำหรับผู้ส่งจำนวนมาก: หลีกเลี่ยงการส่งอีเมลจำนวนมากที่ไม่จำเป็น เพื่อหลีกเลี่ยงการกรองเป็นสแปมและความเสียหายต่อชื่อเสียง
  • การยกเลิกการสมัครที่ง่าย: ทำให้ตัวเลือกยกเลิกการสมัครใช้งานได้ง่าย
  • การมีส่วนร่วม: หลีกเลี่ยงหัวข้อที่ชวนให้เข้าใจผิด การปรับแต่งเฉพาะบุคคลมากเกินไป และเนื้อหาโปรโมชันที่กระตุ้นตัวกรองสแปม

การยืนยันตัวตนผู้ส่ง

  • SPF, DKIM, DMARC คือมาตรฐานการยืนยันตัวตน 3 ประการที่ช่วยปกป้องอีเมลขององค์กร
  • การตั้งค่ามาตรฐานเหล่านี้อย่างเหมาะสมช่วยป้องกันการโจมตีและเพิ่มความสามารถในการส่ง ทำให้อีเมลไปถึงกล่องจดหมายเข้าแทนที่จะเป็นโฟลเดอร์สแปม

ผลกระทบ

  • Google อัปเดตอัลกอริทึมและข้อมูลรายงานจากผู้ใช้อย่างต่อเนื่องเพื่อปรับปรุงการกรองอีเมลและประสบการณ์ผู้ใช้
  • แนวทางความปลอดภัยใหม่แสดงให้เห็นผลกระทบที่มีต่อความสามารถในการส่งอีเมลและการมีส่วนร่วม

เครื่องมือ

  • มีการจัดทำรายการแหล่งข้อมูลออนไลน์ฟรีที่ช่วยในการตั้งค่า ตรวจสอบ และดูแลสุขอนามัยอีเมล

การนำไปใช้

  • การนำแนวทางเหล่านี้ไปใช้ อาจเป็นความท้าทายสำหรับองค์กรขนาดเล็กที่มีทรัพยากรจำกัด
  • เพื่อใช้งานการยืนยันตัวตนอีเมล ควรอ้างอิงทรัพยากรหรือการสนับสนุนจากผู้ให้บริการ

โบนัส

  • แนะนำหลายวิธีที่แฮกเกอร์ใช้ประโยชน์จากช่องโหว่ด้านความปลอดภัยของอีเมล

ความเห็นของ GN⁺

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

1 ความคิดเห็น

 
GN⁺ 2024-04-02
ความคิดเห็นบน Hacker News
  • เมื่อดูอิทธิพลของผู้ให้บริการอีเมลอย่าง “Gmail”, “Outlook”, “Yahoo” แล้ว ผมสงสัยมาตลอดว่า จะเป็นไปได้ไหมที่จะทำให้เกิด การส่งไม่ถึงแบบเจาะจงเป้าหมาย ผ่านการโจมตีรูปแบบอื่นที่มุ่งเป้าไปยังบริษัท
    ทำให้เหยื่อ โดยเฉพาะบริษัท·เมลลิงลิสต์·NGO ส่งอีเมลจำนวนมากไปยังที่อยู่ที่ผู้โจมตีเป็นเจ้าของ แล้วผู้โจมตีก็ทำเครื่องหมายอีเมลเหล่านั้นว่าเป็นสแปมใน Gmail/Yahoo/Outlook
    จากนั้น ตัวกรองสแปม AI ก็จะเรียนรู้ว่านี่เป็นกิจกรรมสแปมใหม่ และอาจจัดอีเมลที่ส่งถึงลูกค้าจริงในภายหลังเป็นสแปม หรือแม้แต่ลบทิ้งก่อนถึงปลายทาง
    ผ่านไปราวหนึ่งปี บริษัทอาจเสียเงินทุกไตรมาส ฝ่ายโฆษณาสงสัยว่าทำไม engagement ทางอีเมลลดลง และฝ่ายเทคนิคก็ตกอยู่ในความสับสน
    บริษัทใหญ่อาจทนได้หรือเลิกใช้อีเมลไปเลย แต่บริษัทเล็ก ๆ หรือ NGO·เมลลิงลิสต์ทางการเมือง อาจได้รับผลกระทบอย่างยอดบริจาคลดลง
    พูดตามตรง ในฐานะเส้นทางโจมตีคงมีโอกาสต่ำ แต่เป็นความคิดที่ติดอยู่ในใจมาตลอด

    • ผมรู้จักเหยื่อที่สแปมเมอร์ตัวจริงขโมยเทมเพลตอีเมลที่ถูกต้องตามกฎหมายไปใช้ทั้งดุ้น
      สแปมเมอร์ใส่เทมเพลตที่ถูกต้องตามกฎหมายไว้ในอีเมลแบบมองไม่เห็น แล้วให้เห็นเฉพาะข้อความหลอกลวงจริง ๆ ไม่กี่บรรทัด
      เป็นวิธีทำให้ตัวกรองมองว่าอีเมลส่วนใหญ่ดูปกติและปล่อยผ่าน สุดท้ายเมื่อผู้ใช้แจ้งสแปมมากพอ ตัวเทมเพลตเอง ก็จะทำให้ถูกบล็อก
      จากนั้นสแปมเมอร์ก็ย้ายไปใช้เทมเพลตอีเมลของเหยื่อรายถัดไปที่ยังผ่านตัวกรองได้ ส่วนเหยื่อรายแรกต้องรับภาระตามแก้ว่าเมลของตัวเองส่งไปไม่ถึงที่ไหนเลย
    • ผมเคยคิดเรื่องนี้ไม่ใช่จากมุมการโจมตีบริษัท แต่จากมุม สิทธิผู้บริโภคหรือการบอยคอต
      เพราะมีประสบการณ์แย่มากกับบริษัทใหญ่ที่ชูการเพิ่มมูลค่าสูงสุดให้ผู้ถือหุ้น จึงย้อนดูบันทึกอีเมลเก่า ๆ แล้วทำเครื่องหมายการสื่อสารทั้งหมดของบริษัทนั้นว่าเป็นสแปม
      มันอาจเป็นแค่หยดน้ำหยดเดียว แต่ในโลกของสแปมอาจไม่จำเป็นต้องมีคะแนนเสียงมากนัก
      การส่งอีเมลดูเหมือนจะพัฒนาไปสู่ โมเดลจ่ายเงินเพื่อผ่าน ที่ชัดเจนยิ่งขึ้น และอาจมีข้อตกลงเบื้องหลังอยู่แล้วก็ได้
    • นั่นเป็นเหตุผลที่เว็บไซต์อีคอมเมิร์ซส่วนใหญ่ส่งอีเมลการตลาดจาก โดเมนแยกต่างหาก
      แม้โดเมนนั้นจะถูกแจ้งสแปม อีเมลธุรกรรมก็ยังส่งจากโดเมนหลักต่อไปได้
      แน่นอนว่าต้องอยู่บนสมมติฐานว่าเมลเซิร์ฟเวอร์ทั้งสองอยู่คนละ IP กัน
    • เว็บฟอรัมที่ผมรู้จักมีกฎว่าอย่าทำเครื่องหมายอีเมลแจ้งเตือนที่พวกเขาส่งว่าเป็นสแปม
      คือสามารถยกเลิกรับบนเว็บไซต์ได้ แต่อยากให้ไม่จัดเป็นสแปมจากฝั่งอีเมลไคลเอนต์
      สำหรับองค์กรเล็ก ๆ นี่อาจเป็นความเสี่ยงที่เป็นจริงพอสมควร
      ส่วนองค์กรใหญ่บรรเทาอย่างไรนั้นผมไม่ค่อยแน่ใจ
    • ผมคิดว่านั่นน่าจะป้องกันได้ด้วย นโยบาย DMARC ไม่ใช่หรือ
      ถ้าอีเมลที่ผู้โจมตีส่งไม่ผ่าน SPF/DKIM ก็สามารถตั้งนโยบาย DMARC เพื่อไม่ให้ Gmail ส่งต่อเมลปลอมนั้นตั้งแต่แรกได้
      แบบนั้นการโจมตีลักษณะนี้ก็เกิดขึ้นไม่ได้
  • การเปลี่ยนแปลงนี้จำเป็น และมาช้าเกินไปมาก
    ถ้ากำหนดให้เจ้าของโดเมนที่ส่งอีเมลจำนวนมากต้องลงนามข้อความอย่างถูกต้อง ผู้รับก็จะแยกเมลดีออกจากเมลร้ายได้ชัดเจนขึ้น โดยอิงจาก ชื่อเสียงของโดเมน ไม่ใช่ชื่อเสียงของ IP address
    ในสถานการณ์ที่มีโดเมนจำนวนมากขึ้นเรื่อย ๆ ส่งอีเมลผ่านพื้นที่ IP ร่วมกันของบริการธุรกรรมและการตลาด ความสามารถในการผูกชื่อเสียงเข้ากับโดเมนผู้ส่งอย่างมั่นคงมีประโยชน์มากในการลดการใช้งานในทางที่ผิด

    • เงื่อนไขที่ว่า “จำนวนมาก” นั้นไม่จริง
      Google บอกว่าข้อกำหนดใหม่บังคับใช้เฉพาะเมื่อส่งมากกว่า 5,000 ฉบับต่อวัน แต่นั่นไม่จริง
      ผมส่งอย่างมากก็วันละไม่กี่ฉบับ โดยปกติแทบไม่ถึงวันละฉบับไปยังบัญชี Gmail และ implement แค่บางข้อกำหนด แต่ Google ก็เริ่มปฏิเสธข้อความของผม
      สุดท้ายต้องเสียเวลา implement ข้อกำหนดทั้งหมด รวมถึงบางอย่างที่ค่อนข้างซ้ำซ้อน
    • ในฐานะผู้ดูแลระบบ ผมสงสัยว่าควรทำอย่างไรเมื่ออีเมล 5% เข้าโฟลเดอร์สแปมเพราะการตั้งค่าเมลเซิร์ฟเวอร์ Office365 ฝั่งผู้รับผิดพลาด
      โดยรวมแล้วผมเห็นด้วยว่านี่เป็นการเปลี่ยนแปลงเชิงบวก แต่เมื่อเหตุผลที่อีเมลเข้าโฟลเดอร์สแปมคือการตั้งค่าผิดจากฝั่งผู้รับ มันน่าหงุดหงิดจริง ๆ
      เช่น มีกรณีที่ SPF พังระหว่างการส่งต่อ
    • พวกเราก็กำลังค่อย ๆ ย้ายไป IPv6 เช่นกัน และถ้าสามารถมี IP address ใหม่ได้มากเท่าที่ต้องการ ชื่อเสียงแบบอิง IP ก็น่าจะไร้ประโยชน์ไปพอสมควร
      หากผู้ส่งที่ประสงค์ร้ายสามารถส่งอีเมลแต่ละฉบับจากที่อยู่ IPv6 ที่ต่างกันได้ ก็อาจต้องตั้งค่าให้ไม่เชื่อถือที่อยู่ IPv6 ที่ดูเหมือนใหม่ทั้งหมดโดยปริยาย
    • เห็นด้วย นี่คือข้อดีที่ชัดเจน
      แม้จะไม่สะดวก แต่หวังว่าการเปลี่ยนแปลงนี้จะช่วยจัดระเบียบ ecosystem ของอีเมลได้
  • สแปมแยกไม่ออกจากคอนเทนต์อันตราย
    คุณไม่เคยสมัคร “จดหมายข่าว” นั้น และที่อยู่อีเมลของคุณถูกเก็บรวบรวมแล้วส่งต่อให้ผู้ไม่หวังดีที่ต้องการรบกวนคุณ
    หากคลิกอะไรก็ตาม คุณจะถูกพาไปยังเว็บไซต์ของบริษัทนั้น ซึ่งมีข้อมูลของคุณและจะไม่คำนึงถึงประโยชน์ของคุณเลย
    กรณีดีที่สุด คุณก็แค่กำจัดแหล่งขยะใน inbox ได้หนึ่งแหล่ง และกรณีแย่ที่สุด คุณอาจคลิกบางอย่างที่ติดตั้งมัลแวร์ลงในคอมพิวเตอร์
    ดังนั้น อย่าคลิกลิงก์ยกเลิกรับ ให้กดปุ่มแจ้งสแปม และเลิกใช้บริการอีเมลรายใหญ่ที่เพิกเฉยต่อการแจ้งสแปม
    Gmail ปล่อยให้บริษัทใหญ่รายอื่นส่งสแปมถึงคุณ แถมยังไม่ให้ตัวเลือกบล็อกทั้งโดเมนโดยตรง
    คอนเทนต์อันตรายจะยังคงเข้ามาใน inbox จนกว่าคุณจะย้ายไปใช้ผู้ให้บริการอีเมลที่ให้ความสำคัญกับความเป็นส่วนตัวและความปลอดภัยอย่างจริงจัง

    • เป็นการประเมินที่สมเหตุสมผล
      อยากรู้ว่าใช้ผู้ให้บริการอีเมลเจ้าไหนอยู่
  • น่าประหลาดใจที่บริษัทใหญ่จำนวนมากขนาดนี้ไม่ผ่านการทดสอบ ยกเลิกการรับแบบคลิกเดียว
    เช่น Cloudflare หรือ Akamai บล็อกการเชื่อมต่อ, หน้าเว็บโหลดนานกว่า 5 วินาที, หรือบังคับให้ล็อกอินหรือกรอกอีเมลใหม่
    แล้วก็ไม่ควรแปลกใจถ้าลูกค้ากดปุ่มรายงานสแปม

    • อีเมลที่ฉันไม่ได้ยินยอมรับ ฉันจะไม่กดยกเลิกการรับ
      ดังนั้นฉันจึงกดรายงานสแปม
    • ฉันใช้ NextDNS พร้อมแนบรายการบล็อกโฆษณา ซึ่งแทบจะเป็น Pi-hole บนคลาวด์
      สิ่งที่น่ารำคาญที่สุดคือผู้ส่งอีเมลทำ การติดตามคลิก ผ่านโดเมนที่ถูกบล็อกโดยรายการบล็อกโฆษณา
      ฉันมีอินสแตนซ์เบราว์เซอร์แยกไว้สำหรับคัดลอกลิงก์แบบนั้นไปวาง แต่พอทำแบบนั้นก็ต้องล็อกอินอีก
      ฉันชอบส่งอีเมลขอยกเลิกรับมากกว่าคลิกลิงก์ และ Gmail ก็ทำสิ่งนี้แบบอัตโนมัติได้
    • ฉันจะยกเลิกรับอยู่แล้ว แต่ในปี 2024 คำพูดไร้สาระอย่าง “อาจใช้เวลาถึง 14 วันจึงจะมีผล” นั้นยอมรับไม่ได้แล้ว
      ถ้ามีอีเมลมาอีกภายในไม่กี่วัน ฉันจะทำเครื่องหมายว่าเป็นสแปม
      ถ้า TripAdvisor สร้างแผนการเดินทางที่ AI สร้างขึ้นได้ ก็ควรหาวิธีที่จะไม่ส่งมันมาทางอีเมลได้เช่นกัน
    • สุดท้ายแล้วฉันมองว่าเป็นเพียง การแข่งขันด้าน UI
      ลูกค้าจะเลือกวิธีที่สะดวกกว่า ไม่ว่าจะเป็นการยกเลิกรับหรือรายงานสแปม
  • หนึ่งในสิ่งที่การเปลี่ยนแปลงเดือนเมษายนทำให้พังคือ การส่งต่อ ระหว่างบริการอีเมล
    ตัวอย่างเช่น หากเคยส่งต่อจากที่อยู่อีเมลมหาวิทยาลัยเดิม foo@school.edu ไปยังบัญชี Gmail ส่วนตัว bar@gmail.com ต่อไปก็น่าจะใช้งานไม่ได้แล้ว
    ดูจากการที่ผู้ให้บริการรายใหญ่ผลักดันเรื่องนี้ กรณีใช้งานนี้คงค่อนข้างหายาก แต่สำหรับคนที่ได้รับผลกระทบก็เป็นการเปลี่ยนแปลงที่น่ารำคาญไม่น้อย

    • ไม่เข้าใจว่าทำไมถึงบอกว่าจะใช้งานไม่ได้แล้ว
      ตอนส่งต่ออีเมล ตราบใดที่ผู้ส่งต่อไม่แก้ไขเนื้อหาข้อความ มันก็ยังตรงกับลายเซ็น DKIM และควรผ่านได้
    • นี่ไม่ใช่การเปลี่ยนแปลงใหม่
      SPF ทำให้ตัวส่งต่อที่ไม่แตะที่อยู่ผู้ส่งใน envelope พังมาโดยตลอด และนั่นก็ถูกต้องและเหมาะสมแล้ว
      ยังส่งต่ออีเมลได้อยู่ แต่ผู้ส่งต่อต้องเขียน return path ใหม่
    • เรื่องนี้ค่อนข้างสำคัญ งั้นหมายความว่าต่อไปการส่งต่ออีเมลจะทำไม่ได้แล้วหรือ?
  • น่าประหลาดใจที่ยังมีคนปล่อยให้อีเมลผ่าน ทั้งที่ไม่ได้ตั้งค่า SPF, DKIM, DMARC ไว้อย่างสมบูรณ์
    ฉันเคยรัน เซิร์ฟเวอร์อีเมลส่วนตัวแบบโฮสต์เอง ที่ตั้งค่าไว้อย่างดีมาหลายปี แต่ก็ยังเจอความยากลำบากเป็นครั้งคราวในการทำให้อีเมลผ่าน ถึงอย่างนั้นก็ดูเหมือนจะค่อย ๆ ดีขึ้น

    • การตั้งค่า SPF, DKIM, DMARC อย่างสมบูรณ์ไม่ได้หมายความว่าเซิร์ฟเวอร์ฝั่งรับจะมองแบบนั้น
      โดยเฉพาะเซิร์ฟเวอร์ของ Microsoft มักสุ่มตัดสินว่า การตั้งค่า DKIM ที่ไม่มีปัญหาอะไรล้มเหลวโดยไม่มีเหตุผล
    • ไม่ใช่แค่เรื่องการตั้งค่า แต่ ชื่อเสียง ก็สำคัญด้วย
      หากปริมาณการส่งต่ำ ก็เสี่ยงถูกทิ้งได้เพียงเพราะไม่ใช่ผู้ส่งที่เป็นที่รู้จัก
    • ฉันก็สู้กับปัญหานี้มาหลายปีแล้ว
      ในเมื่อ 3 รายใหญ่เผยแพร่แนวทางพวกนี้และทำให้โปร่งใสขึ้น ก็หวังว่าพฤติกรรมจะสม่ำเสมอมากขึ้น
    • จากประสบการณ์ของฉัน DKIM ไม่จำเป็น และแม้ในแนวทางใหม่ของ Google หากใช้ SPF ก็ยังไม่ถือว่าบังคับ
    • น่าประหลาดใจที่ผู้คนมองความสามารถในการส่งอีเมลถึงปลายทางแค่ผ่านการตั้งค่า SPF, DKIM, DMARC
      สแปมเมอร์ก็ทำแบบเดียวกันได้ เพราะกำแพงในการเข้ามาต่ำ
      มันสำคัญก็จริง แต่เกี่ยวข้องกับ การส่งถึงปลายทาง ในโลกจริงน้อยมาก
  • สิ่งที่ยากที่สุดของ DMARC คือมันล้มเหลวบ่อย โดยเฉพาะกับ Microsoft
    และยังมีปัญหาในทุกกรณีใช้งานที่ผู้รับส่งต่ออีเมลด้วย เพราะตอนนั้น การจัดแนว SPF จะพัง
    เพราะอยากทำตามแนวปฏิบัติที่ดี เมื่อไม่นานมานี้ฉันจึงเปลี่ยน p=quarantine เป็น p=none
    เพราะกลัวว่าอีเมลที่ถูกต้องตามกฎหมายจะไม่ผ่าน DMARC ทั้งที่ตั้งค่า DKIM และ SPF อย่างถูกต้องแล้ว
    ฉันอยากใช้ p=reject จริง ๆ แต่คงทำไม่ได้จนกว่าเซิร์ฟเวอร์เมลฝั่งรับจะแก้ไขให้รองรับกรณียกเว้นแบบเดียวกันที่การส่งต่ออีเมลทำให้ DMARC พัง

    • ผู้ส่งที่บังคับใช้ DMARC และต้องการให้อีเมลของตนถูกส่งต่อได้ควรใช้ DKIM
      การส่งต่อข้อความที่เซ็นด้วย DKIM ไม่ได้ทำให้ DMARC พังเลย
  • สิ่งที่แย่ที่สุดคือรับอีเมลไว้แล้วทำเครื่องหมายเป็นสแปมแบบเงียบ ๆ จากนั้นโยนไปไว้ในที่ที่ผู้รับที่ตั้งใจไว้จะไม่มีวันเห็น
    Gmail ของ Google ทำแบบนี้หนักที่สุด
    อีเมลองค์กรไม่ใช่อีเมลอีกต่อไป แต่เป็น สวนที่มีกำแพงล้อม และไซโลแบบ Facebook

    • ดีแล้วที่มีกำแพงแบบนั้น
      ไม่อย่างนั้นเราคงจมสแปมอีเมลขายของแบบ cold email ไปแล้ว
      พูดจริง ๆ คือผมเลิกดูแลและบริหารเซิร์ฟเวอร์เอง แล้วให้ทุกบริษัทใช้ Gmail
      เป็นเรื่องน่าเศร้าที่สิ่งนี้กลายเป็นเรื่องยากขนาดนี้
      หากไม่ได้อยู่บน Gmail Workspace ที่ตั้งค่าไว้อย่างดี ก็รู้สึกว่าแม้แต่อีเมลที่ถูกต้องตามกฎหมายก็แทบไม่มีโอกาสผ่าน
    • น่าหงุดหงิดจริง ๆ
      ตามที่ฉันเข้าใจ ดูเหมือนพวกเขาไม่อยากส่ง สัญญาณ ให้สแปมเมอร์รู้ว่าข้อความถูกตัดสินว่าเป็นอีเมลปกติหรือสแปม
      ฉันอยากรู้ว่าสแปมเมอร์ใช้ข้อมูลแบบนั้นอย่างฉลาดจริง ๆ แค่ไหน
      สแปมส่วนใหญ่ดูเหมือนเป็นการยิงถล่มที่ไม่สนใจฟีดแบ็กความล้มเหลว
      บนเซิร์ฟเวอร์เมลของฉัน ข้อความที่ถูกจัดเป็นขยะจะถูกปฏิเสธชั่วคราวต่อไปพร้อมข้อความผิดพลาดทั่วไป
      อย่างน้อยผู้ส่งที่ถูกต้องตามกฎหมายแต่ถูกจัดผิดก็จะได้รับ DSN ที่ล่าช้า และสุดท้ายได้รับฟีดแบ็กว่าข้อความไม่ได้ถูกส่งถึง
      ดูเหมือนเซิร์ฟเวอร์เมลและบริการจำนวนมากให้ความสำคัญกับการไม่ส่งสัญญาณให้สแปมเมอร์ มากกว่าการให้สัญญาณที่มีประโยชน์แก่ผู้ใช้ที่ถูกต้องตามกฎหมายซึ่งถูกจัดประเภทผิด
      บางทีพวกเขาอาจคิดว่าการจัดประเภทของตัวเองยอดเยี่ยมมากจนไม่เกิด false positive เลยก็ได้
    • ไม่ได้บอกว่าถูกต้อง แต่ได้ผล
      ตัวกรองสแปมและตัวกรองโปรโมชันของ Gmail นั้นเชื่อถือได้ มากกว่า 99% จากมุมมองผู้ใช้ และ false positive ก็น้อยมากจริง ๆ
    • น่าเสียดายที่การคุ้มครองทางกฎหมายจำนวนมากต่อสแปมที่ไม่ได้ร้องขอใช้กับการใช้งานของผู้บริโภคเท่านั้น
      ใน B2B ถ้านักการตลาดรู้ที่อยู่อีเมลของคุณ ก็เหมือนมีสิทธิ์ส่งข้อความมาได้มากเท่าที่ต้องการ
      ถ้าไม่มีกำแพง มันคงใช้การไม่ได้อย่างสิ้นเชิง
  • VM ส่วนตัวของผมไปติดอยู่ใน RBL บางรายการ เพราะพื้นที่ที่อยู่ /24 ทั้งช่วง ถูกขึ้นบัญชีดำ
    ได้ยินว่ามีใครบางคนส่งสแปม และตอนนี้เครื่องของผมที่ส่งอีเมลแค่ประมาณสามฉบับต่อสัปดาห์ก็ถูกบล็อกไปด้วย

    • ปัญหาคือผู้ให้บริการ VM กำลังให้พื้นที่ที่อยู่เดียวกันนี้กับสแปมเมอร์โดยไม่ได้ตั้งใจ
      สแปมเมอร์อาจใช้ที่อยู่สุ่มภายในช่วงนั้น หรืออาจมีใครตั้งค่าเซิร์ฟเวอร์ SMTP ผิดพลาดจนอนุญาตให้รีเลย์ได้
      การรันเซิร์ฟเวอร์ SMTP ขาออกในช่วง IP ของลูกค้าก็มีแนวโน้มจะเป็นปัญหาอยู่แล้ว
      ช่วงแบบนั้นถือว่าน่าสงสัยได้ทั้งหมด เพราะสแปมเมอร์ใช้โดยไม่สนใจชื่อเสียง
    • ใช่เลย เรื่องนี้เจ็บปวดมาก
      ดูเหมือนผู้ดูแลรายการบล็อกจะตรวจสอบรายงานการละเมิดได้ไม่ดีนัก หรือจงใจสร้าง ความเสียหายข้างเคียง เพื่อกดดันให้ผู้ดูแลเครือข่ายลงมือจัดการ
      ผมไม่ชอบการถูกใส่ในรายการบล็อก แต่สำหรับอินเทอร์เน็ตโดยรวมอาจมีผลสุทธิที่ดีอยู่ก็ได้
      ผมมองว่าเมลเซิร์ฟเวอร์และบริการต่าง ๆ ใช้รายการบล็อกแบบอิง IP กันผิดวิธี
      ควรใช้เป็นเพียงสัญญาณหนึ่งในหลายสัญญาณ และอาจให้น้ำหนักมากขึ้นกับผู้ส่งที่ไม่เคยเห็นมาก่อน
      แต่ถ้า IP ที่เคยรับส่งข้อความที่ยืนยันตัวตนด้วย SPF/DKIM/DMARC และมีธุรกรรมต่อเนื่องกัน จู่ ๆ ถูกใส่ในรายการบล็อก ชื่อเสียงเชิงบวกเดิมควรมีน้ำหนักมากกว่าการถูกบล็อกนั้น
      ควรยังสื่อสารกับคู่ติดต่อที่รู้จักกันได้ต่อไป และค่อยปฏิเสธการส่งต่อหรือจัดเป็นขยะในภายหลังหลังจากที่พวกเขาทำเครื่องหมายว่าเป็นสแปมแล้ว
      ตอนนี้ดูเหมือนเมลเซิร์ฟเวอร์และบริการจำนวนมากจะใช้รายการบล็อก IP ตั้งแต่ช่วงต้นของกระบวนการ SMTP เพื่อลดภาระระบบ
      ดีต่อภาระระบบ แต่แย่ต่อประสิทธิภาพการวิเคราะห์
      โดยรวมแล้ว แม้แต่บริการอีเมลฟรีรายใหญ่ก็ดูมีความสามารถไม่ดีนักในการใช้ชื่อเสียงเดิมมาช่วยตัดสินว่าอีเมลปกติหรือสแปม
      เมื่อเร็ว ๆ นี้ผมเปลี่ยนเว็บเซอร์วิสออนไลน์ที่ทำไว้ให้สมัครโดยใช้อีเมล เป็นวิธีส่งอีเมลไปยังที่อยู่เฉพาะเพื่อสมัคร คล้ายกับการสมัคร mailing list
      แนวคิดคือเมื่อผู้ใช้ส่งอีเมลถึงบริการของผม ผมก็จะเข้าไปอยู่ในรายชื่อคู่ติดต่อที่ผู้ใช้รู้จัก
      ดังนั้นอีเมลตอบกลับยืนยันที่มี SPF/DKIM/DMARC aligned จากเมลเซิร์ฟเวอร์ของผมก็ควรถูกยอมรับโดยธรรมชาติ
      ยังต้องมีการ opt-in ที่ชัดเจนกว่านี้อีกแค่ไหนกัน
      พอทดสอบกับบริการอีเมลฟรีรายใหญ่บางเจ้า Yahoo ถึงกับเอาอีเมลตอบกลับยืนยันที่อ้างอิงข้อความต้นฉบับไปไว้ในโฟลเดอร์ขยะ
      สำหรับคนที่คิดว่าแข่งกับบริการอีเมลรายใหญ่ไม่ได้ ผมอยากบอกว่ามาตรฐานไม่ได้สูงอย่างที่คิด
    • น่าเห็นใจจริง ๆ
      การกู้ชื่อเสียงให้กลับมานั้น ต่อให้ทำได้ดีก็แทบจะเป็นฝันร้าย
      ผมเคยเห็นคำแนะนำว่าให้ซื้อโดเมนอื่นแล้วส่งอีเมลจากโดเมนนั้นเพื่อปกป้องโดเมนหลัก แต่ก็ไม่ค่อยอยากทำเท่าไร
  • ดูเหมือนในบทความจะใช้ ซองจดหมาย (RFC5321) กับ เฮดเดอร์ (RFC5322) ปนกัน
    มีข้อความว่า “ชื่อโดเมนในฟิลด์ From: ของเฮดเดอร์ซองจดหมายอีเมลจะถูกตรวจสอบและจัดแนวกับโดเมนอื่นที่ยืนยันตัวตนด้วย SPF หรือ DKIM” แต่ซองจดหมายไม่มีเฮดเดอร์ และเฮดเดอร์อยู่ในเนื้อหา/บอดี้ของอีเมล
    ภาพหน้าจอที่เขียนว่า “ตัวอย่างซองจดหมายอีเมลขององค์กรที่ผ่านแนวทางความปลอดภัยอีเมลทั้งหมด” ก็เป็นเมลเฮดเดอร์ ไม่ใช่ข้อมูลซองจดหมาย
    มีสไลด์นำเสนอที่ดีของ dmarc.org เกี่ยวกับหัวข้อนี้
    https://dmarc.org/presentations/Email-Authentication-Basics-...