Máy chủ iRedMail được định cấu hình bằng máy chủ DNS của ISP. Chạy vài năm mà không có vấn đề gì. Chuyển từ ISP hiện tại sang Starlink. Có vẻ như Starlink sử dụng DNS công cộng của Cloudflare.Hiện có cả hai ISP chạy song song cho đến khi quá trình chuyển đổi hoàn tất. Một lần nữa, máy chủ thư chạy tốt trên ISP cũ.
Khi tôi chuyển sang Starlink (bao gồm cả các thay đổi DNS công khai phù hợp), nhận được lỗi 12.255.255.254 từ Spamhaus cho biết họ sẽ không cho phép truy vấn từ các máy chủ DNS công cộng. Đủ công bằng. Thiết lập trình giải quyết Không liên kết cục bộ để khắc phục sự cố. Làm việc không giới hạn và được sử dụng cho tất cả các máy khách mạng. Khi IP máy chủ không liên kết được sử dụng cho DNS trong máy chủ thư có cổng của ISP kế thừa, thư đến sẽ được chuyển.
Khi sử dụng cổng Starlink, thư sẽ ngừng chảy. Không thấy bất kỳ lỗi nào trong nhật ký Postfix. Thư chỉ ngừng chảy. Mặc dù Spamhaus có vẻ hài lòng khi sử dụng máy chủ Không liên kết khi sử dụng cổng kế thừa, đã kiểm tra phản hồi của Spamhaus chỉ trong trường hợp. Kết quả thật thú vị:
% dig +short @[địa chỉ của máy chủ Không liên kết] 2.0.0.127.zen.spamhaus.org
127.0.0.2
127.0.0.10
127.0.0.4
%
Đúng rồi. Tuy nhiên, những điều sau đây không trả lại gì:
% dig +short @[địa chỉ của máy chủ Không liên kết] 1.0.0.127.zen.spamhaus.org
%
Từ tài liệu Spamhaus, nó sẽ trả về:
Không tìm thấy máy chủ 1.0.0.127.zen.spamhaus.org: 3(NXDOMAIN)
Tài liệu của Spamhaus cũng cho biết "Các truy vấn đối với các đối tượng" not_listed "phải luôn trả về NXDOMAIN để quá trình lọc thư hoạt động bình thường." và "Điều quan trọng là phải kiểm tra kết quả chính xác cho cả truy vấn 'được liệt kê' và 'không được liệt kê'."
Thật thú vị, khi tôi sử dụng DNS và cổng ISP kế thừa, tôi cũng nhận được:
% đào +rút ngắn @[IP DNS ISP kế thừa] 1.0.0.127.zen.spamhaus.org
%
Nhân tiện, thư gửi đi hoạt động trong mọi cấu hình ISP. Chỉ thư đến có vấn đề. Đồng thời chạy một máy chủ web phía sau Starlink đang hoạt động tốt. IP công cộng của Starlink đã giống nhau trong hai tháng cho đến nay.
Chính xác thì chuyện gì đang xảy ra ở đây vậy? Nó có thể là cấu hình máy chủ Unbound? Tôi biết Starlink là CGNAT nhưng điều đó không gây ra sự cố này. Bất kỳ lời khuyên khắc phục sự cố? Thực sự bối rối. Sẽ đánh giá cao bất kỳ sự giúp đỡ.
CẬP NHẬT:
Tôi đã tìm thấy trong các tin nhắn bị từ chối của mình nhiều mục giống như thế này sau khi tôi chuyển mọi thứ sang Starlink:
451 4.3.5 <mta-d-130-24.infusionmail.com>: Lệnh Helo bị từ chối: Lỗi cấu hình máy chủ; [email protected] to=<mike@[My public mail server name]> proto=ESMTP helo=<mta-d-130-24.infusionmail.com> (tổng cộng: 1)
1 infusionmail.com ([email protected])
CẬP NHẬT 2:
Thiết lập máy chủ BIND9 như đề xuất bên dưới. Một lần nữa, thư sẽ chảy khi sử dụng BIND9 DNS và cổng ISP kế thừa chứ không phải khi sử dụng cổng Starlink.
Đã sử dụng công cụ sau để kiểm tra https://mxtoolbox.com/diagnostic.aspx
Vượt qua tất cả các bài kiểm tra khi máy chủ email chạy phía sau DSL cũ. Khi chạy phía sau Starlink, nhận được:
19/3/2022 17:33:54 Lần thử kết nối #1 - Không thể kết nối sau 15 giây. [15,05 giây]
Máy chủ tra cứu 15051ms
Nó giống như máy chủ email không phản hồi trên cổng 25 từ phía sau Starlink. Tôi đã thử xóa tất cả các quy tắc spam trong Postfix. Vẫn không trả lời.
Gần như giống như sự cố tường lửa nhưng tôi có các cổng 25, 587 và 993 được chuyển tiếp từ bộ định tuyến Starlink giống như tôi làm đối với bộ định tuyến DSL cũ.
Từ bên ngoài mạng của mình, tôi đã xác định rằng các cổng sau không bị chặn:
25:
% telnet [Tên máy chủ thư công cộng của tôi] 25
220 [Tên máy chủ thư công khai của tôi] ESMTP Postfix
587:
% telnet [Tên máy chủ thư công cộng của tôi] 587
220 [Tên máy chủ thư công khai của tôi] ESMTP Postfix
993:
% openssl s_client -connect [Tên máy chủ mail công cộng của tôi]:993 -crlf -quiet
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
xác minh lỗi:num=10:chứng chỉ đã hết hạn
notafter=30 tháng 9 14:01:15 2021 GMT
xác minh trả lại: 0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
xác minh lỗi:num=10:chứng chỉ đã hết hạn
notafter=30 tháng 9 14:01:15 2021 GMT
xác minh trả lại: 0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
xác minh lỗi:num=10:chứng chỉ đã hết hạn
notafter=30 tháng 9 14:01:15 2021 GMT
xác minh trả lại: 0
* OK [KHẢ NĂNG IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) đã sẵn sàng.
Điều này chứng tỏ Starlink không chặn bất kỳ cổng nào của tôi.
Tôi nghĩ điều quan trọng nhất cho đến nay là lệnh HELO đang bị từ chối. Không chắc tại sao nó lại bị từ chối khi máy chủ chạy phía sau Starlink chứ không phải ISP cũ. Hừm...
Đây có phải là sự cố DNS ngược không? Starlink có bản ghi PTR trên địa chỉ IP mà họ cung cấp cho tôi:
% máy chủ [IP công khai của Starlink]
[IP công cộng Starlink].in-addr.arpa con trỏ tên miền customer.sttlwax1.pop.starlinkisp.net.
% đào +khách hàng ngắn.sttlwax1.pop.starlinkisp.net
%
% đào +thư ngắn.[tên miền của tôi].com
[IP công cộng Starlink]
Sau đó, tôi đã kiểm tra DSL kế thừa của mình:
% máy chủ [IP công cộng DSL kế thừa]
[IP công cộng DSL kế thừa].in-addr.arpa máy khách con trỏ tên miền-[IP công cộng DSL kế thừa].hostwindsdns.com.
% đào +ứng dụng khách ngắn-[IP công cộng DSL kế thừa].hostwindsdns.com
%
% đào +thư ngắn.[tên miền của tôi].com
[IP công cộng DSL kế thừa]
Họ dường như cư xử tương tự và có cùng một vấn đề.
