Synology-Forum.nl
Packages => Officiële Packages => Mail Server => Topic gestart door: Heeren01 op 03 juni 2018, 11:41:13
-
Weet iemand of er in mail station problemen zijn met DKIM?
Ineens worden mails van afzenders geweigerd waar ik eerder wel mail van ontving.
Bij 1 van de mails ontving de zender onderstaande:
Onderwerp: Mail delivery failed: returning message to sender
Datum: 2018-06-02 15:55
Afzender: Mail Delivery System <Mailer-Daemon@filter01.totaalholding.nl>
Ontvanger: xxx@xxx.nl
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
mail@yyy.nl
host yyy.nl [Ipv6 adres]
SMTP error from remote mail server after end of data:
550 5.7.0 bad DKIM signature data
Reporting-MTA: dns; filter01.totaalholding.nl
Action: failed
Final-Recipient: rfc822;mail@yyy.nl
Status: 5.0.0
Remote-MTA: dns; yyy.nl
Diagnostic-Code: smtp; 550 5.7.0 bad DKIM signature data
-
Mail Station doet geen DKIM omdat het een mail cliënt is. DKIM wordt principieel door de SMTP server toegevoegd. In dit geval door Mail Server.
(dus nu verplaatst)
Ik denk eerder dat er gebeurt wat er staat: De data is niet ok. Ik heb b.v. een klant met een provider die foute DKIM gebruikt. In dat geval een sleutellengte van 256 byte, terwijl de default setting van OpenDKIM is om sleutels kleiner dan 1000 byte te bouncen. Ten behoeve van hem heb ik de setting ook lager gezet. (Hoewel elke Mail Server update dit weer ongedaan maakt).
Ik heb ook een klant waarvan de mailtjes wel binnenkomen met de melding:
"Authentication-Results: dkim=fail reason="key not found in DNS" (0-bit key) "
Als ik dan kijk, gebruiken zij een key met de naam "default", maar er staat geen publieke sleutel in dat keyveld.
Als ik in de mailheaders kijk, zie ik vaak dat klanten hun mail niet goed voor elkaar hebben. (Vaker gaat het om fout geconfigureerde SPF records)
In de OpenDKIM settings kun je ook instellen om een kopie van, via DKIM, bouncende mailtjes naar de mailbeheerder te sturen, zodat hij dit ook kan beoordelen. (Moet alles via een SSH inlog aangepast worden)
Kijk eerst eens in: "/volume1/@maillog/maillog" (En filteren in je logreader op "opendkim" zodat je niet teveel regels ziet)
-
Dank je, dit heeft me al wat verder geholpen. Ik kan wel met SSH overweg, maar hoe stel ik in dat die bouncete mail doorgestuurd wordt naar de systeembeheerder? En hoe stel ik die kortere lengte in?
-
In de configuratie files.
/volume1/@appstore/MailServer/etc/opendkim.conf
En ook in de bijbehorende template file.
/volume1/@appstore/MailServer/etc/template/opendkim.template
NB weet wat je veranderd in en template, want anders verpest je de installatie. (Maar voor de zekerheid een kopie van een originele template)
-
Ik heb exact hetzelfde probleem als Heeren01!
Een leraar van de school van mijn kinderen geeft aan dat hij een deze melding krijgt als hij mij een mailtje stuurt. Zijn collega heeft dit probleem echter niet als hij mij een mailbericht stuurt. Hoe kan dat?
Ben je al wat verder gekomen met het aanpassen van configuratie files? Heeft dat resultaat bij jou?
-
Bij mij treedt het probleem ook op bij 2 scholen. Die gebruiken volgens mij beide office 365 en mailen via Outlook.com. Ik heb nog geen tijd gehad om de config aan te passen (misschien lukt dat vandaag), maar ik heb voorlopig de e-mail adressen van die scholen maar even op de whitelist gezet. Ik weet alleen niet of dat veel uitmaakt. 1 mailadres kwam nu wel door, maar een andere nog steeds niet.
-
Toevallig Het Hooghuis?
-
Nee, 2 andere.
Het lijkt erop dat ze Dkim trouwens wel ingesteld hebben (test via internet.nl), maar waarschijnlijk niet goed, want dat is alleen te testen als ze een mail sturen. (Overigens hebben ze het bij hun internet site minder goed geregeld, maar dat is een ander verhaal).
-
Je kunt naar het volgende deel uit de config kijken:
## On-...
##
## Specifies what to do when certain error conditions are encountered.
##
## See opendkim.conf(5) for more information.
# On-Default
On-BadSignature reject
# On-DNSError
# On-InternalError
# On-NoSignature
# On-Security
# On-SignatureError
Nu staat hij op reject bij een foute handtekening. Als je er tijdelijk een # voor zet, zal hij ook foute mailjes doorlaten. Je kunt dan alleen in de header zien dat hij fout is.
Of je past het volgende veld aan:
## RedirectFailuresTo address
## default (none)
##
## Redirects signed messages to the specified address if none of the
## signatures present failed to verify.
# RedirectFailuresTo postmaster@example.com
De mail wordt dan wel regulier geblokkeerd maar een kopie gaat naar een specifiek adres.
Voor een uitgebeide handleiding van de config zie: OpenDKIM.conf (http://opendkim.org/opendkim.conf.5.html)
-
Dank je, zo kom ik wel een stuk verder denk ik.
(blijft dit staan als je het aanpast of wordt de config gereset bij een updat van mailstation?)
-
Ik pas ze altijd op beide plekken aan. Je kunt ook alleen de template aanpassen en dan Mailserver stoppen en starten.
Bij de meeste updates blijft de verandering staan. Maar bij sommige updates wordt ook de config file geupdate. Ik was mijn aanpassingen tot nu toe maar 1x kwijt.
-
Ik log in als su via Putty, kopieer de .conf naar een map waar ik er met notepad bij kom, sla op en kopieer dan de .conf weer terug. Als ik de DiskStation dan opnieuw opstart en de .conf bekijk staan alle waarden weer zoals ze oorspronkelijk stonden. Wat doe ik fout?
-
Gokje: /volume1/@appstore/MailServer/etc/template/opendkim.template ook aanpassen (advies Briolet), misschien dat er vandaar uit de .conf weer aangepast word ?
-
Ah, ok, tnx. Was niet zo slim van me... :oops:
-
Ik log in als su via Putty, kopieer de .conf naar een map waar ik er met notepad bij kom, sla op en kopieer dan de .conf weer terug.…
Een beetje omslachtig, al dat heen en weer gecopieer. :)
Zelf maak ik een hard-link van de config bestanden naar een share. Vervolgens edit ik de file dan op de share. De link naar het origineel blijft bestaan totdat het origineel een keer bij een update vervangen wordt. Tot dan heb je dus helemaal geen putty nodig voor je aanpassingen.
Hard links kun je alleen maken bij files die al op volume1 staan, maar dat is bij de diverse config bestanden van mailserver het geval.
ln /volume1/@maillog/maillog /volume1/Logs/Mail
ln /volume1/@appstore/MailServer/etc/opendkim.conf /volume1/Logs/Mail
ln /volume1/@appstore/MailServer/etc/template/opendkim.template /volume1/Logs/Mail/templates
ln /volume1/@appstore/MailServer/etc/template/opendmarc.template /volume1/Logs/Mail/templates
ln /volume1/@appstore/MailServer/etc/template/dovecot.template /volume1/Logs/Mail/templates
ln /volume1/@appstore/MailServer/etc/template/spamassassin.template /volume1/Logs/Mail/templates
ln /volume1/@appstore/MailServer/etc/template/master.template /volume1/Logs/Mail/templates
ln /volume1/@appstore/MailServer/etc/template/main.template /volume1/Logs/Mail/templates
Waarbij "/Logs/Mail" naar een folder op mijn share met naam "Logs" verwijst.
-
Ik denk altijd dat het maken van een link meer tijd kost dan even snel kopieeren, maar was inderdaad veel handiger geweest.
Het is gelukt, nu wachten op een foute Dkim
-
De eerste mail met slechte DKIM is binnen:
dkim=fail reason="signature verification failed" (1024-bit key)
Betekent dit dat ze een te korte key gebruiken?
Helemaal binnen is hij overigens niet, want hij is wel bij de systeembeheerder bezorgd (ik) maar niet bij de geadresseerde.
Ik dacht nu toch maar te hardlinken, maar dit lukt bij mij niet. Ik krijg melding:
ln: failed to create hard link ‘/volume1/Logs/Mail/maillog’ => ‘/volume1/@maillog/maillog’: Invalid cross-device link
-
Een 1024-bit key is de ondergrens, maar gewoon goed qua lengte.
Waarschijnlijk publiceren ze een verkeerde key via hun dns record.*
Om hem bij de geadresseerde binnen te laten komen moet je ergens een instelling aanpassen om fouten geheel te negeren. Maar dat is eigenlijk slecht. Beter is om de afzender er op te wijzen dat ze iets fout doen.
En wat die hard link betreft: De doel-share moet natuurlijk wel bestaan.
* Of ze een key publiceren is wel te achterhalen. In de header van de mail staat bij dkim een selector "d=". Die selector kun je weer opvragen via een 'host' command. (Alleen beschikbaar op unix en niet op windows). Maar dat vraagt eerst een weekend studie van de dkim manuals.
-
Kan je bij RedirectFailuresTo ook meer dan 1 adres opgeven? Zo ja, gescheiden door komma’s?
-
De afzender wijzen op het feit dat ze iets fout doen lijkt onbegonnen werk. Het probleem treedt bij mij op bij diverse onderwijsinstellingen (nu weer 1). Die gebruiken kennelijk veelal Office 365 en dan weten ze waarschijnlijk niet meer hoe (of dat ze überhaupt) nog wat in moeten stellen.
-
De afzenders hebben het idd niet altijd in eigen hand. Ik heb meerdere contacten die hun mail via skynet.be laten lopen. Die publiceren een te korte, onveilige, sleutel. (Het allerergste bij skynet.be is dat ze deze onveilige sleutel publiceren onder de naam "s=securemail" :lol: . Ik heb de afzender hier meermaals op gewezen. Ook heb ik zelf skynet hierop aangesproken via hun website, maar zelfs op dit soort veiligheids issues reageren ze niet eens. Dus geen provider die ik zou aanraden.)
G-Mail geeft alleen een waarschuwing erover, maar MailServer weigert deze skynet mail gewoon. Ik moet er na elke Mailserverupdate aan denken dat ik de config file weer aanpas om ook onveilige sleutels te accepteren. Vorige week was ik al mijn instellingen weer kwijt na de update.
RedirectFailuresTo kent volgens mij maar één adres. Anders had het er wel bijgestaan.
-
In de configuratie files.
/volume1/@appstore/MailServer/etc/opendkim.conf
En ook in de bijbehorende template file.
/volume1/@appstore/MailServer/etc/template/opendkim.template
NB weet wat je veranderd in en template, want anders verpest je de installatie. (Maar voor de zekerheid een kopie van een originele template)
Als aanvulling. Als je "/volume1/@appstore/MailServer/etc/opendkim.conf" aanpast gebeurd er niets totdat je opendkim opnieuw start met:
sudo /var/packages/MailServer/target/scripts/opendkim.sh restart
Bij het opnieuw starten van MailServer zelf, wordt de config file opnieuw aangemaakt vanuit de template file, aangevuld met de bewaarde instellingen voor MailServer. Je kunt dus ook alleen de template aanpassen en dan MailServer stoppen en weer starten.
-
Hier ook een gebruiker van mailstation (en van Office365). Binnen office365 een geldige 1024bit DKIM signature (mails naar bijvoorbeeld Gmail geven aan dat DKIM geldig is), maar een mailtje naar mailstation geeft:
dkim=fail reason="signature verification failed" (1024-bit key) header.d=[i][mijndomein.eu][/i] header.i=@[i][mijndomein.eu][/i] header.b=YojACaJP
Diverse testsites geven aan dat de gebruikte selector (bij O365 is dat standaard selector1 of selector2) geldig is en beide selectors zijn ook geldig en de publieke sleutels in DNS opgenomen uiteraard.
Als ik vanuit mijn gmail een mail stuur dan is dit de uitkomst:
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rurqsDuo
Dus aan de lokale instelling lijkt het ook niet te liggen dat de Office365 failed geeft. PS, dit gaat voor alle Office365 dkim ondertekende mails op dezelfde manier fout (ten minste zover ik tot nu toe heb kunnen terugvinden).
PS, de crosslink foutmelding bij het maken van een hardlink krijg ik ook. Als ik in plaats van een normale hardlink een symlink maak dan lukt het wel. Lijkt toch op één of andere manier niet hetzelfde volume terwijl het beide toch écht volume 1 is en de share ook bestaat.....
Vooralsnog edit ik dus in de shell middels vi, omslachtig weliswaar maar het werkt wel.
-
dus in de shell middels vi, omslachtig weliswaar maar het werkt wel.
Installeer nano vanuit het Package Center. (3th-party Package)
Een stuk vriendelijker dan vi en als je lange files hebt, kun je simpel naar een specifieke regel springen. En alle belangrijke commando's staan steeds onderaan in beeld, zodat je niets hoeft te onthouden.
-
Eigenlijk weet ik niet wat Office365 er mee te maken heeft. In principe moet dit ciënt onafhankelijk zijn. De cliënt stuurt de mail naar de smtp server op de de nas. Dan pas gaat de nas een dkim sleutel toevoegen en de mail verzenden.
dit gaat voor alle Office365 dkim ondertekende mails op dezelfde manier fout
Office behoort dus geen mails te ondertekenen. Als dat in dat pakket zit, moet je dat uitschakelen en aan de nas overlaten.
-
Ik weet het ook niet helaas. Office365 voegt uiteraard zelf een DKIM handtekening toe. Deze wordt zoals aangegeven door Gmail wel correct gevalideerd maar door Mail Server niet.
Misschien dat het komt dat in O365 de publieke sleutel niet in een TXT record in de eigen DNS omgeving staan, maar via een CNAME worden doorgestuurd naar een O365-klantspecifieke domeinnaam en daar staat wel een TXT record. In geval van één van mijn domeinen is dat dan hetvolgende:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2+nq6VSz/wtRBmuCbenNYbens5a3xyG+9qIVJE5CAEjcgwW6uBgE4heZ5w/qYSFUwdGvhHJ3X2XmQGdkibivPQPY48URte2IcYr1vfPvf4vV0+0Scwtm143O4PmSdp1bX2Xsvki8gGqtR9hXBbqpf3kVh7B85RK9mQvOonQMVawIDAQAB; n=1024,1450051420,1
Reden hiervoor is dat sleutelbeheer en -rotatie te allen tijde door Microsoft kan worden uitgevoerd en dat er nooit een extra handeling nodig is in de DNS-settings van de klant na de initiële configuratie.
Overigens is Office365 geen client, maar een zakelijk hostingomgeving van Microsoft gebaseerd op een Exchange server omgeving. De Exchange server is degene die de signature toevoegt uiteraard, dat doet nooit een lokale client (of webmail client).
-
Ik zou de log variabele in de dkim settings tijdelijk aanpassen om te zien of je daar iets uit kunt halen:
## LogWhy { yes | no }
## default "no"
##
## If logging is enabled (see Syslog below), issues very detailed logging
## about the logic behind the filter's decision to either sign a message
## or verify it. The logic behind the decision is non-trivial and can be
## confusing to administrators not familiar with its operation. A
## description of how the decision is made can be found in the OPERATIONS
## section of the opendkim(8) man page. This causes a large increase
## in the amount of log data generated for each message, so it should be
## limited to debugging use and not enabled for general operation.
# LogWhy no
-
Dat heb ik nu gedaan en herstart, maar waar/of ik die log moet vinden is me nog even niet duidelijk. Het staat niet in het "normale" Synology logboek iig.
-
/volume1/@maillog/maillog
-
Misschien heb je hier iets aan?
https://support.microsoft.com/nl-nl/help/3145666/550-dkim-ndr-error-when-office-365-users-send-mail-to-an-external-doma
-
Dit lijkt bij mij niet de reden te zijn. De O365 omgeving is exact zo ingericht zoals door Microsoft geadviseerd, inclusief CNAME records in DNS.
-
In het log staat niet meer dan "Rejected". Ook niet meer info met extra logging.
Mij valt wel op dat jouw DKIM ondertekening geen timestamp heeft. Volgens mij staat die in bijna alle mail. Volgens de specificaties is het een "aangeraden" parameter en geen verplichte.
Als ik in de source van OpenDKIM kijk, dan krijgt de variabele "sig_timestamp" de waarde nul als die t ontbreekt.
Elders in de code vind ik:
/*
** DKIM_SIG_GETSIGNTIME -- retrieve signature timestamp
**
** Parameters:
** sig -- DKIM_SIGINFO handle
** when -- signature timestamp (returned)
**
** Return value:
** A DKIM_STAT_* constant.
*/
DKIM_STAT
dkim_sig_getsigntime(DKIM_SIGINFO *sig, uint64_t *when)
{
assert(sig != NULL);
assert(when != NULL);
if (sig->sig_timestamp == 0)
return DKIM_STAT_INVALID;
*when = sig->sig_timestamp;
return DKIM_STAT_OK;
}
Dat doet vermoeden dat OpenDKIM de waarde null als een ongeldige waarde beoordeelt. Als ik dat goed interpreteer is dat een fout van OpenDKIM omdat de tijdcode geen verplicht veld is.
Maar misschien dat er nog ergens in de code nog iets staat dit nog overuled.
Is het voor jou mogelijk om aan serverzijde de timestamp toe te voegen?
-
Nee, helaas niet. Nadeel van een cloud dienst. Ik kan DKIM enkel aan- of uitzetten (en aan kan enkel als DNS van het domein goed is ingesteld).
-
Ik heb nu de "reject on-BadSignature" uitgezet. (Dat is eigenlijk de default van OpenDKIM, maar Synology heeft dat op reject gezet)
MailServer geeft een fail in de header:
Authentication-Results: xxx.nl; dmarc=pass header.from=xxx.eu
Authentication-Results: xxx.nl; dkim=fail reason="signature verification failed" (1024-bit key)
Als ik de mail echter met een cliënt open die ook DKIM kan controleren, zie ik:
[attachimg=1]
Thunderbird ziet de DKIM handtekening inderdaad als geldig. Ook nadat de mail door mailserver bewerkt is. Dit lijkt me toch een bug in OpenDKIM. Ik gok door de ontbrekende timecode. (Ik kan niets anders verzinnen)
-
Ik vond hier (https://help.returnpath.com/hc/en-us/articles/222438487-DKIM-signature-header-detail) nog iets over een missende 'timestamp' in de DKIM signing:
Spammers don’t normally set time values. Empty or incorrect time values, such as an expiration time dated before the email timestamp, will cause some mailbox providers to reject the message.
t= is the DKIM signature timestamp. It is meant to indicate the time that message is sent. The format is the number of seconds from 00:00:00 on January 1, 1970 in the UTC time zone.
Dus hoewel de timestamp optioneel is, gebeurt het vaker dat dit soort mail geblokkeerd wordt. Voor de betrouwbaarheid zou een mailserver dus altijd een tijdcode moeten toevoegen. Er is ook niets geheims aan de tijd van verzenden. OpenDKIM accepteert tot 5 minuut afwijking voor het geval van niet synchroon lopende klokken.
Edit:
De timestamp is toch niet essentieel voor OpenDKIM. Ik zag net dat de mailings van de Hanos ook geen timestamp hebben:
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed; s=selector1; d=td42.tripolis.com; h=Date:From:To:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; bh=X/d1yuiYnyIvRqhSQSU0fs0WSHFT8nzIqGCTLLsACMs=; b=dy0XqU6powzbAzGoWLShkLZtsrOKCtj56nHC8UMwqBmtB7EltJSq/HDqQTP5SX1yNKrIXfdnVg9C uy0C/swT4NFXDeKq7hxByf98k5PFNN8tSCTGh1oarwans30aLBUcejtQOARLonOLEkbrg6sD54tS xZAI9sdYQkwxmEz4Ofw=
Er gaat dus iets anders fout.
-
Die indirecte methode via een alias, is ook niet de reden. Het voordeel van die alias is vooral dat jij dat record niet hoeft te publiceren. Als de office server de key veranderd, hoef jij geen actie te ondernemen.
Ik heb jouw public key eens met die van Tripolis vergeleken Die mailing krijg ik altijd probleemloos binnen en loopt blijkbaar ook via zo'n CNAME constructie:
Briolet$ host -t txt selector1._domainkey.xxxx.eu
selector1._domainkey.xxxx.eu is an alias for selector1-xxxx-eu._domainkey.xxxx.onmicrosoft.com.
selector1-xxxx-eu._domainkey.xxxx.onmicrosoft.com descriptive text
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxTrZ+VDlN3aazo0yCSl8WWIiHOzr4cWlBrcrdGxKdAlJnmjI230siLmDotGS4uxtnxg0BaySb7k4CwMuoBrBQXQKPy5y8d2mMmga+lLue3EMxWetrf12Y+4We75gS/91/sndq5EqcUkoN2Oim2DBJEkZ5isXzC20lsxpGTzi/aQIDAQAB;"
--------------
Briolet$ host -t txt selector1._domainkey.td42.tripolis.com
selector1._domainkey.td42.tripolis.com is an alias for selector1-td42.dkim.tripolis.com.
selector1-td42.dkim.tripolis.com descriptive text
"v=DKIM1;h=sha256;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8wISrBaa7vaO6zRxx7JxPWNPljUulngxMAdWOVEMba2438TqneT4WbLDPXnovuzYMKmK7" "SXMhjf5R1xGxtSmc9thOCa1VkzcVtgBbQywBL5TmoIc/f6YlRf9dFsmvm7WxwBkbbdZGD7bGys7kmndH5+xdQ2goazQudZ5kK8EUZwIDAQAB"
Daar zie ik geen fundamenteel verschil tussen.
------
Wat je kuny proberen is om geen CNAMe te gebruiken, maar het TXT record zelf te publiceren. Moet ook gewoon werken, zolang onmicrosoft.com de sleutels niet aanpast. In elk geval kun je voor de duur van een test die records eens aanpassen om te zien of het dan wel werkt.
-
Sinds begin juni ook problemen met bijna alle office 365 beheerde domeinen. De mail log laat zien dat de mails gestuurd vanaf die domeinen geweigerd worden ivm bad DKIM Signature.
Na met meerdere beheerders gesproken te hebben, bleek dat zij de instellingen precies zo hadden ingesteld als geadviseerd door microsoft. Uiteindelijk een ticket aangemaakt bij synology, welke vrij spoedig opgepakt werd. Uitkomst (
2018-07-31) zie hieronder:
Hi Martijn,
Thank you for waiting.
After confirming by our developer, this is a known issue that our developers are working hard to address in a future release.
Please kindly stay tuned for the update, and in the meantime, we apologize for any inconvenience caused.
[Fix]
Please install the Mail Server package (attached with in the message) in Package Center.
Please let us know if the issue is resolved after installing the package in Package Center, thank you.
De fix nog niet geprobeerd... zal deze in het weekend toepassen.
-
Fix heeft inderdaad geholpen, stond bij mij sinds 2 uur in package manager beschikbaar. Zojuist geinstalleerd, een mail gestuurd en DKIM signature is nu wél in orde!
-
Ik kan niet zien wat veranderd is omdat alles van mailserver vernieuwd is. De config file is in elk geval wel gelijk gebleven.
Mooi dat het nu wel werkt.
-
Misschien hebben ze wel niets zelf gefixed, maar alleen OpenDKIm een keer geupdate. Ik zie nml dat versie "2.10.0" van december 2014 nu naar versie "2.10.3" van mei 2015 geupdete is.
De releasenotes van de OpenDKIM updates zijn:
2.10.3 2015/05/12
LIBOPENDKIM: Make strict header checking non-destructive. The last change
to this code resulted in failing signatures. Reported by Pedro
Morales and Wez Furlong.
2.10.2 2015/05/10
Fix bug #221: Report a DKIM result of "policy" if MinimumKeyBits
or UnprotectedKey cause the signature to result in a "pass"
override. Reported by Kurt Roeckx.
Fix bug #227: Revert removal of SenderHeaders configuration setting.
Document that it is now limited to signature selection.
LIBOPENDKIM: Fix bug #226: Deal with header fields that are
wrapped before there's any content. Reported by
Alessandro Vesely.
CONTRIB: Update to contrib/systemd/opendkim.service.in from
Steve Jenkins.
2.10.1 2015/02/03
Fix bug #214: Handle arbitrarily large From: fields. Reported by
Tomohiko Sasaki.
Fix bug #220: Make DB_SIGNINGTABLE symbol available in Lua scripts.
Problem noted by Klaus Heinrich.
LIBOPENDKIM: Fix bug #213: Remove "dkim_default_senderhdrs" from
dkim.h. Problem noted by Daniel J. Luke.
LIBOPENDKIM: Fix bug #219: Unresolved CNAMEs are not failures,
according to the DNS (see RFC6604), so report them as
NXDOMAIN or similar. Reported by Alessandro Vesely.
2.10.0 2014/12/27
-
Misschien hebben ze wel niets zelf gefixed, maar alleen OpenDKIm een keer geupdate. Ik zie nml dat versie "2.10.0" van december 2014 nu naar versie "2.10.3" van mei 2015 geupdete is.
Dat is toch wel schandalig dat er zo veel DS updates verder nog altijd niet naar de laatste versie van OpenDKIM geupdatet was..... In elk geval zijn ze nu bij en werkt het nu ook. Thanks voor al je inzet bij het meehelpen uitzoeken nog.
-
Storend is dat DKIM toegevoegd is in DSM 5.2. Deze DSM versie heeft een releasedatum van 2015-05-12. Heel toevallig dezelfde releasdatum als de laatste versie van OpenDKIM.
Waarschijnlijk was versie 2.10.0 de actuele versie toen DSM 5.2 de beta fase in ging maar hebben ze er verder niet meer naar omgekeken toen er nog een paar bugfixes verschenen.
Ook vreemd dat ik uit de relesenotes van DSM 5.2 moet halen dat DKIM toegevoegd is, terwijl hierover niets terug te vinden is in de releasenotes van MailServer zelf. Terwijl het daar toch echt in zit en niet in DSM.
Beter laat dan nooit, zullen we maar zeggen. ;)