เซิร์ฟเวอร์ iRedMail กำหนดค่าโดยใช้เซิร์ฟเวอร์ DNS ของ ISP ใช้งานหลายปีไม่มีปัญหา การย้ายจาก ISP ปัจจุบันไปยัง Starlink ดูเหมือนว่า Starlink ใช้ DNS สาธารณะของ Cloudflareขณะนี้มี ISP ทั้งสองทำงานแบบขนานจนกว่าการตัดต่อจะเสร็จสมบูรณ์ อีกครั้ง เมลเซิร์ฟเวอร์ทำงานได้ดีบน ISP เดิม
เมื่อฉันตัดไปที่ Starlink (รวมถึงการเปลี่ยนแปลง DNS สาธารณะที่เหมาะสม) ได้รับข้อผิดพลาด 12.255.255.254 จาก Spamhaus ซึ่งระบุว่า พวกเขาจะไม่อนุญาตให้มีการสืบค้นจากเซิร์ฟเวอร์ DNS สาธารณะ. ยุติธรรมเพียงพอ ตั้งค่าตัวแก้ไข Unbound ในเครื่องเพื่อแก้ไขปัญหา การทำงานที่ไม่ผูกมัดและใช้สำหรับไคลเอนต์เครือข่ายทั้งหมด เมื่อ IP ของเซิร์ฟเวอร์ที่ไม่ได้ผูกไว้ใช้สำหรับ DNS ในเซิร์ฟเวอร์อีเมลที่มีเกตเวย์ของ ISP เดิม กระแสเมลขาเข้า
เมื่อใช้เกตเวย์ Starlink เมลจะหยุดไหล ไม่เห็นข้อผิดพลาดใดๆ ในบันทึก Postfix จดหมายเพิ่งหยุดไหล แม้ว่า Spamhaus ดูเหมือนจะพอใจที่จะใช้เซิร์ฟเวอร์ Unbound เมื่อใช้เกตเวย์แบบเดิม ทดสอบการตอบสนองของ Spamhaus ในกรณี. ผลลัพธ์น่าสนใจ:
% ขุด +short @[ที่อยู่ของเซิร์ฟเวอร์ Unbound] 2.0.0.127.zen.spamhaus.org
127.0.0.2
127.0.0.10
127.0.0.4
%
ถูกต้อง. อย่างไรก็ตาม ต่อไปนี้จะไม่คืนค่าใดกลับมา:
% ขุด +short @[ที่อยู่ของเซิร์ฟเวอร์ Unbound] 1.0.0.127.zen.spamhaus.org
%
จากเอกสารประกอบของ Spamhaus มันควรจะกลับมา:
ไม่พบโฮสต์ 1.0.0.127.zen.spamhaus.org: 3(NXDOMAIN)
เอกสารประกอบของ Spamhaus ยังระบุว่า "การสืบค้นสำหรับอ็อบเจ็กต์ "not_listed" จะต้องส่งคืน NXDOMAIN เสมอเพื่อให้การกรองอีเมลทำงานได้อย่างถูกต้อง" และ "การตรวจสอบผลลัพธ์ที่ถูกต้องสำหรับทั้งข้อความค้นหาที่ 'อยู่ในรายการ' และ 'ไม่ได้อยู่ในรายการ' เป็นสิ่งสำคัญ"
สิ่งที่น่าสนใจคือ เมื่อฉันใช้ DNS และเกตเวย์ของ ISP ดั้งเดิม ฉันยังได้รับ:
% ขุด +short @[ดั้งเดิม ISP DNS IP] 1.0.0.127.zen.spamhaus.org
%
อย่างไรก็ตาม อีเมลขาออกทำงานในการกำหนดค่า ISP ทั้งหมด เฉพาะจดหมายขาเข้าเท่านั้นที่มีปัญหา เรียกใช้เว็บเซิร์ฟเวอร์ที่อยู่เบื้องหลัง Starlink ซึ่งทำงานได้ดี IP สาธารณะของ Starlink เหมือนเดิมมาสองเดือนแล้ว
เกิดอะไรขึ้นที่นี่? อาจเป็นการกำหนดค่าเซิร์ฟเวอร์ Unbound หรือไม่ ฉันรู้ว่า Starlink คือ CGNAT แต่นั่นไม่ควรเป็นสาเหตุของปัญหานี้ เคล็ดลับการแก้ปัญหาใด ๆ ? อึ้งจริงๆ ขอขอบคุณสำหรับความช่วยเหลือใด ๆ
อัปเดต:
ฉันพบข้อความที่ถูกปฏิเสธหลายรายการที่มีลักษณะเช่นนี้หลังจากที่ฉันตัดทุกอย่างไปที่ Starlink:
451 4.3.5 <mta-d-130-24.infusionmail.com>: คำสั่ง Helo ถูกปฏิเสธ: ข้อผิดพลาดการกำหนดค่าเซิร์ฟเวอร์; [email protected] ถึง=<mike@[ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน]> proto=ESMTP helo=<mta-d-130-24.infusionmail.com> (ทั้งหมด: 1) 1 infusionmail.com ([email protected])
อัปเดต 2:
ตั้งค่าเซิร์ฟเวอร์ BIND9 ตามที่แนะนำด้านล่าง อีกครั้ง เมลไหลขณะใช้ BIND9 DNS และเกตเวย์ ISP เดิม แต่ไม่ใช่เมื่อใช้เกตเวย์ Starlink
ใช้เครื่องมือต่อไปนี้เพื่อทดสอบ https://mxtoolbox.com/diagnostic.aspx
ผ่านการทดสอบทั้งหมดเมื่อเซิร์ฟเวอร์อีเมลทำงานหลัง DSL รุ่นเก่า เมื่อทำงานเบื้องหลัง Starlink จะได้รับ:
19/3/2022 17:33:54 น. ความพยายามในการเชื่อมต่อ #1 - ไม่สามารถเชื่อมต่อได้หลังจากผ่านไป 15 วินาที [15.05 วินาที]
Lookup Server 15051ms
เหมือนกับว่าเซิร์ฟเวอร์อีเมลไม่ตอบสนองที่พอร์ต 25 จากด้านหลัง Starlink ฉันพยายามลบกฎสแปมทั้งหมดใน Postfix ยังไม่ตอบสนอง
เกือบจะรู้สึกเหมือนปัญหาไฟร์วอลล์ แต่ฉันมีพอร์ต 25, 587 และ 993 ที่ส่งต่อจากเราเตอร์ Starlink เช่นเดียวกับที่ฉันทำกับเราเตอร์ DSL รุ่นเก่า
จากภายนอกเครือข่ายของฉัน ฉันพิจารณาแล้วว่าพอร์ตต่อไปนี้ไม่ถูกบล็อก:
25:
% telnet [ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน] 25
220 [ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน] ESMTP Postfix
587:
% telnet [ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน] 587
220 [ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน] ESMTP Postfix
993:
% openssl s_client -connect [ชื่อเซิร์ฟเวอร์เมลสาธารณะของฉัน]:993 -crlf -quiet
ความลึก=1 O = Digital Signature Trust Co., CN = DST Root CA X3
ตรวจสอบข้อผิดพลาด:num=10:ใบรับรองหมดอายุ
notAfter=30 กันยายน 14:01:15 น. 2021 GMT
ตรวจสอบผลตอบแทน:0
ความลึก=1 O = Digital Signature Trust Co., CN = DST Root CA X3
ตรวจสอบข้อผิดพลาด:num=10:ใบรับรองหมดอายุ
notAfter=30 กันยายน 14:01:15 น. 2021 GMT
ตรวจสอบผลตอบแทน:0
ความลึก=3 O = Digital Signature Trust Co., CN = DST Root CA X3
ตรวจสอบข้อผิดพลาด:num=10:ใบรับรองหมดอายุ
notAfter=30 กันยายน 14:01:15 น. 2021 GMT
ตรวจสอบผลตอบแทน:0
* ตกลง [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) พร้อมแล้ว
สิ่งนี้ควรพิสูจน์ได้ว่า Starlink ไม่ได้ปิดกั้นพอร์ตใดๆ ของฉัน
ฉันคิดว่าสิ่งที่สำคัญที่สุดคือคำสั่ง HELO กำลังถูกปฏิเสธ ไม่แน่ใจว่าเหตุใดจึงถูกปฏิเสธเมื่อเซิร์ฟเวอร์ทำงานเบื้องหลัง Starlink และไม่ใช่ ISP เดิม อืม...
นี่อาจเป็นปัญหา DNS ย้อนกลับหรือไม่ Starlink มีบันทึก PTR บนที่อยู่ IP ที่พวกเขาให้ฉัน:
% โฮสต์ [Starlink IP สาธารณะ]
[Starlink IP สาธารณะ] ตัวชี้ชื่อโดเมน .in-addr.arpa customer.sttlwax1.pop.starlinkisp.net
% ขุด + short customer.sttlwax1.pop.starlinkisp.net
%
% ขุด +short mail.[โดเมนของฉัน].com
[Starlink IP สาธารณะ]
จากนั้นฉันตรวจสอบ DSL เดิมของฉัน:
% โฮสต์ [Legacy DSL Public IP]
[IP สาธารณะ DSL เดิม].in-addr.arpa ตัวชี้ชื่อโดเมน ไคลเอนต์-[IP สาธารณะ DSL เดิม].hostwindsdns.com
% ขุด + short client-[Legacy DSL Public IP].hostwindsdns.com
%
% ขุด +short mail.[โดเมนของฉัน].com
[IP สาธารณะ DSL ดั้งเดิม]
พวกเขาดูเหมือนจะทำงานคล้ายกันและมีปัญหาเดียวกัน
Starlink กล่าวว่าพวกเขากำลังบล็อกพอร์ต 25 และ CGNAT อาจทำให้เกิดปัญหาการกำหนดเส้นทาง ฉันแก้ปัญหาด้วยการสร้าง VPS แล้วสร้างช่องสัญญาณไปยังเมลเซิร์ฟเวอร์ของฉันที่อยู่เบื้องหลัง Starlink จากนั้นทราฟฟิกทั้งหมดจะถูกส่งต่อจาก VPS ผ่านทันเนลไปยังเมลเซิร์ฟเวอร์ การรับส่งข้อมูลขาออกทั้งหมดจากเซิร์ฟเวอร์อีเมลจะผ่านอุโมงค์ ทำงานเหมือนจับใจ
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
