Làm cách nào tôi có thể sử dụng ký tự đại diện cho sendmail TLS_Rcpt?

sendmail cho phép hạn chế một nơi đối với các cuộc hội thoại TLS. Tôi muốn kiểm tra xem các tin nhắn được gửi đến example.com có ​​được gửi đến một máy chủ có chứng chỉ * .messagelabs.com không. Tôi muốn bảo vệ chống giả mạo DNS và MitM. Nếu messagelabs chỉ có một máy chủ thì sẽ dễ dàng:

TLS_Rcpt:example.com VERIFY:256+CN:mx.messagelabs.com

Tuy nhiên messagelabs có rất nhiều máy chủ và cụm máy chủ khác nhau với IP và certs duy nhất cho cùng một tên. Tất cả đều ổn, tôi chỉ muốn kiểm tra xem máy chủ mà tôi đang gửi thư có được chứng nhận thuộc về messagelabs không.

Tôi đã thử

TLS_Rcpt:example.com VERIFY:256+CN:messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:*.messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:.*.messagelabs.com

nhưng tôi gặp lỗi như

CN mail31.messagelabs.com does not match .*.messagelabs.com

Tôi có thể làm cái này như thế nào? Đây là một yêu cầu định kỳ cho chúng tôi (chủ yếu là cho các cấu hình như TLS_Rcpt: example.com XÁC MINH: 256 + CN: *. Example.com), vì vậy tôi đã sẵn sàng sửa đổi sendmail.cf, nhưng tôi không thể hiểu

STLS_req
R $| $+         $@ OK
R<CN> $* $| <$+>                $: <CN:$&{TLS_Name}> $1 $| <$2>
R<CN:$&{cn_subject}> $* $| <$+>         $@ $>"TLS_req" $1 $| <$2>
R<CN:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " CN " $&{cn_subject} " does not match " $1
R<CS:$&{cert_subject}> $* $| <$+>       $@ $>"TLS_req" $1 $| <$2>
R<CS:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Subject " $&{cert_subject} " does not match " $1
R<CI:$&{cert_issuer}> $* $| <$+>        $@ $>"TLS_req" $1 $| <$2>
R<CI:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Issuer " $&{cert_issuer} " does not match " $1
ROK                     $@ OK

Sendmail 8.14.7 (sớm nâng cấp lên 8.15.2).

Tạo cửa hàng sendmail.cf ${cn_subject}với phần máy chủ bị tước ${cn1_subject}.
Nó làm cho việc hoàn thành việc thực hiện gần như không đáng kể.

CẢNH BÁO: Hỏi ý kiến news:comp.mail.sendmailtrước khi triển khai nó trong môi trường không thử nghiệm. Nó có thể hoạt động nhưng sendmail giúp tránh "tác dụng phụ không mong muốn" RẤT NHIỀU hơn tôi sẵn sàng "đầu tư". Tôi "thử nghiệm khô" với sendmail-8.15.2.

truy cập vào:

TLS_Rcpt:example.com VERIFY:256+CN1:messagelabs.com

sendmail.mc sửa chữa để hỗ trợ mục nhập trên

CẢNH BÁO: nhớ về TAB (\ t) giữa RHS và LHS theo Rdòng.
Đó là thực hiện bẩn hơn thông qua sendmail.mc chỉ .

define(`_LOCAL_TLS_RCPT_')dnl
LOCAL_RULESETS
SLocal_tls_rcpt
R$*     $: $&{cn_subject}
R$-.$+  $@ $(macro {cn1_subject}  $@ $2 $)
R$*     $@ $(macro {cn1_subject}  $@ $)    

# Ruleset continued
STLS_req
R<CN1:$&{cn1_subject}> $* $| <$+>               $@ $>"TLS_req" $1 $| <$2>
R<CN1:$+> $* $| <$-:$+> $#error $@ $4 $: $3 " CN-1 " $&{cn_subject} " does not match " $1
ROK                     $@ OK
divert(0)dnl

Giải trình:

1. Tạo Local_tls_rcptcửa hàng ${cn_subject}theo quy tắc với phần "trước dấu chấm đầu tiên" bị tước${cn1_subject}
2. Thêm kiểm tra ${cn1_subject}kích hoạt bởi tiền tố CN1 trong "phần bổ sung" của bộ TLS_reqquy tắc

Kịch bản mẫu để kiểm tra nó

#!/bin/sh
# -C sendmail-test.cf -- use non standard cf file
# -d60.5 -- trace (access) map lookus
# -d21.12 -- trace R lines rewriting 
sendmail -C sendmail-test.cf -bt -d60.5 <<END
.D{verify}OK
.D{cn_subject}mail31.messagelabs.com
.D{server_name}mail31.messagelabs.com
tls_rcpt user1@example.com
END

Đây không chính xác là một câu trả lời cho câu hỏi như được đặt ra, nhưng có vẻ như tôi đang làm mọi thứ một cách khó khăn.

Cấu hình Sendmail được viết theo cách ưu tiên dễ dàng và hiệu quả cho phần mềm phân tích cấu hình đó, không phải để con người dễ dàng cấu hình và bảo trì. Đơn giản là không có lý do chính đáng để làm điều đó trong những thập kỷ gần đây.

Sendmail là một di tích phức tạp khủng khiếp 15 năm trước. Một số bản phân phối linux vẫn cung cấp nó theo mặc định và điều đó tốt nếu cấu hình mặc định hoạt động cho bạn, nhưng ngay khi bạn thấy mình làm bất cứ việc gì mất hơn vài phút, tốt nhất bạn nên ném sendmail ra và cài đặt MTA hiện đại .

Khoảng 15 năm trước, qmail có thể vẫn là một sự thay thế hợp lý, nhưng trong gần như lâu nay tôi đã coi hậu tố là một lựa chọn tốt hơn. Các tài liệu từ trang postfix.org là tốt khi bạn tìm thấy bit bạn cần. Trong trường hợp của bạn, bạn sẽ muốn http://www.postfix.org/TLS_README.html cho vấn đề này.

Tôi nhận ra rằng bạn hoàn toàn có thể đã dành thời gian để giải quyết một vài vấn đề trong sendmail, nhưng thay vì ném thêm thời gian xuống lỗ hổng đó, hãy chuyển sang cơ hội sớm nhất. Nếu bạn nhìn lại, bạn sẽ co rúm lại.