Synology-Forum.nl
Packages => Officiële Packages => Mail Server => Topic gestart door: Briolet op 09 maart 2017, 17:22:29
-
Version: 1.6.2-0487
(2017/03/09)
• Supports integration with Synology Active Directory Server as an account source.
• Fixed an issue where memory leak might happen.
• Minor bug fixes.
Blijkbaar worden nu ook de accounts uit de Active Directory Server ondersteund.
-
Zijn dat dezelfde gebruikers als de ldap gebruikers?
Ik zag het maar ldap gebruik ik al sinds 2013, dat is dus niet nieuw.
Wel de update gedaan en alles werkt, gelukkig, nog :)
-
LDAP is inderdaad niet nieuw. Ik vind al screenshots van DSM 4.3 waar die keuze in zit. Dan vraag ik me af wat ze wel bedoelen met die releasenote.
Ik vind ook geen nieuwe optie in Mail Server. Als ik overschakel naar LDAP accounts, werkt dat. Maar dan werken de mailadressen van de gewone accounts niet meer goed. De accountnaam als mailadres werkt nog wel, maar alle aliassen naar lokale accounts zijn dan onbereikbaar.
-
Mail adressen voor "gewone" accounts gebruik ik niet dus daar kan ik niets over zeggen.
In de setting zie ik inderdaad ook nergens een verschil.
Maar gisteravond wel een vreemde, voor af en toe webmail gebruik ik een eigen Roundcube.
Dus niet diegene die standaard bij Mail Station zit, Mail Station staat er bij mij niet op.
Kreeg een database error bij inloggen na de update.
Wilde er nu net even met frisse tegenzin naar gaan kijken en het werkt gewoon weer.
-
Ik zie nu pas het woord 'Active' voor Directory Server. Dat is inderdaad geen LDAP maar het nieuwe pakket in DSM 6.1. (Dat ik op mijn 212J met dsm 6.1 niet kan zien)
-
Hmm, ook niet echt gezien blijkbaar 8)
Active Directory was "vroeger" toch iets van Microsoft?
Of nog steeds natuurlijk.
-
Active Directory draait op Samba. Dat is open source en wordt gebruik door Microsoft, toch?
-
Deze versie heeft een probleem met de TLS en SSL smtp verbindingen:
Out: 220 xxxxxxx.nl ESMTP Postfix
In: EHLO [192.168.1.107]
Out: 250-xxxxxxx.nl
Out: 250-PIPELINING
Out: 250-SIZE 52428800
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: STARTTLS
Out: 454 4.7.0 TLS not available due to local problem
Out: 421 4.4.2 xxxxxxxx.nl Error: timeout exceeded
Session aborted, reason: timeout
Dit is al op het engels forum ter sprake gekomen met als fix een downgrade uit te voeren. Ik ben tijdelijk terug gegaan naar good old poort 25. https://forum.synology.com/enu/viewtopic.php?f=238&t=129224
-
Geïnstalleerd en getest... ik zie niks vreemds... alles doet 't...
-
Daar hebben ze het over problemen bij verzenden. Ik doe dat via poort 587 met Ziggo als relay. In het log zie ik geen problemen:
Trusted TLS connection established to smtp.ziggo.nl[212.54.34.9]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Ik snap ook de commentaren op het Engelse forum ook niet. Blijkbaar zit er een fout in de config file. Dan ga je toch die ene regel aanpassen (In de template ervan) en niet helemaal een oud pakket her-installeren.
Als oorzaak wordt genoemd:
directory of TLS certificate ist wrong in the new config file.
Bij certificaat kun je elk certificaat kiezen voor mailserver, dus zou ik verwachten dat het hen-en-terug veranderen van het certificaat dit ook kan rechtzetten.
-
Ik heb het als volgt tijdelijk opgelost:
in "/volume1/@appstore/MailServer/etc/template/main.template"
aan het eind van de file uitgecommentarieerd:
#smtpd_tls_cert_file = /usr/syno/etc/ssl/ssl.crt/server.crt
#smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key
toegevoegd:
smtpd_tls_cert_file = /usr/local/etc/certificate/MailServer/postfix/fullchain.pem
smtpd_tls_key_file = /usr/local/etc/certificate/MailServer/postfix/privkey.pem
Hierna de syno herstarten en na een minuutje drukt hij de template op de config file "/volume1/@appstore/MailServer/etc/main.cf".
Rechtstreeks editeren van main.cf levert ook een werkende mailserver op maar zodra de mailserver of Syno herstart wordt heb je de oude instellingen terug.
Ben benieuwd of dit bij de eerste update van de mailserver goed gaat :).
-
Vreemd. Ik heb niets aan de config file aangepast, maar bij staat er gewoon (in de config van 2 maart 2017):
smtpd_tls_cert_file = /usr/local/etc/certificate/MailServer/postfix/fullchain.pem
smtpd_tls_key_file = /usr/local/etc/certificate/MailServer/postfix/privkey.pem
Dat is exact hetzelfde als een config file die ik van een jaar geleden bewaard heb. Blijkbaar krijgt niet iedereen dezelfde main.template. Op zich vreemd. Ik gebruik niet het standaard certificaat, maar een eventuele aanpassing zou moeten gebeuren in het vertalen van de template file naar de echte config file.
Het zou kunnen dat deze bug er alleen bij bepaalde nas-modellen ingeslopen is. @KoenV, in elk geval bedankt om aan te geven in welke regels de fout zit.
-
Hi,
Ik heb net gekeken op mijn andere nas(DS716). Daar had ik de oudere versie van de mailserver geïnstalleerd om het juiste pad/filenaam. Deze geupdate naar de laatste mailserver versie en de paden blijven correct.
De fout treed op bij mijn DS413+. Je zou wel eens gelijk kunnen hebben dat het afhankelijk is van het type.
Verder zie ik dat ook de security config van de DS716 veel uitgebreider is Hier worden oude SSL versies uitgesloten terwijl dat bij de DS413+ niet gebeurd. Verder zijn er nog header checks en andere dingen extra in de config:
smtpd_tls_mandatory_exclude_ciphers = aNULL, RC4
smtpd_tls_exclude_ciphers = aNULL, RC4
smtp_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1
smtp_tls_fingerprint_digest = sha1
smtpd_tls_fingerprint_digest = sha1
smtp_tls_note_starttls_offer = yes
smtpd_tls_received_header = yes
header_checks = pcre:/var/packages/MailServer/target/etc/attachment_filter.pcre, regexp:/var/packages/MailServer/target/etc/header_checks
sender_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/sender_bcc
recipient_bcc_maps = hash:/var/packages/MailServer/target/etc/bcc/recipient_bcc
smtp_host_lookup = dns, native
duplicate_filter_limit = 32768
smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_aut$
smtpd_relay_restrictions = $smtpd_recipient_restrictions
message_drop_headers = bcc, content-length, resent-bcc
smtpd_tls_dh1024_param_file = /usr/syno/etc/ssl/dh2048.pem
smtp_tls_CApath = /etc/ssl/certs/
Dit 1 op 1 copieren naar de DS413+ werkt niet. Blijkbaar missen sommige dingen daar. De SSL versie restricites heb ik wel gecopieerd. de rest moet ik nog uitvissen wat precies wel en niet werkt.
-
Op mijn 415+ zie ik slechts 1 verschil met jouw file:
smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
-
Ik zie dat er nu weer een nieuwe versie 1.6.3-0488 is met releasenote:
Fixed an issue where sending/receiving emails via SSL might not work on DS413 and DS213+ models.
Dat moet de boven genoemde bug zijn. Gelijktijdig wordt bevestigd dat de bug alleen op twee modellen aanwezig was. Blijft de vraag waarom deze update ook bij andere aangeboden wordt.
Het model 413+ van KoenV staat er niet tussen als gefixed. ::)
-
Ik vond het ook al een beetje bijzonder.
Maar goed, wel alle modellen op het zelfde niveau.
Dat scheelt misschien later weer vragen?
-
Sorry mijn fout Ik heb geen DS413+ (die bestaat zelfs niet) maar een DS413. Na de update heeft de config.template idd de juiste verwijzing naar de certificaten gekregen maar niet alleen dat ook alle andere security settings zoals welke cphers toegelaten zijn staan er nu bij. Er was dus eea mis met de config.
Dit geeft me wel te denken hoe Synology zijn package voor de verschillende NAS modellen maakt. Blijkbaar moeten alle updates voor elk model appart gemaakt worden, dat is dus vragen om dergelijke issues vrees ik...