Mail Station DKIM

[Heeren01]

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

[Heeren01]

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

[Briolet]

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.

[Heeren01]

Kan je bij RedirectFailuresTo ook meer dan 1 adres opgeven? Zo ja, gescheiden door komma’s?

[Heeren01]

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.

[Briolet]

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"  . 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.

[Briolet]

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:

Code: [Selecteer]

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.

[@rno]

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:

Code: [Selecteer]

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:

Code: [Selecteer]

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.

[Briolet]

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.

[Briolet]

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.

[@rno]

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:

Code: [Selecteer]

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).

[Briolet]

Ik zou de log variabele in de dkim settings tijdelijk aanpassen om te zien of je daar iets uit kunt halen:

Code: [Selecteer]

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


[@rno]

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.

[Briolet]

/volume1/@maillog/maillog

[Briolet]

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