Instrumentele oferite de OpenDKIM nu oferă o pereche de chei utilizabilă pentru DKIM

eu folosesc opendkim-genkey -b 2048 -t -s implicit -d mydomain.com, rezultând fișiere implicit.private și default.txt. Da, implicit.private începe (corect, SFAIK) cu -----BEGIN RSA PRIVATE KEY----- și default.txt nu depășește 256 de caractere pe segment (nu încalcă cerințele de codare DNS.) De asemenea, opendkim-testkey nu returnează nimic (fără -v) si cu -v -v -v se spune Cheia nu este sigură (dar nu folosesc DNSSEC) și, de asemenea Tasta OK, deci cheia este cel puțin corectă în funcție de opendkim per se.

Primesc erorile

26 septembrie 22:41:49 mydomain opendkim[1793958]: 18R2fhko1843765: SSL error:0909006C:PEM routines:get_name:no start line
26 septembrie 22:41:49 mydomain opendkim[1793958]: 18R2fhko1843765: dkim_eom(): resursa indisponibilă: PEM_read_bio_PrivateKey() a eșuat
Sep 26 22:41:49 mydomain sm-mta[1843765]: 18R2fhko1843765: milter=opendkim, reject=451 4.7.0 resursa indisponibilă
Sep 26 22:41:49 mydomain sm-mta[1843765]: 18R2fhko1843765: Milter: data, reject=451 4.7.0 resursă indisponibilă
Sep 26 22:41:49 mydomain sm-mta[1843765]: 18R2fhko1843765: to=<[email protected]>, delay=00:00:00, pri=30408, stat=resource indisponible

Am văzut o mulțime de referințe de căutare pe web la ambele erori Eroare SSL:0909006C:PEM routines:get_name:nicio linie de pornire și dkim_eom(): resursă indisponibilă: PEM_read_bio_PrivateKey() a eșuat, dar nimic care să ajute. Când am văzut „cazul închis”, a fost din cauza erorilor de implementare ale utilizatorilor, cum ar fi permisiuni greșite, specificații de locație a fișierelor greșite sau formatare proastă a tastei/txt, iar cei care trimiteau au spus de obicei „scuze pentru zgomot”, dar niciunul nu este cazul. Eu fac EXACT așa cum precizează documentația, cu eșecurile pe care le-am logat mai sus.

Pentru cei care ar dori să știe, folosesc Ubuntu 20.04 LTS și sendmail 8.15.2. Reclamația provine din rutinele opendkim milter vs. SSL, deci contextul extern nu ar trebui să conteze.

Aș întreba pe lista de corespondență opendkim, dar „lists.opendkim.org” este în jos.Trebuie să fac OpenDKIM să ruleze, să mă supun Master Goo (pe lângă faptul că este cea mai bună practică, ei bine.) Voi fi recunoscător dacă altcineva s-a confruntat cu asta, în special, și poate da un răspuns de lucru.

Ieșirea pe care o folosesc este exact ceea ce iese „opendkim-genkey”, nu există erori de formatare așa cum este descris în altă parte și opendkim-testkey este mulțumit, așa că vă rog să vă scuzați că nu am inclus acele date reale.

p.s.: opendkim instalat cu apt install opendkim:

opendkim -p /var/run/opendkim.sock -V opendkim:
OpenDKIM Filter v2.11.0 Compilat cu OpenSSL 1.1.1f 31 martie 2020  
SMFI_VERSION 0x1000001  
libmilter versiunea 1.0.1  
Algoritmi de semnare acceptați: rsa-sha1 rsa-sha256 ed25519-sha256  
Algoritmi de canonizare acceptați: simpli relaxați  
Opțiuni de cod activ: QUERY_CACHE USE_DB USE_LDAP USE_LUA USE_ODBX USE_UNBOUND _FFR_ATPS _FFR_RBL _FFR_REPLACE_RULES _FFR_SENDER_MACRO _FFR_STATS _FFR_VBR  
libopendkim 2.11.0: atps query_cache

Nici cheile generate de instrumentul opendkim, nici cheile generate manual (conform documentației OpenDKIM) nu trec de erori.

Acesta este un răspuns, sperăm: Am încercat să compilez OpenDKIM din sursă, dar asta nu a ajuns nicăieri: eroarea PEM a dispărut, dar filtrul a eșuat în alte moduri fatal pentru utilizarea sa. Așa că am primit „dk-filter”, care cea mai recentă versiune este învechită, deoarece folosește doar SHA1, numește „relaxed” „nofws”, gestionează doar o singură canonizare (relaxată sau simplă, față de două ca în „relaxed/simple” și folosește „dns”, dar nu „dns/txt”. L-am spart conform RFC8301 (pe care nimeni nu îl citează) și poate să funcționeze; se ocupă de corespondența primită și, în cele din urmă, mi-a dat o semnătură DKIM:

DomainKey-Signature: a=rsa-sha256; s=10191; d=mydarneddomain.com; c=relaxat/simplu; q=dns/txt;
    h=to:from:subject:message-id:data:user-agent:mime-version:
    tip-conținut:codare-transfer-conținut:limba-conținut:x-uctc:x-sdmilter-detectat;
    b=kldIuC9j/EIB7ouhRrhxmZBkC7xAazd8RiWHUA/1R0FZK265yeFgf+TPqbfTjErps
    CrkoCn1I2gdMpq8k9ZrdF8RsQk8FeZBVLGE9iY3D2Rkj/ozjdOyHgNaNDCHKfdnpiNp
    4uV/w7ZG8fAEdDwfSoQ3IBvCmxoszV2bzGvzKz+DuT17G8ES3aJcKsdm9+MEHz0VxrB
    EHdOd9ij/EBZFHTMwcLqBWVi+kTvUvzjFK1ssPEO9CHXIWqjBE1gKtfiIDkeJ7kx0w4
    ft8TiPvMb5Z1WyOPWoI6a+tNNz2at1URSYvxMcDi77m93GH5Tcda1fNN/shx9ze9Igw
    DwPHc6mFA==

Deoarece am spart chestia în conformitate și funcționalitate (încă nu a fost confirmată în practică, dar în curând) și din moment ce poate funcționa pentru toți cei pentru care OpenDKIM nu funcționează, merită împărtășit, pe github, să zicem. Încă nu știu cum să fac asta; daca cineva ar dori sa ma ajute cu asta, anunta-ma.

Lucrul este cu adevărat brut, nu există nici măcar un fișier „dk-filter.conf”, mai degrabă trebuie să folosiți linia de comandă; eu folosesc

dk-filter -p inet:8892@localhost -b sv -c relaxed -d mydarneddomain.com -D -h -H -l -S 10191 -s /etc/dkimkeys/10191.private

deși -d se poate referi la un fișier care listează gazde de semnat (nu este încă testat.) Nici nu este un „serviciu”. Dacă cineva poate cita o carte care explică cum să o închei, de ex. Ubuntu ca serviciu, anunțați-mă.

p.s.: RFC8301 mandate valori specifice şi interzice utilizarea SHA1. Site-urile care verifică cheile DKIM pot avea un comentariu învechit care spune că fie sha1, fie sha256 pot fi utilizate. Nimic mai puțin decât sha256 poate fi folosit acum, iar aceste comentarii sunt depășite.

Am verificat că cheia este corectă (privată<==>publică) și accesibilă prin două mijloace diferite. Nu folosesc KeyTable. /etc/opendkim.conf meu (domeniul real deghizat) este:

Syslog da
UMask 007
Domeniul mydomain.sometld
KeyFile /etc/dkimkeys/10191.private
Selector 10191
Modul v
Socket inet:8892@localhost
#@Socket local:/run/opendkim/opendkim.sock
PidFile /run/opendkim/opendkim.pid
OversignHeaders De la
TrustAnchorFile /usr/share/dns/root.key
ID utilizator opendkim

Țin filtrul în modul „v”, deoarece „sv” eșuează așa cum este indicat și trebuie doar să repornesc milter-ul cu „sv” pentru a testa. Folosind opendkim-2.10.3 obținut de la opendkim.org: Am spart libopendkim/dkim.c, folosit de milter, pentru a-mi arăta primele 96 de caractere (*) ale cheii încercate, atunci când eșuează (în primele ore ale dimineții, când nimănui nu-i pasă.) (*) 96 = linie antet + primul „rând” de date cheie.

1135 if (strncmp((char *) dkim->dkim_key, "-----", 5) == 0)
1136 { /* PEM */
1137 rsa->rsa_pkey = PEM_read_bio_PrivateKey(rsa->rsa_keydata, NULL,
1138 NULL, NULL);
1139 
1140 dacă (rsa->rsa_pkey == NULL)
1141 {
1142 dkim_load_ssl_errors(dkim, 0);
1143 dkim_error(dkim, „PEM_read_bio_PrivateKey() a eșuat”);
1144 // ecsd: vrem să vedem ce a eșuat:
1145 char dbuf[128]; sprintf(dbuf,"dkim_key %96.96s\n",dkim->dkim_key);
1146 dkim_error(dkim, dbuf);
1147 // termina depanarea suplimentară
1148 BIO_free(rsa->rsa_keydata);
1149 rsa->rsa_keydata = NULL;
1150 returnează DKIM_STAT_NORESOURCE;
1151 }
1152 }

Ar trebui să depanez PEM_read_bio_PrivateKey (pentru a afla despre ce e vorba), dar am prea multă teamă la recompilarea acelui subsistem, în plus, plângerea este de antet prost, așa că trebuie doar să înțeleg ce se încearcă „în schimb”, deoarece conținutul cheii private este corect. Între timp, ce este cu opendkim.org că lista lor de corespondență nu funcționează, iar contactele listate pe opendkim.org și dkim.org nu funcționează? De parcă toată lumea s-a plictisit și s-a dus acasă. Nu este grozav pentru un protocol pe care vrei să-l adopti universal. Cel puțin codul încearcă, dar de ex.A trebuit să piratez „configurează” pentru a opri necesitatea unei biblioteci care să conțină SSL_library_init(), despre care documentul (lumea exterioară) spune că este eliminată (astfel, codul opendkim ar părea că nu este întreținut corespunzător.)

configura:
16846 fi
16847 rm conftest.$ac_ext
16848 LIBS=$ac_func_search_save_LIBS
16849 fi
16850 #ecsd
16851 $as_echo "pentru libssl, LIBS:$LIBS"
16852 { $as_echo "$as_me:${as_lineno-$LINENO}: rezultat: $ac_cv_search_SSL_library_init" >&5
16853 $as_echo "$ac_cv_search_SSL_library_init" >&6; }
16854 ac_res=$ac_cv_search_SSL_library_init
16855 #ecsd:
16856 #if test "$ac_res" != nu; atunci :
16857 # test "$ac_res" = "nu este necesar" || LIBS="$ac_res $LIBS"
16858 #altfel
16859 # as_fn_error $? „libssl nu a fost găsit” „$LINENO” 5
16860 #fi
16861 
16862 
16863 
16864 fi