SRS จำเป็นต้องเขียนใหม่หรือไม่สำหรับผู้ส่งต่อจดหมาย

ฉันใช้งานเซิร์ฟเวอร์อีเมล Postfix สำหรับโดเมนพูด mydomain.com ส่วนใหญ่จะทำหน้าที่เป็นเซิร์ฟเวอร์อีเมลที่ส่งต่อ: ผู้ใช้จะได้รับที่อยู่อีเมล @ mydomain.com แต่มักจะเลือกให้มีที่อยู่ของพวกเขาส่งต่อไปยังกล่องจดหมายภายนอก (Gmail, Yahoo, ฯลฯ ) มีที่อยู่ไม่กี่พันที่ถูกส่งต่อดังนั้นเซิร์ฟเวอร์จะจัดการปริมาณการรับส่งจดหมายที่ค่อนข้างเป็นธรรม

ในอดีตเซิร์ฟเวอร์ไม่ได้ใช้ SRS เขียนใหม่ หลักสูตรนี้หมายความว่าเมลที่ส่งต่อจะล้มเหลวในการตรวจสอบ SPF เนื่องจากที่อยู่ IP ของฉันไม่ได้รับอนุญาตทางเทคนิคในการส่งอีเมลในนามของโดเมนของผู้ส่งดั้งเดิม อย่างไรก็ตามจากสิ่งที่ฉันเห็นมันดูเหมือนจะไม่ก่อให้เกิดปัญหาที่สำคัญใด ๆ โดยทั่วไปไม่มีการร้องเรียนจากผู้ใช้เช่น Gmail, Yahoo และอื่น ๆ ดูเหมือนว่าฉลาดพอที่จะเพิกเฉยต่อความล้มเหลวของ SPF และส่งข้อความได้อยู่ดี

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

จริงอยู่ที่ฉันได้ใช้มาตรการป้องกันที่แนะนำบางอย่างเช่นการใช้ SpamAssassin เพื่อเพิ่ม "สแปม" ในบรรทัดเรื่องของสแปมที่น่าสงสัยก่อนที่จะส่งต่อไม่ส่งต่อความมั่นใจสูง (คะแนน 15+) สแปมและการใช้รายการบล็อกสแปม สมบูรณ์แบบและสแปมยังสามารถผ่านเครื่องหมายไม่มีเครื่องหมาย

การเปิดใช้งาน SRS ใหม่จะคุ้มค่าหรือไม่หากเพิ่มความเสี่ยงในการทำเครื่องหมายผิด ๆ ว่าเป็นผู้ส่งสแปม หรือจะปลอดภัยกว่าถ้าปล่อยไว้เฉยๆและละเว้นความล้มเหลวของ SPF

postfix spam spamassassin

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

ฉันรู้จากประสบการณ์ว่า ISP บางรายในสหราชอาณาจักรจะปฏิเสธอีเมลขาเข้าที่อ้างว่ามาจากลูกค้าของพวกเขาเอง แต่ยังไม่ได้ส่งจากอีเมลของพวกเขาเอง เช่นเดียวกันอาจกลายเป็นจริงสำหรับ Gmail, Yahoo และ AOL สถานการณ์ดังกล่าวสามารถแก้ไขได้โดยการเขียนที่อยู่ผู้ส่งอีกครั้ง

— roaima

คำตอบ:

สำหรับฉันแล้วสิ่งที่คำถามของคุณเพิ่มขึ้นคือ " มีเซิร์ฟเวอร์อีเมลกี่เครื่องที่ตรวจสอบระเบียน SPF ของอีเมลขาเข้า " หากเป็นส่วนใหญ่ SRS เป็นข้อกำหนดที่แน่นอนสำหรับเซิร์ฟเวอร์การส่งต่อ หากไม่มีเลยคุณไม่จำเป็นต้องใช้ SRS

น่าเสียดายที่ฉันไม่สามารถทำงานวิชาการใด ๆ ได้ในทันที แต่เนื่องจากฉันตรวจสอบ SPF ในอีเมลขาเข้าฉันสามารถพูดได้อย่างมั่นใจว่ามีบางเซิร์ฟเวอร์อีเมลตรวจสอบ ลูกค้าของคุณที่มีเซิร์ฟเวอร์ของคุณส่งต่อไปยังบัญชีในเซิร์ฟเวอร์ของฉันจะสูญเสียอีเมลที่ส่งจากผู้ส่งที่โฆษณา SPF ที่สิ้นสุด (ตามที่ควรจะเป็น) -allยกเว้นว่าคุณใช้ SRS ดังนั้นผมจึงสามารถพูดด้วยความมั่นใจว่าโดยไม่ต้อง SRS บางส่วนของอีเมลของลูกค้าของคุณจะไม่ถูกส่ง

ฉันขอโทษ Marc ที่ฉันไม่สามารถอ่านภาษาเยอรมันได้ดังนั้นฉันจึงไม่สามารถพูดได้ว่า PDF ที่เขาเสนอราคานั้นมีข้อโต้แย้งที่น่าสนใจหรือไม่ แต่ฉันสามารถยืนยันได้ว่าไม่มี SRS อีเมลของลูกค้าบางส่วนจะไม่ถูกส่งออกไป ฉันไม่สามารถบอกได้ว่าเศษส่วนนั้นคืออะไร แต่มันไม่ได้เป็นศูนย์และที่ได้รับมาฉันไม่คิดว่าคุณมีทางเลือกอื่นนอกจากเรียกใช้ SRS

ฉันยอมรับว่าเซิร์ฟเวอร์ของคุณจะไม่ช่วยตัวเองด้วยการส่งต่อสแปม แต่ในประสบการณ์ของฉันส่วนใหญ่ของความเสียหายชื่อเสียงจะทำไปยังที่อยู่ IP ของมันไม่ใช่โดเมนซองจดหมาย - จาก; สิ่งนี้จะทำโดยไม่คำนึงถึงการใช้ SRS

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

ในระยะสั้นฉันจะบอกว่าคุณต้องการ SRS ในระยะสั้นและรูปแบบธุรกิจใหม่ในระยะยาว

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

สิ่งนี้คือ SRS เป็นวิธีการแก้ไขปัญหาการส่งต่อของ SPF SRS เขียนใหม่เช่น user @ A ถึง A = user @ B และระเบียน SPF ของ B นั้นอยู่ในความดูแล ปัญหา: B ยังสามารถปลอมที่อยู่! ดังนั้นบางคนจึงเพิ่ม crypt-hashes และ time stamps ไปยังที่อยู่ที่เขียนใหม่ เพื่อให้การทำงานในระดับที่ยอดเยี่ยมนั้นต้องการการยอมรับทั่วโลกซึ่งไม่ได้มี มันจะใช้งานได้ก็ต่อเมื่อมีบางสิ่งถูกส่งต่อครั้งเดียว แต่ไม่มาก คำตอบก็เป็นปัญหาเช่นกัน โปรดทราบว่า SPF เป็นเทคนิคในการปกป้องโดเมนของคุณในทางที่ผิดไม่มีอะไรเพิ่มเติม

— Marc Stürmer

@ MarcStürmer " SRS เป็นวิธีการแก้ไขปัญหาการส่งต่อค่า SPF ": ใช่นั่นคือสิ่งที่มันเป็น SPF เป็นที่รู้จักกันว่าการส่งต่อแบบง่าย ๆ หากคุณไม่คิดว่า SRS เป็นราคาที่คุ้มค่าแก่การลงทุนอย่าโฆษณาเรคคอร์ด SPF " ปัญหา: B ยังคงปลอมแปลงที่อยู่ ": ไม่ใช่โดเมนของ A หรือโดเมนอื่นใดที่ได้รับการปกป้องโดยระเบียน SPF ที่เหมาะสมมิเช่นนั้นอีเมลจะถูกปฏิเสธภายใต้ SPF แต่นอกจากนั้นใช่มันทำได้และฉันไม่เห็นว่ามันเป็นปัญหา " SPF เป็นเทคนิคในการปกป้องโดเมนของคุณจากการละเมิดไม่มีอะไรเพิ่มเติม ": ฉันเห็นด้วย

— MadHatter

@ MarcStürmer: "ใช้งานได้เฉพาะหากมีการส่งต่อบางครั้ง แต่ไม่เกิน" มันผิด. SRS ทำงานได้ดีกับเซิร์ฟเวอร์ส่งต่อหลายตัว มันจะทนทุกข์ก็ต่อเมื่อไม่มีเซิร์ฟเวอร์ที่ติดแท็กในบรรทัด แต่นี่เป็นปัญหาเดียวกันกับเซิร์ฟเวอร์ที่ไม่ติดแท็กทั่วไปโดยทั่วไปไม่ว่าจะเป็น hop หรือส่งต่อในภายหลัง ในโลกของ SPF คุณไม่จำเป็นต้องใช้ SRS คุณเพียงแค่ต้องรับผิดชอบต่อจดหมายที่ส่งต่อและตรวจสอบให้แน่ใจว่าคุณสามารถส่งคืนได้ SRS เป็นเพียงเทคนิคเดียวที่ทำเช่นนี้ Google เช่นใช้สิ่งที่แตกต่าง

— Adrian Zaugg

ปัญหาคือการใช้ SRS แบ่งการตรวจสอบการจัดตำแหน่ง DMARC (เช่นผู้ส่งซองจดหมาย! = From:-header) และจะทำให้ Gmail ปฏิเสธข้อความหากโดเมนในFrom:ส่วนหัวมีp=rejectนโยบาย DMARC ของพวกเขา หากคุณเขียนFrom:ซ้ำเช่นกันเมลจะถูกตรวจสอบตามกฎของโดเมนของคุณเอง แต่การตรวจสอบ DKIM จะล้มเหลวและผู้ส่งที่แสดงในโปรแกรมรับส่งเมลจะถูกจัดการ

— mbirth

@mbirth afaik คุณพูดถูก แต่โดยส่วนตัวแล้วผมถือว่า DMARC เป็นภัยพิบัติที่สมบูรณ์ไม่น้อยเพราะมันทำลายรายชื่อผู้รับจดหมายเพียงฝ่ายเดียวและ (ในฐานะผู้ดูแลระบบของรายชื่อชุมชนขนาดใหญ่) เพียงแค่แนะนำผู้คนให้ใช้ ISP ที่เผยแพร่p=rejectนโยบาย ถ้า SRS แบ่ง DMARC นั่นก็เป็นเรื่องยากสำหรับ DMARC

— MadHatter

SRS ดูเหมือนจะเป็นความคิดที่ดีบนกระดาษ แต่ทำงานได้ไม่ดีนักตาม Heinlein Support (พวกเขาใช้บริการจดหมายขนาดกลางที่มีบัญชีมากกว่า 100,000 บัญชี)

รายละเอียดอยู่ในการพูดคุยของพวกเขา แต่เป็นภาษาเยอรมันทำไม: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

เหตุผลหลักคือ SRS เป็นแพทช์ขนาดเล็กสำหรับปัญหาร้ายแรงของการใช้ SPF ในความเป็นจริงเนื่องจาก SPF ไม่ครอบคลุมกรณีการใช้งานทั่วไปของอีเมลได้เป็นอย่างดี เพื่อให้ SRS มีเหตุผลแม้ว่าจะต้องมีการปรับใช้บนเซิร์ฟเวอร์ขนาดใหญ่ซึ่งไม่น่าจะเกิดขึ้น ดังนั้นจนกว่าจะมีการปรับใช้บนฐานของเซิร์ฟเวอร์ขนาดใหญ่มันก็ไม่สมเหตุสมผลเลย

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

ถ้าคุณต้องการให้ส่งเมลของคุณไปยังผู้ให้บริการอีเมลขนาดใหญ่อย่าง Gmail, Hotmail และอื่น ๆ คุณควรติดตั้งอย่างน้อย DKIM และ DMARC แต่ควรตั้งให้ล้มเหลวอย่างนุ่มนวลที่สุดและอาจใช้กลไก จำกัด อัตราในการส่งจดหมาย จะทำงานมหัศจรรย์สำหรับคุณ

ปัญหานี้กับผู้ให้บริการรายใหญ่เป็นสาเหตุที่ปัจจุบันมีบริการเช่น Mailchimp, Mandrill หรือ Returnpath ผู้ให้บริการเหล่านั้นจ่ายเงินให้กับ Google & Co เพื่อคุณภาพการจัดส่งที่ดีขึ้น

— Marc Stürmer
แหล่งที่มา

ปัญหานี่คือ SPF ไม่ใช่ SRS ตราบใดที่ ISP บางรายใช้ SPF คุณจะต้องใช้ SRS (หรือสิ่งที่คล้ายกัน) เพื่อให้การส่งต่อทำงานกับพวกเขาทั้งหมด ปัญหาเกี่ยวกับ greylisting นั้นแตกต่างกันคุณควร "คลาย" SRS ที่ติดแท็กที่อยู่ผู้ส่งสำหรับ greylisting (เช่นเดียวกับ BATV ที่ติดแท็กเมล)

— Adrian Zaugg

ฉันเห็นด้วยกับแต่ละคำของ @MadHatter แต่ข้อเท็จจริงสำคัญเกี่ยวกับ Google!

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

ในกรณีนี้ - gmail รู้ว่าคุณเป็นผู้ส่งต่อสำหรับอีเมลนี้และไม่ได้ตั้งค่าสถานะการส่งต่อว่าเป็นสแปมแม้ว่าจะตรวจสอบค่า SPF ไม่สำเร็จก็ตาม

คุณสามารถส่งอีเมลลูกค้าของคุณได้จาก bill@microsoft.com ข้อความจะเข้าสู่กล่องจดหมายโดยไม่มีการเตือน! (Microsoft มี -allในบันทึก spf)

ตรวจสอบและตรวจสอบแล้ว ตัวอย่างที่แนบมา

ข้อความนี้ไปที่กล่องจดหมาย

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