Mail verificatie (SPF, DKIM & DMARC)

[MaVeWeb]

Dus wordt DKIM, SPF etc alleen gebruikt wanneer je GEEN smtp mail relay toepast?

[Briolet]

Nee, in beide gevallen. Voor Ziggo moet ik alles via de relayserver laten lopen omdat ik niet vrij via poort 25 mag verzenden, dus mijn testen lopen via de mailserver relay-instelling. Maar als het daar werkt, werkt het zonder relay instelling in MailServer, zeker.

In mijn Apple Mail client heb ik 4 IMAP accounts. (GMail, Ziggo, eigen-domein op de nas en mijn externe mailprovider) Het GMail account gebruikt de gmail-smtp server, maar de andere 3 accounts op mijn mac's gebruiken de nas als smtp sever. Die op zijn beurt, stuurt alles via de relayinstelling door naar de Ziggo smtp server. Maar alleen de mail die mijn eigen hostnaam als afzender gebruikt, wordt door MailServer DKIM-ondertekend.

SPF verzenden is iets anders want het verzenden gaat zonder SPF. Dat is alleen een entry in het DNS record van mijn domeinnaam. Een SPF record in mijn domeinnaam had ik al voordat die optie in MailServer toegevoegd werd. Die optie in Mailserver is voor IN-komende mail. Van elk mailtje kijkt hij of het domein van de afzender een SPF entry bevat en handelt ernaar. Bij SPF voegt de verzender niets toe aan de mail, alleen de ontvanger.

[Pippin]

Ik vraag me natuurlijk wel af waarom juist te ruime rechten (schrijfrechten voor groep & public) de boel blokkeerden. Moet ergens een beveiliging check geweest zijn die bij te veel rechten de boel op slot gooit.

Net zoals hier heeft dat vermoed ik met Apparmor te maken.
Dat is ook aanwezig in 5.1 en aangescherpt vanaf 5.2.

[Briolet]

SPF zou volgens het protocol mail moeten bouncen bij een hard fail en in de spamfolder moeten zetten bij een soft fail. Dat laatste werkt nog niet want die mail wordt gewoon doorgelaten. Je ziet alleen een opmerking in de mail header maar die ziet een gebruiker normaal nooit:

Received-Spf: softfail (msdp1.com: Sender is not authorized by default to use 'bounce-41mSkc-ulWl0fbiw3t7tCmjMCqIN34BA0qlEyKUZBRRc@msdp1.com' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched))

Je kunt wel instellen om soft fail te laten bouncen maar dat vind ik weer te grof want de afzender zal zijn reden hebben om geen hard fail in te stellen.

Probleem is dat mail die je forward altijd een fail geeft omdat de mail dan vanaf een andere server binnenkomt dan in het SPF record is ingesteld. Ik heb diverse instanties alleen mijn ziggo e-mail adres gegeven en een deel bounced nu. Vroeger ging die mail naar mijn dataweb mail account en zij bouncen die mail niet maar gooiden het altijd in de spambox. Nu de mail naar mijn eigen mailserver gestuurd wordt heb ik maar ingesteld dat er altijd een kopie op de Ziggo site blijft staan.

Voor mij een reden om een feature request naar Synology te sturen met het verzoek om een optie in te bouwen om bij falen van de SPF test, de mail in de spambox te zetten i.p.v. te bouncen. Dit ten behoeve van mensen die externe mailboxen naar de nas willen forwarden.
Verder heb ik verzocht om in de help file de waarschuwing op te nemen dat forwarded mail altijd een failure situatie zal genereren.

[Briolet]

Vandaag liep ik tegen dit document uit maart 2015 aan: Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Dit document beschrijft duidelijk de werking van DMARC en gaat ook in op SPF en DKIM omdat die met DMARC te maken hebben. Nuttig leesvoer als je zelf een DMARC record in je DNS zet.

[Stephan296]

Klopt dan krijg je netjes elke dag een mail met gegevens. Heb ik ook een tijdje gehad.

Verstuurd vanaf mijn Nexus 5 met Tapatalk

[Briolet]

Ik had wel steeds vreemde DMARC resultaten. Volgens de terugkerende rapporten kreeg ik steeds een dmarc=pass. Echter als ik de header in de mail analyser van google invulde kreeg ik steeds de melding: SPF=pass, DKIM=pass, DMARC=fail.

Die fail kwam doordat er 2 dmarc regels in de header stonden. 1 met DMARC=pass en 1 met DMARC=fail. De fail-regel luidde:

Code: [Selecteer]

Authentication-Results: mijndomein.nl; dmarc=fail header.from= mijndomein.nl

Echter, toen ik een mailtje naar een account verstuurde die geen DMARC of DKIM checks deed, stond die regel er ook in. Het lijkt er op dat Mailserver zelf al een DMARC test doet bij het versuren en dat slaat nergens op. Dat zal door het gebruik van de relay server komen. Op die server authenticeer ik me met mijn ziggo e-mail adres.

Dus heb ik voor de aardigheid het DMARC record in mijn eigen DNS server op de nas verwijderd. (Het had daar toch geen nut). Als ik dan een mailtje stuur vind ik in mijn header

Code: [Selecteer]

Authentication-Results: mijndomein.nl; dmarc=none header.from= mijndomein.nl
Dat bevestigd dat deze DMARC regel al in de uitgaande mail gezet wordt en door Mailserver gecreëerd wordt. Testen op dat moment lijkt me een bug.

Zonder eigen DNS server (met afwijkende DNS instellingen binnen mijn LAN) zou dit altijd een fail melding in de header geven. Gelukkig leidt dit niet tot een fail bij de ontvangers. Alleen de google mailheader analyser trekt hier een foute conclusie.

[Briolet]

Sinds een paar dagen was mijn DKIM ongeldig geworden. De dagelijkse dmarc rapporten gaven steeds een dkim fail. En in de header van de ontvangen mail stond steeds "  dkim=neutral (bad version) header.i=@.
Na lang zoeken blijkt dat de DKIM entry in mijn DNS record veranderd was van "v=DKIM1" naar "v=dkim1". Ik heb geen idee hoe dat gebeurd is. Ik kan me niet voorstellen dat ik dat zelf veranderd heb. Ook al omdat ook het DMARC record ook lowercase geworden is. "v=DMARC1" blijkt echter niet case sensitive te zijn.
Ik meld dit zodat anderen die dit overkomt, direct weten waar ze moeten zoeken.

[Briolet]

Gisteren kwam er weer een update van Mail Server binnen:

Version: 1.5-0482

(2016/04/28)
Enhanced the functionality of DKIM.
Improved the Daily Quota mechanism.
Fixed an issue where users might receive the notifications from themselves after enabling auto-reply.
Minor bug fixes.

Heeft iemand enig idee wat die uitbreiding van de functionaliteit inhoud? De menu's zijn in elk geval niet aangepast met andere opties.

[Briolet]

Ik kwam vandaag een pagina tegen van SIDN (waar alle nederlandse domeinnamen geregistreerd zijn) waar ze statistische gegevens bijhouden van het gebruik van de domeinnamen. Voor mail vind je dat hier.

Je ziet b.v. in het eerste plaatje dat er in de 2e helft 2018 plots een sterke toename van het DMARC gebruik gekomen is tot een kleine miljloen domeinnamen. En daarna geen significant verdere stijging. (De lichtblauwe lijn.)
ca 3 minjoen domeinnamen gebruiken een SPF record (Groene lijn) terwijl er in totaal een kleine 3.5 miljoen domeinnamen zijn met een MX record (De dus mail kunnen verwerken)

[Briolet]

Er bestaat een beveiliging waarmee je kunt aangeven of jouw domein de mails via DKIM ondertekent.  (Domain Signing Practice ADSP) Deze beveiliging is al zeker 15 jaar oud en is in zekere zin overbodig geworden door het DMARC protocol.

Toch heb ik hem een jaar geleden voor de lol geïmplementeerd.  In je domein voeg je het volgende subdomein toe:

Code: [Selecteer]

_adsp._domainkey.mijndomein.nl
En hierin zet je het tekstbestand:  "dkim=xxxxxx"

Met xxx een van de volgende 3 parameters: <unknown>, <all> and <discardable>

Code: [Selecteer]

C<unknown>: Messages from this domain might or might not have an author
signature. This is a default if a domain exists in DNS but no ADSP record
is found.

C<all>: All messages from this domain are signed with an Author Signature.

C<discardable>: All messages from this domain are signed with an Author
Signature. If a message arrives without a valid Author Signature, the domain
encourages the recipient(s) to discard it.
Ergens zit hier een configuratiefout in mailserver.  Spamassassin checkt ook de uitgaande mail en  ik krijg steeds de melding in mijn uitgaande mailheader

Code: [Selecteer]

1.8 DKIM_ADSP_DISCARD      No valid author signature, domain signs all mail and suggests discarding the rest
Het lijkt erop dat deze check plaats vind, nog voor de DKIM ondertekening in de header geplaatst wordt, want uiteindelijk is de mail netjes ondertekend. 

Ik had dit probleem al een jaar genegeerd, totdat er vandaag een uitgaande mail als spam gezien werd. Deze check verhoogde de spamscore met 1,8 punt zodat ik al dicht tegen de drempel aan zat.

Nu kan ik volgens de autheur van de spamassassin module wel overrides in de config file plaatsen (link), maar ik heb er voor gekozen om de waarde in mijn locale dns server op 'unknown' te zetten. Dat doet hetzelfde als zo'n override en door de eigen dns server kan ik dingen lokaal anders laten reageren.