Synology-Forum.nl
Packages => Officiële Packages => Mail Server => Topic gestart door: Briolet op 13 maart 2015, 22:09:47
-
Ik heb net het beta pakket van mailserver geïnstalleerd. (DSM draait bij mij nog wel onder 5.1)
Ik zie dat er nu een afzender verificatie bijgekomen is. Via SPF (https://en.wikipedia.org/wiki/Sender_Policy_Framework), DKIM (http://dkim.org) en DMARC (http://dmarc.org).
Alleen met SPF ben ik een beetje op de hoogte. Die controleert of het afzender IP op een lijstje staat dat het domein legitimeert. Methode is niet foolproof en kan ook legitieme mail blokkeren als je de mail automatisch forward, omdat dan het afzender IP plots dat van de forwardende server wordt. :o
[attachimg=1]
Zie ook checking your domains dkim spf and spam record status for outgoing smtp mail (https://opensourcehacker.com/2014/02/19/checking-your-domains-dkim-spf-and-spam-record-status-for-outgoing-smtp-mail/) en mailcontrole met spf, dkim en dmarc uitgelegd (https://ziggoforum.nl/topics/mail-controle-met-spf-dkim-en-dmarc-uitgelegd.92195/)
-
Heeft er al iemand ervaring met de DKIM implementatie op de nas? Ik ben er afgelopen week mee bezig geweest, maar de help file is niet geheel duidelijk. Hij leek wel duidelijk, maar ik heb de indruk dat ik iets niet goed instel omdat mail niet verzonden kan worden als de DKIM optie aan staat. :'(
Wat DKIM is kun je ook lezen op: http://www.dkim.org
waarschuwing: er bestaat ook een dkim.nl site, maar die wordt door een commercieel bedrijf gehost die er juist geen belang in heeft om de werking uit te leggen. Zij willen dat tegen betaling voor jou instellen. :twisted:
Wat ik gedaan heb. In mailserver heb ik ingevuld:
[attachimg=1]
Deze publieke sleutel heb ik aan mijn DNS record toegevoegd:
Briolet$ host -t txt mail._domainkey.mijndomein.nl
mail._domainkey.mijndomein.nl descriptive text "v=DKIM\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7EnnYZdi7AgUPG/xRNHXFRJik14k+TPlS09+h+ctAEmCxGCHR50Kc/6UZbpvH9iDLSt31+SDJfZgQQnnmkEZXA/xTOS2UkXdhADBjYdPKvAbMjBxg799bR9cBj1sqTFGzNWTGk9FjJp4RPGdz5BY7thHj VmwYJHhnfxEDq2P2DQIDAQAB"
Maar ergens begrijp ik de instructies verkeerd. Iemand een hint?
Als ik naar http://dkimcore.org/c/keycheck ga en daar mijn domeinnaam in tik en de selector code, zijn alle checks OK.
EDIT: Ik zie dat het probleem zit in het verbinden met de SMTP server. Met ingeschakelde DKIM weigert mijn mailcliënt zelfs maar te verbinden met de SMTP server van de nas.
-
Op het engelstalige forum zag ik ook dat er mensen een vergelijkbaar DKIM probleem hadden bij gebruik van MailStation. Ik krijg dus eerder het vermoeden dat het een bug in de beta versie is.
-------
Ik heb vandaag eens geëxperimenteerd met de SPF verificatie.
Mijn externe mail provider deed altijd al een SPF check. Bij een soft-fail werd er alleen een spam waarschuwing in de titel gezet en bij een hard-fail werd het gehele bericht ook nog in de spambox geplaatst. Formeel moet een mail bij een hard-fail geweigerd worden.
Om te testen hoe de mail server van Synology hier mee omgaat heb ik een paar mailtjes verstuurd die een hard en een soft fail veroorzaakten.
Bij een hard fail wordt het mailtje geweigerd en wordt er dus niets afgeleverd. (Dat is de correcte implementatie). De nas stuurt wel een mailtje terug naar de afzender dat de mail bounced vanwege een SPF check met een link naar de pagina van openspf.net met uitleg over deze check en het IP adres wat te bounce veroorzaakte. Alles heel mooi.
Bij een soft fail is alles minder mooi. Als ontvanger merk je niet dat er een soft fail was. Alleen in de header kun je dit zien:
Received-Spf: softfail (mijndomein.nl: Sender is not authorized by default to use 'info@mijndomein.nl' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=GedeeldeData; identity=mailfrom; envelope-from="info@mijndomein.nl"; helo=smtpq3.tb.mail.iss.as9143.net; client-ip=212.54.42.166
Maar wie kijkt er nu in de header? Ik mag toch hopen dat dit ook in de message-titel gezet gaat worden, zoals nu ook bij een spamcheck gebeurd of dat dergelijke mail in toekomst naar de spambox gaat.
Het is in elk geval een optie die je altijd aan moet zetten. Als ontvangende partij hoef je hiervoor ook niets te configureren.
-
Ik heb gisteren nog eens verder getest met de SPF instellingen omdat je ook kunt instellen dat berichten bij een soft fail geweigerd moeten worden. De reactie die de verzender krijgt is echter anders. Omdat dit testen voor sommigen misschien lastig is en voor mij juist heel makkelijk omdat is een eigen DNS server heb draaien zodat ik allen met mijn locale DNs instellingen hoef te testen, stuur ik mijn resultaten ter info voor anderen.
Bij een SPF hard fail krijgt de verzender het volgende bericht terug:
Dit bericht is afkomstig van de mail-server.
U stuurde het volgende bericht, maar dat kon niet aan iedereen worden bezorgd:
======================================================================
Onderwerp: SPF test 5
yyyyyy
======================================================================
Op de volgende adressen kon het bericht niet worden afgeleverd:
briolet@mijndomein.nl
SMTP error from remote mail server after RCPT TO:<briolet@mijndomein.nl>:
host xxxx.i234.me [217.121.xxx.xxx]: 550 5.7.1 <briolet@mijndomein.nl>:
Recipient address rejected: Please see http://www.open-spf.org//Why?s=mfrom;id=info%40zijndomein.nl;ip=212.54.42.168;r=GedeeldeData
Als je de checkbox aankruist om ook een soft fail te weigeren krijg de afzender het volgende bericht terug.
Dit bericht is afkomstig van de mail-server.
U stuurde het volgende bericht, maar dat kon niet aan iedereen worden bezorgd:
======================================================================
Onderwerp: SPF test 7
xxxxxxxx
======================================================================
Op de volgende adressen kon het bericht niet worden afgeleverd:
briolet@mijndomein.nl
SMTP error from remote mail server after end of data:
host xxx.i234.me [217.121.xxx.xxx]: 550 5.7.1 message content rejected
Bij een soft fail heeft de afzender dus geen clue wat de reden van rejection was.
Normaal gesproken zal het alleen de spam verstuurder zijn die deze mailtjes retour krijgt. Maar als je mailtjes forward naar een server die het SPF controleert, faalt de controle ook en wordt dergelijke mail ook geweigerd. Dan is het wel prettig dat de verzender weet dat de mail niet aangekomen is.
Nog een waarschuwing voor het weigeren van mail bij een soft fail. Er zijn best wel veel bedrijven die hun mail systeem niet goed op orde hebben en dus een soft fail genereren. Je kunt wel op je strepen staan door te zeggen dat de fout van niet aangekomen mail bij de verzender ligt, maar jij bent degene die de mail niet krijgt. Bedenk dus of je dit wel wilt weigeren.
-
Ik kwam net nog de volgende test site tegen: https://www.internet.nl die door de overheid gesponsord wordt
Het was notabene de dmarc.org website die hier naar toe verwees als een bruikbare site om e-mail beveiliging te testen. Je moet wel alles dichtgetimmerd hebben voor een goede score. En zonder IPv6 faal je in elk geval voor elke test.
De mail test vind ik overigens wel matig omdat ik voor de test wel een dmarc en dkim entry aangemaakt heb in mijn dns record, maar op de nas staat het uit. De test kijkt dus alleen naar de aanwezigheid van de records.
NB: het starten van de e-mail test is niet intuïtief omdat je bij de internet test op deze regel kunt klikken. Voor de website- en email test moet je de cursor in het invulveld hebben en dan een return geven. Dus net anders dan de eerste test.
-
Hoi Briolet,
ik wil ook eens gaan experimenteren met DKIM. Wanneer zo zo een sleutel genereerd, HOE kun je die/doe je die dan aan je DNS toevoegen? Ik kan een SPF regel toevoegen en een TXT-regel. Beide heb ik nog synchroon staan. Moet dit DKIM record dan in de TXT-regel komen te staan?
-
In de help file staat dat op zich duidelijk uitgelegd maar omdat het bij mij niet werkte begon ik te twijfelen of ik het goed gelezen had. In principe maak je een TXT subdomein aan met de naam "code._domainkey en als content "v=DKIM1; k=rsa; p=[publiekesleutel].
Zo heb ik het ingesteld:
[attachimg=1]
Code (selectorvoorvoegsel) kies je zelf, zodat je meerdere codes met bijbehorende sleutels kunt maken voor je domein. Het probleem zit in de publieke sleutel. MailServer heeft geen export functie, dus moet je de sleutel van het scherm kopieren. Omdat die sleutel meerdere regels beslaat krijg je er makkelijk spaties, returns of andere foute tekens in.
EDIT: de private en public key staan in de folder: /var/packages/MailServer/etc/dkim.key
EDIT 2: Sinds versie 1.5-0326 staat de sleutel in een eigen invulveld en kun je hem wel probleemloos vanuit dat veld op je browserscherm kopiëren.
Ik kan een SPF regel toevoegen en een TXT-regel.
Volgens mij kijkt niemand naar het SPF record maar alleen naar het TXT record dat begint met "v=spf1..."
In elk geval heb ik vele hosts bekeken en nergens vond ik een expliciet SPF record, alleen de TXT versie. Bij Hostnet kun je niet eens een SPF record aanmaken.
Sterker, op de eigen DNS server van Synology kun je wel een SPF record aanmaken maar als er ook een TXT record is met SPF content, dan gebruikt hij die en negeert het SPF record. Dat bleek in elk geval uit mijn testen met tegenstrijdige info in beide records.
zie b.v.:
Briolet$ host -t TXT google.com
google.com descriptive text "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
Briolet$ host -t SPF google.com
google.com has no SPF record
Alleen een TXT record bij Google en andere grote namen die ik getest heb.
-
Ik heb even een mailtje van de Hanos doorgespit. Zij besteden het verzenden van mailings uit aan tripolis.com en die firma gebruikt ook DKIm verificatie.
Hun TXT bestand ziet er als volgt uit:
Briolet$ host -t TXT s20120227._domainkey.ntd42.tripolis.com
s20120227._domainkey.ntd42.tripolis.com descriptive text "k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDaGqO6Sl7WrqfTQlJLLpn+1vQL+piQY4aPA8yLHovkO99WXN852Fy3ASrFDhDJUeeD8mH5AwRhSws8sI" "kLAWQGiJ718lczFbJxh4wsiuefMzDJ35HpPEuWb/hnSiGKdXKcCtRGfOpu+xeH/bEq1lMh53cZxsJGMbE79uWrXhvraQIDAQAB"
Wat me opvalt is dat het stukje "v=DKIM1;" bij hun ontbreekt. Blijkbaar niet essentieel :?: Verder zie ik dat de sleutel in hun record in tweeën geknipt is. Blijkbaar mag dat ook als niet alles op één regel past.
-
Het lijkt of DKIM bij mij werkt. Ik heb een domein bij Strato geregistreerd staan. Ik kan daar een TXT-record instellen. Ik kan er echter geen naam aan toekennen. Vandaar dat ik the DKIM record als volgt ingevuld heb:
[DKIM-VOORVOEGSEL]._domainkey.[MIJNDOMEIN.NL] in txt "v=DKIM1; k=rsa; p=FDGJFDGJFD/DFHhghfgfjfkgkgkgklghkGKHFGH.................."
Wanneer ik nu mail relay uitzet en een mail verstuur, zie ik o.a. het volgende in de header van mijn e-mail tevoorschijn komen:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=[MIJNDOMEIN.NL];
s=[VOORVOEGSEL]; t=1431351271;
bh=6hjgjf697696+gf5gg..........=;
h=Date:From:To:Subject;
b=ljgfdkgjdfkl;gj;lfkgj;fldkgj59060568950690569050965
fldgkfl;gkfdl;gktort+_rtyrtykljsgkl;hjgkhgjkhjgklhhjj
hkghghklg;h88768GFJHHJH456efjsdkfjdsklj;kjhh=
-
Dat ziet er alles correct uit. :lol:
Nu alleen uitvinden waarom ik geen SMTP verbinding krijg met DKIM ingeschakeld. :P
Als je overigens ook een DMARC record aanmaakt bij je DNS provider, kun je verwachten dat je een paar dagen erna een mailtje krijgt met als afzender: dmarcrep@microsoft.com (Edit: zie ook dit blog (http://blog.returnpath.com/blog/cherie-ansari/reading-your-first-dmarc-reports) over deze reports.)
Ik dacht eerst dat het een phishing mail was, omdat het alleen een zip bestand bevat. De afzender lijkt echter volkomen legitiem uit het microsoft domein te komen. De inhoud bevat enkele van mijn DMARC instellingen in het DNS record.
Overigens heb ik een soortgelijk mailtje vanuit het G-Mail domein gekregen. met afzender: noreply-dmarc-support@google.com
De zip bevat de tekstfile:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<extra_contact_info>http://support.google.com/a/bin/answer.py?answer=246xxxx</extra_contact_info>
<report_id>10xxxxxxxxxxxx</report_id>
<date_range>
<begin>1431043200</begin>
<end>1431129599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>mijndomein.nl</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>quarantine</sp>
<pct>20</pct>
</policy_published>
<record>
<row>
<source_ip>212.54.42.166</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
<reason>
<type>sampled_out</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mijndomein.nl</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mijndomein.nl</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
Hij is gestuurd aan het e-mail adres dat ik in het DMARC record gezet heb. Ik heb dat record gisteren nog eens aangepast en en een uniek email adres in gezet dat ik nog nooit eerder gebruikt heb, en plots krijg ik weer een mailtje van microsoft naar dat nieuwe e-mail adres.
-
Na nog wat studie in de werking van DKIM verwacht ik dat dit ook niet bruikbaar zal zijn bij gebruik van de SMTP relay, zoals ik bij Ziggo voor uitgaande mail moet gebruiken. Bij DKIM wordt een checksum over de gehele mail berekend, maar de relay server zal de mail nog eens aanpassen zodat de ontvanger altijd een mail ontvangt waarbij de checksum fout zal zijn. Hij ziet de mail dan als 'frauduleus'.
Dit is overigens niet de reden van de SMTP error die ik steeds krijg als DKIM aan staat, omdat deze ook optreed als ik de relayserver uit zet.
Ik vond wel een commerciële relayserver waarbij je wel DKIM kunt gebruiken. Je moet dan hun publieke DKIM sleutel aan je eigen domeinnaam toevoegen en hun verzoeken DKIM authenticatie voor jouw mail aan te zetten. De relay server voegt dan de authenticatie toe.
-
Nu alleen uitvinden waarom ik geen SMTP verbinding krijg met DKIM ingeschakeld. :P
Op het Engelse forum waren er ook meerdere meldingen van dit probleem. Iemand heeft hierover een bugmelding gedaan en Synology heeft het bij hem remote opgelost. Het probleem zat hem in de rechten van de folder: "/usr/syno/etc/packages/MailServer". Deze moet 755 zijn, maar was 777. Hij heeft ook andere rechten dan de andere packages die allen op 755 stonden. (drwxr-xr-x)
Ik heb de rechten op 755 gezet en nu werkt de SMTP server bij ingeschakelde DKIM. Zenden gaat ook goed en de mail van mijn nas-account naar mijn GMail account loopt ook goed. Ik ben dus blij dat DKIM ook via een relayserver werkt. De hash wordt blijkbaar alleen over het bericht zonder de headers berekend. In elk geval geeft GMail een: 'dkim=pass'. :)
Waardoor de rechten fout stonden weet ik niet. Ik heb nog nooit rechten aangepast via SSH toegang. Alle pakketten hebben nu 755 als rechten met uitzondering van VPNCenter die ook op 777 staat. Dan ga je je afvragen of die ook fout kan zijn. Voorlopig maar afblijven.
-
Bij mij, schone installatie 5.1-5055, staan alle pakketten op 755 in /usr/syno/etc/packages, ook VPNCenter.
-
Dank voor de melding. Ik heb de rechten van VPNCenter nu ook aangepast. 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. Synology is nu op de hoogte dat dit probleem speelt. Ik ben benieuwd of ze dat in een volgende update gaan rechtzetten.
Op de mac heb je het programma schijfhulpprogramma dat de rechten van alle files naloopt en weer rechtzet. Het zijn meestal de printerdrivers die andere rechten hebben dan Apple vindt dat ze moeten hebben.
-
Als test heb ik ook een mailtje met mijn @Ziggo.nl adres als afzender via MailServer naar mijn GMail adres gestuurd. Daar werd netjes de DKIM ondertekening weggelaten. Het mailtje zou anders door de ontvanger geweigerd worden.
In elk geval weet ik nu dat MailServer slim genoeg is om te zien welke mailtjes hij met dkim moet ondertekenen. ;)
-
Dus wordt DKIM, SPF etc alleen gebruikt wanneer je GEEN smtp mail relay toepast?
-
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.
-
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 (http://www.synology-forum.nl/vpn-server/beter-beveiligde-openvpn/) heeft dat vermoed ik met Apparmor te maken.
Dat is ook aanwezig in 5.1 en aangescherpt vanaf 5.2.
-
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.
-
Vandaag liep ik tegen dit document uit maart 2015 aan: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (https://datatracker.ietf.org/doc/rfc7489/?include_text=1).
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.
-
Klopt dan krijg je netjes elke dag een mail met gegevens. Heb ik ook een tijdje gehad.
Verstuurd vanaf mijn Nexus 5 met Tapatalk
-
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 (https://toolbox.googleapps.com/apps/messageheader/) 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:
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
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.
-
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.
-
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.
-
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 (https://stats.sidnlabs.nl/nl/mail.html).
Je ziet b.v. in het eerste plaatje (https://stats.sidnlabs.nl/nl/mail.html#domeinnamen) 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)