Synology-Forum.nl
Packages => Officiële Packages => Mail Station => Topic gestart door: jhattem op 01 juni 2020, 19:27:33
-
Hallo,
Ik zit met een probleem. Vanmiddag heb ik de nieuwste update van Mail Station uitgevoerd. Waarin onder andere de versie van Roundcube is geupdated naar Versie 1.3.8 (was 1.2.7). Sindsdien kan ik geen mails meer binnenhalen via POP
Normaal haalt Mail Station mijn mails van mijn externe postvak (Solcon) binnen, en maak ik vervolgens met mijn telefoon, computer etc verbinding via Imap met de mailserver van de Synology.
Ik kan nog WEL berichten versturen vanaf Mail Station, dus de SMTP instellingen lijken goed te zijn. Maar externe mail binnenhalen wil niet meer.
Het rare is dat de mails in de webmail van Solcon wel op gelezen komen te staan zonder dat ik ze zelf geopend heb, dus ergens wordt er toch wel iets binnengehaald met Mail Station lijkt het wel. Echter zie ik hier niets van in Postvak IN verschijnen, en zover ik kan zien ook niet in een andere map.
Wie heeft ervaring met dit probleem of er een oplossing voor?
Groeten,
Jurrian
-
Kijk eens in het echte maillog (en niet dat surrogaat-log van MailServer). Ook de logging van roundcube gaat daarheen.
-
Hallo,
Hoe bedoel je dat precies, en hoe kom ik daar bij?
Wat zou daar evt niet goed kunnen zijn?
Groet
Jurrian
-
Ik ken de locatie niet uit het hoofd. Het is iets van "/volumex/xx/maillog". De locatie is hier echter vaak voorbij gekomen.
-
Ik kom er net achter dat als ik de map waar nieuwe berichten binnenkomen aanpas naar een submap van Postvak IN, de mails dan wel binnenkomen....
Als ik dan de locatie bij de POP instellingen weer terugzet naar Postvak IN komen ze niet meer binnen.
-
Briolet,
Ik heb even gekeken maar kon het log nog niet zo snel vinden.
Kan dat wel gewoon via File Station, of moet ik dan anders inloggen?
-
Op de termal via SSH inloggen.
In mijn opinie moet je als Mail Server gebruiker toch regelmatig in dat log kijken. Alleen daar zie je goed als er inbraakpogingen (geweest) zijn. Mail Station logt daar precies in welke (sub)map een mailtje geplaatst wordt. En ook als het niet lukt.
-
Misschien een rare reactie van mij, maar inloggen via SSH heb ik nog nooit gedaan. ..
Kun je beschrijven hoe dat precies moet?
En wat kan de reden zijn dat de mails wel in een submap komen, maar niet in de hoofd Postvak IN map?
-
maar inloggen via SSH heb ik nog nooit gedaan. ..
Kun je beschrijven hoe dat precies moet?
Dat is hier beschreven:
NAS benaderen met SSH: Windows en OSX (https://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/)
-
Aha bedankt voor de link, daar staat het duidelijk beschreven.
Weet je toevallig ook het commando waarmee ik dan het logboek bekijken kan?
-
"cat /volume1/@maillog/maillog"
Bereid je voor op een listing van vele duizenden regels. Roundcube logt er onder de naam "dovecot".
Ik heb even gekeken wat er gelogd wordt als het poppen goed gaat:
2020-03-13T13:59:57+01:00 xxxxxx dovecot: lda(xxxx): sieve: msgid=<oXpPXnVjqc1LYmLUn1uusUJrMfILu78CUFl-8MYvzcZjchFH5OriwLpb-hXBbWYp@news.webhare.net>: stored mail into mailbox 'INBOX'
De naam van de mailserver waar het vandaan komt wordt niet gelogd. ook niet de naam van de afzender. Alleen het ID van de mail. Je moet dus het tijdstip van het poppen weten om de regel(s) tussen de duizenden terug te vinden.
-
Je moet dus het tijdstip van het poppen weten om de regel(s) tussen de duizenden terug te vinden.
Je kunt beter die file even kopiëren naar een Gedeelde Map met het volgende commando:
cp /volume1/@maillog/maillog /volume1/De Gedeelde Map/
Dan naar File Station en dubbele klik die file, dan wordt die file gedownload naar je PC.
Hierna openen met b.v. Notepad++ of Notepad.
-
Dat werkt inderdaad gemakkelijker. Zelf maak ik altijd een hard link met
ln /volume1/@maillog/maillog /volume1/[de gedeelde map]/maillog.log
Voordeel is dat die file dan altijd actueel is en je niet elke keer een nieuwe kopie moet maken. (die file kun je daarna ook veilig verplaatsen. hernoemen/wissen zonder het origineel te schaden)
Er zijn eigenlijk twee programmas bezig. Dovecot is het programma dat het hele imap gebeuren met mail cliënten verzorgd en ook het poppen doet. Dit logt naar het genoemde log.
Hier bovenop zit de roundcube schil die de GUI creëert. Die heeft een eigen log, maar ik heb geen idee waar dat zit. Volgens de configuratie file gaat dat naar een log folder in het installatiepad van roundcube. (Maar daar vind ik geen log files).
Maar omdat dovecot het eigenlijke poppen doet, zal dat roundcube log ook niet interessant zijn.
Ik zie in het config bestand van dovecot wel dat je kunt instellen om ook het afzend mailadres of het onderwerp van de mail te loggen. (maakt het zoeken gemakkelijker). IK zie ook dat er een verbose logging optie in te stellen is. Maar omdat het helle SSH gebeuren nieuw is, zou ik daar voorlopig niets mee doen en hopen dat er nu al iets gelogd wordt dat een aanknoping geeft.
Ik blijf het vreemd vinden dat plaatsen in de INBOX niet lukt, maar wel in elke andere map. Net alsof hij de INBOX niet kan vinden. (Wat dan zeker in het log zal staan)
-
Ik blijf het vreemd vinden dat plaatsen in de INBOX niet lukt, maar wel in elke andere map. Net alsof hij de INBOX niet kan vinden. (Wat dan zeker in het log zal staan)
Dat vind ik ook heel apart, want met de vorige versie van Mail Station (Thunderbird) heeft het altijd gewerkt. Ik heb al geprobeerd om de Inbox leeg te maken, en alle mail die daarin stond in een aparte map te plaatsen, maar dan werkt het ook niet. En naar de submap van Postvak IN werkt het probleemloos, als hij Postvak IN niet kon vinden zou een submap van die map ook niet gevonden kunnen worden toch lijkt me?
Ik zal eens even kijken of ik kan inloggen via SSH, en het logfile kan openen.
-
Je bedoelt echt een submab in de inbox. Ik dacht gewoon een extra postvak. Dat maakt het nog vreemder, want bij een corrupte file of map, zou dat ook met een submap fout gaan.
-
@Briolet
Ja inderdaad, ik heb een submap aangemaakt in Postvak IN genaamd Nieuw, als ik dan aangeef dat ik de mails wil laten binnenkomen in de submap Nieuw van Postvak IN, dan werkt het dus wel, maar wanneer ik hem terugzet naar Postvak IN komen ze niet meer binnen, echter worden ze dan nog wel geladen vanaf de mailprovider, omdat ze daar nog wel op gelezen gaan staan.
Ik ben ook even bezig geweest met WinSCP en Putty, en ik kan al inloggen en alle mappen zien etc.
Ook heb ik de logfile gevonden op de door @Briolet aangegeven locatie.
Maar ik kan het bestand niet openen. Ik krijg dan de melding zoals op bijgevoegde foto.
Zou het kunnen dat ik toch nog niet helemaal goed ben ingelogd en nog niet alle rechten heb?
-
Je moet het log hebben met de naam "maillog". Dat kan elk administrator account ook lezen. (Geen root voor nodig).
Ik heb zelf nog nooit een "clamd.log" in die "@maillog" folder gezien. Ik gok dat dit van het anti-virus pakket is, maar snap niet waarom jij die log file hebt, terwijl ik de virusscanner ook gebruik. (Of ik heb dat log niet omdat er nooit iets gevonden is :P ) Negeer dat clamd.log. Daar zul je root voor moeten zijn om te kunnen lezen.
Bij mij staan er alleen "maillog maillog.1.xz maillog.2.xz maillog.3.xz maillog.4.xz". De eerste is het actuele log. De andere zijn oude logs die geziped zijn en je ook niet nodig hebt.
-
Oh sorry, dat heb ik wel geprobeerd, maar toen ik de schermafbeelding genomen heb had ik net toevallig het clamp bestand geopend om te testen of die het ook deed. Maar bij het maillog bestand krijg ik dezelfde melding (zie bijlage)
Ik heb inderdaad ook meerdere maillog bestanden zoals je zei, maillog.1.xz en dan 2, 3, en 4.
En ik heb er een van MailPlus, maar dat komt denkik omdat ik die in het verleden een keer geinstalleerd heb, die gebruik ik nu niet meer.
Ik heb nu alleen via WinSCP ingelogd als admin op de server. Daarvoor heb ik de handleiding gevolgd die eerder geciteerd werd, dat zou voldoende moeten zijn om het logbestand te openen toch?
-
Dan moet je kennelijk toch root zijn in WinSCP, link wel goed opgevolgd?
-
Dan moet je root zijn in WinSCP, link wel goed opgevolgd?
Ja precies de stappen doorlopen.
Ik zie nu dat de eigenaar van de map @maillog MailPlus-Server is (zie bijlage) , maakt dat nog uit toevallig?
-
Is er niet iemand die een screenshot van zijn/haar configuratie kan/wil sturen? Zoals die eruit ziet in WinSCP?
-
Anders moet ik gewoon weer terug naar de vorige versie. Die werkte wel goed.
Is dat ook te doen via WinSCP?
Ik heb evt nog een server (DS713+) waar de werkende versie nog wel opstaat. Kan ik die ook overzetten naar de andere server?
Of is dat vragen om problemen?
-
Hallo,
Inmiddels kan ik het logfile wel openen, ik was toch niet goed als root ingelogd in WinSCP.
Alleen als ik een mailtje verstuur naar het emailadres wat aan de Mail Server hangt, komt deze wel aan, maar daar staat niks van in het logboek.
Wat mij wel opvalt is dat ip adres: 87.246.7.74 constant probeert te connecten. Nu las ik ergens op internet dat dit een 'verkeerd' IP adres is, en je deze gerust kon blokkeren, dat heb ik gedaan, maar toen stond er later in het logboek nog weer een log dat dit IP adres weer wou connecten..
-
Ik krijg deze melding in het logboek als ik de aflevermap gewoon op Postvak IN zet.
dovecot: lda(SERVER-01\username)<30088><j4gGIu35116IdQAAvVmdyg>: Fatal: Cannot obtain SMTP address from username `SERVER-01\username': Invalid character in user name
Dan komt de mail dus NIET goed aan.
En als ik verder terugzoek, naar het moment dat de mailserver nog wel mails binnenhaalde (voor de update) krijg ik bij elke binnenkomende mail deze melding:
dovecot: lda(SERVER-01\username): sieve: msgid=<emailcode@naam.emailadres.nl>: stored mail into mailbox 'INBOX'
-
Invalid character in user name
Dit geeft wel een richting aan, maar kan ik niet rijmen met het wel werken bij een submap.
Heb je eens geprobeerd mail binnen te halen via een ander account?
-
Met geen enkele account werkt het, moet er wel bijzeggen dat het allemaal domeinaccounts zijn.
Met een lokaal account heb ik het nog niet getest, omdat daar geen mailadressen aan gekoppeld zijn.
Dat zou ik evt kunnen proberen, maar dan moet ik dat eerst configureren.
-
Even een update over mijn mailstoring.
De mailserver werkt inmiddels weer goed, ik heb contact gehad met Synology Support.
Zij gaven aan dat er in het pakket een fout zat die bij veel meer gebruikers voorkomt, hun hebben pakket 20200522-0301 geïnstalleerd.
Die werkt wel goed.
Dus let op! Mail Station pakket 20200416-0296 KAN dus NIET goed werken.
-
versie 20200416-0296 staat in package center en in download center op de website. Ook bij de handmatige downloads staat deze versie als laatste genoemd.
De versie 20200522-0301 zie ik nergens staan.
Vooralsnog heb ik geen problemen met het binnenhalen van Pop. met de versie 296. Reden tot zorg?
-
De versie 20200522-0301 zie ik nergens staan.
Dat is omdat dit een tussenversie is die Synology er zelf op gezet is. De kans is ook redelijk dat deze versie nooit beschikbaar komt omdat er ook al andere bug(s) met de laatste versie gemeld zijn die (hopelijk) ook in een volgende release verholpen zullen zijn. (probleem met de classic layout)
Zelfs dit zou een probleem met de classinc layout kunnen zijn doordat die layout een illegaal karakter in de settings laat wegschrijven bij de keuze van de aflevermap. In het log wat jhatten laat zien wordt gemeld "Invalid character in user name".
-
versie 20200416-0296 staat in package center en in download center op de website. Ook bij de handmatige downloads staat deze versie als laatste genoemd.
De versie 20200522-0301 zie ik nergens staan.
Vooralsnog heb ik geen problemen met het binnenhalen van Pop. met de versie 296. Reden tot zorg?
Volgens synology komt het alleen bij domeinaccounts voor, na de update is volgens mailserver de gebruikersnaam (DOMEIN\GEBRUIKER) ongeldig. En dat veroorzaakt het probleem.
Ik weet niet of jii ook domeinaccounts gebruikt of alleen maar lokale accounts?
En het komt niet bij elke gebruiker voor zeiden ze. Dus het zou best kunnen dat jij toevallig wel een goedwerkend pakket hebt.
-
De versie 20200522-0301 zie ik nergens staan.
Dat is omdat dit een tussenversie is die Synology er zelf op gezet is. De kans is ook redelijk dat deze versie nooit beschikbaar komt omdat er ook al andere bug(s) met de laatste versie gemeld zijn die (hopelijk) ook in een volgende release verholpen zullen zijn. (probleem met de classic layout)
Dat zou inderdaad heel goed kunnen.
Ik krijg het SPK bestand met de versie die ik nu heb nog van synology. Die zal ik dan wel posten. Mochten er anderen zijn die dit probleem ook krijgen, dan kun je deze versie handmatig installeren, totdat er een nieuwe versie in Package Center beschikbaar is.