Bagaimana saya bisa menggunakan wildcard untuk sendmail TLS_Rcpt?

Sendmail memungkinkan pembatasan satu tempat pada percakapan TLS. Saya ingin memeriksa apakah pesan yang dikirim ke example.com dikirim ke server yang memiliki sertifikat * .messagelabs.com. Saya ingin melindungi dari spoofing DNS dan MitM. Jika messagelab hanya memiliki satu server yang mudah:

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

Namun messagelab memiliki banyak server dan kelompok server yang berbeda dengan IP dan sertifikat unik untuk nama yang sama. Semua itu baik-baik saja, saya hanya ingin memeriksa server yang saya berikan surat untuk disertifikasi milik messagelab.

saya telah mencoba

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

tapi saya mendapatkan kesalahan seperti

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

Bagaimana saya bisa melakukan ini? Ini adalah permintaan berulang untuk kami (kebanyakan untuk konfigurasi seperti TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), jadi saya akan siap untuk memodifikasi sendmail.cf, tetapi saya tidak dapat memahami

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 (segera ditingkatkan menjadi 8.15.2).

Membuat toko sendmail.cf ${cn_subject}dengan bagian host dilucuti di ${cn1_subject}.
Itu membuat penyelesaian implementasi hampir sepele.

PERINGATAN: Minta pendapat news:comp.mail.sendmailsebelum menyebarkannya di lingkungan yang tidak diuji. MUNGKIN bekerja tetapi sendmail membuat menghindari "efek samping tak terduga" BANYAK LEBIH melelahkan daripada saya siap untuk "berinvestasi". Saya "kering mengujinya" dengan sendmail-8.15.2.

entri akses:

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

sendmail.mc fix untuk mendukung entri di atas

PERINGATAN: ingat tentang TAB (\ t) antara RHS dan LHS Rsejalan.
Ini lebih kotor melalui implementasi sendmail.mc saja .

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

Penjelasan:

1. Buat Local_tls_rcpttoko aturan-set ${cn_subject}dengan bagian "sebelum titik pertama" dilucuti${cn1_subject}
2. Tambahkan cek yang ${cn1_subject}dipicu oleh awalan CN1 di "bagian tambahan" dari TLS_reqaturan-set

Contoh skrip untuk mengujinya

#!/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

Ini bukan jawaban yang tepat untuk pertanyaan yang diajukan, tetapi sepertinya saya melakukan hal-hal yang sulit.

Konfigurasi Sendmail ditulis dengan cara yang mengutamakan kemudahan dan efisiensi untuk perangkat lunak yang menguraikan konfigurasi itu, bukan untuk konfigurasi dan pemeliharaan yang mudah oleh manusia. Tidak ada alasan bagus untuk melakukan itu dalam beberapa dekade terakhir.

Sendmail adalah peninggalan misterius yang mengerikan 15 tahun lalu. Beberapa distribusi linux masih menyediakannya secara default, dan itu tidak masalah jika konfigurasi default berfungsi untuk Anda, tetapi segera setelah Anda menemukan diri Anda melakukan sesuatu yang membutuhkan waktu lebih dari beberapa menit, Anda lebih baik membuang sendmail dan menginstal MTA modern .

Sekitar 15 tahun yang lalu, qmail mungkin masih merupakan pengganti yang masuk akal, tetapi untuk hampir selama itu saya menganggap postfix pilihan yang lebih baik. Dokumentasi dari situs postfix.org baik setelah Anda menemukan bit yang Anda butuhkan. Dalam kasus Anda, Anda ingin http://www.postfix.org/TLS_README.html untuk masalah ini.

Saya sadar Anda kemungkinan besar telah menghabiskan beberapa waktu untuk menyelesaikan beberapa masalah di sendmail, tetapi alih-alih membuang lebih banyak waktu ke lubang itu, beralihlah pada peluang paling awal. Jika Anda melihat ke belakang, Anda akan merasa ngeri.