Jak mogę używać symboli wieloznacznych dla sendmaila TLS_Rcpt?

sendmail pozwala na jedno miejsce na ograniczenia w rozmowach TLS. Chcę sprawdzić, czy wiadomości wysyłane do example.com są wysyłane na serwer, który ma certyfikat * .messagelabs.com. Chcę chronić przed fałszowaniem DNS i MitM. Jeśli messagelabs miałby tylko jeden serwer, byłoby to łatwe:

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

Jednak messagelabs ma wiele serwerów i klastrów różnych serwerów z unikalnymi adresami IP i certyfikatami dla tej samej nazwy. Wszystko w porządku, chcę tylko sprawdzić, czy serwer, na który wysyłam pocztę, jest certyfikowany jako należący do messagelabs.

próbowałem

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

ale dostaję błędy jak

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

W jaki sposób mogę to zrobić? To jest dla nas powtarzające się żądanie (głównie dla konfiguracji takich jak TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), więc byłbym gotowy zmodyfikować sendmail.cf, ale nie mam sensu

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 (wkrótce aktualizacja do wersji 8.15.2)

Ustaw sklep sendmail.cf ${cn_subject}z rozebraną częścią hosta ${cn1_subject}.
To sprawia, że ​​zakończenie implementacji jest prawie banalne.

OSTRZEŻENIE: Zapytaj o opinie news:comp.mail.sendmailprzed wdrożeniem go w środowisku nie testowym. MOŻE działać, ale sendmail sprawia, że ​​unikanie „nieoczekiwanych efektów ubocznych” DUŻO żmudności, niż jestem gotów „zainwestować”. „Testowałem na sucho” za pomocą sendmaila 8.15.2.

dostęp do wpisu:

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

sendmail.mc poprawka do obsługi powyższego wpisu

OSTRZEŻENIE: pamiętaj o TAB (\ t) między RHS i LHS w Rliniach.
Jest to bardziej brudna implementacja sendmail.mc tylko przez .

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

Wyjaśnienie:

1. Utwórz Local_tls_rcptsklep ${cn_subject}z ustalonymi regułami z rozebraną częścią „przed pierwszą kropką”${cn1_subject}
2. Dodaj kontrole ${cn1_subject}wyzwalane prefiksem CN1 w „dodatkowej części” zestawu TLS_reqreguł

Przykładowy skrypt do przetestowania

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

To nie jest dokładnie odpowiedź na postawione pytanie, ale wydaje mi się, że robisz wszystko na poważnie.

Konfiguracja Sendmail została napisana w taki sposób, że priorytetem jest łatwość i wydajność oprogramowania analizującego tę konfigurację, a nie łatwość konfiguracji i konserwacji przez ludzi. W ostatnich dziesięcioleciach po prostu nie było dobrego powodu, aby to zrobić.

Sendmail był okropnie tajemną reliktem 15 lat temu. Niektóre dystrybucje linuksa nadal domyślnie to zapewniają, i to jest w porządku, jeśli domyślna konfiguracja działa dla Ciebie, ale gdy tylko znajdziesz coś, co zajmuje więcej niż kilka minut, najlepiej wyrzucić sendmaila i zainstalować nowoczesny MTA .

Jakieś 15 lat temu qmail mógł nadal być rozsądnym zamiennikiem, ale przez prawie tak długi czas uważałem postfiks za lepszy wybór. Dokumentacja ze strony postfix.org jest dobra, gdy znajdziesz potrzebny bit. W twoim przypadku będziesz potrzebować http://www.postfix.org/TLS_README.html dla tego problemu.

Zdaję sobie sprawę, że najprawdopodobniej spędziłeś już trochę czasu na rozwiązywaniu kilku problemów z sendmailem, ale zamiast tracić więcej czasu w tej dziurze, zmieniaj przy najbliższej okazji. Jeśli kiedykolwiek spojrzysz za siebie, skulisz się.