Synology-Forum.nl
Packages => Officiële Packages => Mail Station => Topic gestart door: GerardR op 07 juli 2013, 07:43:02
-
KPN vernieuwd momenteel de mailboxen en heeft de opzet van de webmail veranderd en box vergroot. Deze vernieuwing heeft vervelende consequenties voor het binnenhalen van pop3 berichten op de mailserver.
Zelf heb ik deze ervaring vanaf vrijdagmiddag jl.
Instellingen van mijn mailserver/mailstation zijn ongewijzigd.
Voor de mailboxen bij KPN die door KPN nog niet gewijzigd werkt alles nog prima.
Bij de mailbox volgens de nieuwe opzet gaat het fout.
Instellingen ter info
Mailserver
SMTP ingeschakeld; accounttype: lokale gebruikers
Domeinnaam: <mijndomein>.nl
Max. grootte: 10
SMTP Relay ingeschakeld
server: smarthost.direct-adsl.nl
poort: 25
IMAP/POP3 ingeschakeld
Mailstation
pop3 account
e-mail: <naam>@kpnmail.nl
gebruikersnaam: <naam>@naamprovider.nl
pop3-server: pop.kpnmail.nl; pop3-poort: 110
Pop3-serverinstellingen > ontvangst e-mail toegestaan
SMTP serverinstellingen > smtp.kpnmail.nl poort 25
Het probleem inmiddels bij KPN gemeld. Het wordt onderzocht.
Aanvullend heb ik op mijn computer in outlook een email account (pop3) aangemaakt. Ik laat vervolgens de mail rechtstreeks binnenkomen, dus buiten de DS mailserver om. Dit werkt soms wel. Dit betekent volgens mij dat door de wijzigingen bij KPN, het binnenhalen van pop3 mail op mailstation niet meer goed werkt.
Moet dit aan Synology worden gemeld? Het is niet voor eerst dat er problemen zijn met het binnenhalen van pop3
-
POP3 is een standaard protocol, en als iedereen zich netjes aan de regels houdt, dan zal het gewoon moeten werken. Als KPN iets aanpast en het werkt in eens niet meer, dan zal ik eerst bij KPN nagaan wat zij hebben aangepast, waarna je dit altijd nog bij Synology neer zal kunnen leggen. Maar het lijkt mij dat KPN moet gaan zoeken, aangezien zij POP3 als service aanbieden en dus ook moeten zorgen dat het protocol netjes ondersteund wordt.
-
Dank voor je reactie.
Vanzelfsprekend is het mij bekend dat het een standaard protocol is. Ik wacht de reactie van KPN af.
Als je de moeite neemt om in dit forum terug te kijken dan zie je dat er eerder problemen zijn geweest met het binnenhalen van pop3 berichten. Een update heeft toen het probleem opgelost. Op voorhand wil ik niet uitsluiten dat het ook aan mailstation kan liggen. Ik spreek uit ervaring.
-
Dat geloof ik graag... Maar het is KPN die in dit geval iets veranderd heeft en je kan deze info mogelijk goed gebruiken bij het aanmaken van een verzoek bij KPN. Succes met afwachten. Hopelijk komen ze een beetje snel met een antwoord!
-
Na vele uren contact met de klantenservice van KPN waarbij alleen de laatste medewerker toegevoegde waarde had, heb ik de oorzaak van het probleem gevonden.
Bij het omzetten was door KPN een alias uitgezet. Dit was niet zichtbaar in mijn kpn (stond nog op "aan").
Via mijn KPN alias uitgezet en na een half uurtje weer aangezet. Vervolgens bevestiging ontvangen van KPN dat emailadres gereactiveerd is. Het werkt weer!
De nieuwe mailserver bij KPN is vooralsnog allesbehalve een stabiele omgeving.
Deze info vermeld ik tbv ander kpn klanten om hen tijd en moeite te besparen als bij hen het probleem ook voor doet. Constructieve medewerking van de klantenservice van KPN valt niet te verwachten.
-
Helaas doet zich het probleem ook voor bij het volgende mailaccount bij KPN. Na omzetting naar de nieuwe mailserver bij KPN worden berichten niet meer doorgestuurd naar mijn nas. Enkele medewerkers van de KPN klantenservice bevestigen dat er problemen zijn. Storingsdienst KPN weigert elke medewerking door zich te verschuilen achter algemene voorwaarden. Men ondersteunt geen lokale computers/mailserver, ook al blijkt uit de test dat het probleem bij KPN ligt.
Voorlopige work arround: zet in mijn KPN copy forward aan naar xxxx.mijndomein.nl met een kopie achterlatend op server KPN.
Willen KPN/planet klanten met een nas en dezelfde klachten reageren?
-
Sinds begin deze week ook dit probleem. Het vreemde is dat op mijn hoofdaccount alles goed verloopt. Op de extra account komt maar een enkele mail binnen. Binnen roundcube account opnieuw ingesteld, geen resultaat. Binnen Outlook direct aangemeld op de pop account en mail komt direct binnen. Als oplossing nog een extra account aangemaakt en alias overgezet. Afwachten wat dit gaat worden omdat dit account op de oude webmail is. Dus deze gaat ook nog worden overgezet.
-
Dank voor je reactie. Ik heb wederom telefonisch contact met KPN. Berichten van dezelfde afzender worden niet altijd doorgezonden. Er is geen regel in te ontdekken. KPN is bereid om te bekijken of alle berichten in hun pop server terechtkomen.
Het volgende vandaag (8/8'13) ontdekt.
Als ik vanaf de command prompt op mijn computer telnet als volgt opstart:
telnet pop.kpnmail.nl 110
user [mijn gebruikersnaam KPN]
pass [wachtwoord]
dan worden vervolgens het aantal mailberichten op de popserver bij KPN weergegeven.
Als ik vervolgens reset m.b.v. het commando RSET en daarna afsluit met QUIT verlaat ik de popserver bij KPN.
Alle pop 3 mailberichten die door KPN nog niet naar mijn mailserver zijn verzonden worden dan alsnog verzonden.
Het bovenstaande bij KPN neergelegd. Wordt vervolgd.
-
Vandaag over gegaan naar de nieuwe webmail, zag ik toevallig. De mails worden door de Synology gewoon bij KPN opgehaald. Ik gebruik pop.kpnmail.nl met poort 110.
-
Vandaag contact gehad met ICT afdeling KPN. Het blijkt dat er door KPN fouten zijn gemaakt met de aliassen bij het overzetten van oude naar nieuwe mailserver bij KPN. Volgens de KPN medewerker zou dit probleem zich niet meer mogen voordoen. Ik wacht af voor wat betreft de nog niet overgezette mailboxen.
-
Hier dezelfde problemen ondervonden. Meer dan 100 mails niet op mijn mailserver ontvangen. Lang gezocht en alle instellingen nog eens nagelopen kwam ik deze discussie tegen op het forum. Na de Telnet reset oplossing van Gerard de Raaij zijn alle gemiste mails alsnog binnengehaald. Met dank.
-
Ook als er anderen zijn met problemen, hoor ik het graag! Ik ben er nog niet klaar mee.
Gedragingen KPN klantenservice voor mij volstrekt onacceptabel.
Technische Service Desk KPN erkent dat er fouten zijn gemaakt. KPN heeft excuses gemaakt (voor wat het waard is!!)
Wanorde in deze organisatie is groot. Aangeboden gratis extra diensten (na het maken van excuses) worden gewoon in rekening gebracht. Toegezegde bloemetje namens directie nooit ontvangen. Ik hoop dat het niet meer komt. Risico is te groot dat het onder rembours wordt aangeboden.
-
Vij off-topic, maar toch: Dit is een van de redenen waarom ik tijden geleden afscheid genomen heb mijn provider e-mail adressen en afgelopen week ook afscheid genomen heb van glasvezel van KPN. Nu over naar XS4ALL wel een dochter van, maar totaal anders qua klantenservice, support en aanverwante zaken (tenminste 2,5 jaar geleden). Hoop dat dat zo gebleven is en uit eerder contact mbt de overgang lijkt dat wel zo te zijn.
-
Dank voor deze thread. Ik dacht dat ik weer eens een upgrade probleem had, sinds 1 sept kwamen niet meer alle emails automatisch binnen vanaf mijn KPN POP accounts. Toevallig ook mailstation en mailserver geupdated die dag.
Na tip met RSET van POP account kwamen de mails weer binnen.
-
Zijn de berichten dan ook weg na het RSET commando?
Eigen ervaring: nee ze worden neit gewist en JA ze komen dan binnen.
MAAAAR: de mails daarna komen dan weer niet binnen!
Ondertussen heb ik 2 aliassen uitgezet, de melding van KPN komt wel binnen en de testmail die ik tevoren gestuurd had niet. Nu snap ik het ook niet meer.
Ik ga toch niet elke dag resetten
Komt dit ook voor bij directe pop met bv thunderbird of outlook als programma op de PC, dus zonder tussenkomt van een NAS mail server?
Wim
-
Wim,
ik ervaar hetzelfde. Sinds dit weekend problemen, leek 1 dag goed te gaan, maar nu weer mis.
Ik denk dat we in ieder geval moeten melden bij Synology.
Het is in ieder geval niet duidelijk hoe het komt, ik heb inmiddels Mailstation package teruggezet, maar probleem blijft.
-
Dag Robroos
Ik denk niet dat het aan de synology ligt. Ik draai bij mezelf en bij mijn zus exact dezelfde configuratie DS110j met DSM3.2 en mailstation zelfde versies.
Ik op Ziggo feilloos
mijn zus bij KPN (via oud hetnet adres) met problemen sinds begin augustus, naar wat we nu weten.
Ik deed vanavond enkel de reset en de mails kwamen binnen, daarna blokkeerde knpmail weer de testmail van mezelf maar de maal van kpn kwam wel door. merkwaardig.
Morgen ga ik proberen om de mail zelf te poppen met thunderbird, zonder tussenkomst van de synology. Uns kijken of dat werkt.
Ik denk echt een KPN probleem. Wat lastig in dit draadje maar ik heb nog geen problemen bij andere proverders gehoord (buiten het feil van initieel lastig instellen van alles, maar als hjet loopt, dan blijft het lopen) Bij mij dus al 2 jaar goed, bij ziggo
Wim
-
Ter info Bij mij speelt het bij HETNET accounts die nu ondergebracht zijn bij KPN
Is dit bij jullie ook zo?
Wim
-
Dag allemaal
Snel de test gedaan: Thunderbird op de PC geïnstalleerd en daar een account aangemaakt waarbij ik rechtstreeks pop naar pop.kpnmail.nl op poort 110.
En warempel: de mail komt nu wel binnen....................................
Het lijkt dus toch aan synology te liggen.
Ik gebruik :
DSM3.2
Mailstation 20111125-038
Ik weet het, oude pakketten maar in combinatie met mijn DS110J een stabiele werkende combinatie, totdat KPN de mailboxen ging veranderen.
Wat zou de oorzaak kunnen zijn dan????
Wat nu?
gr Wim
-
Zelfs versie 4.3 kan nog op een 110j draaien.
Zou dat minder stabiel draaien dan versie 3.2?
-
Klopt wellicht, alleen als ik op DSM3.2 een nieuwere versie Mail Station draaide kon ik met IMAP geen contact leggen met de mailboxen. Dat wil je natuurlijk niet. Met thunderbird bleef hij hangen bij "mailserver mogelijkheden controleren". Zonder contact te krijgen met de mailbox op de synology.
Dat was 2 jaar geleden, ik heb na 2 nassen te testen dus besloten om bij de oude versie te blijven die wel goed werkte. Maar ik weet niet hoe het nu staat met het mailstation.
Wie draait dus DS110J met nieuwere versie DSM en/of Mail Station. En daarbij ook nog eens, wie zegt dan het probleem met KPN dan de wereld uit is....
Wim
-
Regelmatige reset met telnet is de enige oplossing zolang kpn niets doet!
Of foward naar imap adres op mailserver nas.
Van kpn medewerker begrepen dat structuur in mailverwerking op pop mailserver is gewijzigd. Ik kom tot de conclusie dat het niet aan synology ligt, tenzij zij te weten komen wat kpn heeft veranderd.
Waarom komen mailberichten dan wel binnen op nas na een telnet reset op de server van kpn? Op mailstation gebeurt dan niets!
-
Nog een test.
Ik zit bij Ziggo, ik heb dus in MailStation op de NAS een POP mail adres erbij gemaakt die de mail popt van mijn zus bij KPNMAIL, EN DAT WERKT WEL
Dus zou je van extern KPN wel kunnen poppen dan? Ik kan het vanuit mijn ziggo acount met Thunderbird op de PC en met MailStation op de NAS.
Ik moet toch eens proberen om bij mijn zus via de KPN account de mail met thunderbird binnen te halen...... Dat gaat niet vanavond lukken, dat duurt langer, dan moet ik even er naartoe rijden.
Wim
-
Controleer eerst even of haar account al over is naar de nieuwe mailserver.
Eigenlijk is het belachelijk dat wij met work arounds het probleem trachten op te lossen.
Het is KPN die aan de slag moet! De bug moet er uit!
Dames en heren specialisten bij KPN laat u niet langer belachelijk maken door uw afdeling list en bedrog (=klantenservice).
Waarom komt mail wel binnen na reset met telnet op uw server? De oorzaak moet toch te vinden zijn?
-
Hoe zie ik dat : dat de account op de nieuwe mailserver draait.
Ik zie nl wel dat er ruimt is voor 500mb opslag
Is dat het?
Wim
-
Hoe zie ik dat : dat de account op de nieuwe mailserver draait.
Ik zie nl wel dat er ruimt is voor 500mb opslag
Is dat het?
Wim
als je 500 mb opslag ziet dan zit je in de nieuwe opmgeving, was 30 mb
layout is gewijzigd. balk bovenaan: kpn logo email, agenda contacten, naam box, instellingen etc.
-
****Informatie update******
Vanmiddag wederom telefonisch contact met KPN. Vanuit derde lijn aanpassingen gedaan in emailstructuur en op verzoek van KPN getest. Resultaat voor mijn 3e en 4e box die recent zijn overgezet vooralsnog negatief. Dit zojuist telefonisch gemeld aan KPN. Wederom wordt actie ondernomen.
Tijdens laatste telefoongesprek eindelijk een eerlijk antwoord!
KPN heeft problemen met een groot aantal mailboxen van ex planet klanten. Het gaat fout met de aliassen die nog de toevoeging planet hebben. Er moet dan door "de derde lijn bij KPN" een aanpassing plaatsvinden.
wordt vervolgd.
-
Vreemd,
ik heb het probleem zowel met een pop.planet.nl mailbox met daarin alleen xxx@planet.nl mail, daar blijven ook random mails hangen.
Op de pop.kpnmail.nl krijg ik diverse mails binnen geforward vanuit diverse andere domeinen, sommige mails blijven hangen, andere niet, met zelfde forward adres.
Weet iemand waar de fetchmail log van de synology is te vinden, dan wel te activeren ? Dan kan ik misschien zien wat fetchmail terug krijgt van KPN
-
1) mail box bij mijn zus is nieuw (500mb)
2) thunderbird op pc geïnstalleerd popt moeiteloos van pop3.hetnet.nl en van pop.kpnmail.nl
3) bij tijd en wijle krijg ik ook RoundCube aan het werk. IK heb op een gegeven moment de mail van persoon A toegevoegd bij Persoon B, mails verstuurt en persoon A weer verwijdert.Ook met pop3.hetnet.nl en pop.kpnmail.nl getest, verder als gebruikers naam A en A@hetnet.nl geprobeert.
Het lijkt nu te werken, waarom weet ik niet.
Eens een paar dagen afwachten, ik heb enkel veel meel vanuit mijn hotmail adres naar kpn gestuurd. Die bleef eerst hangen, nu komt die mail binnen, Kijken wat andere mails gaan doen.
Mail poppen vanuit KPN verbinding is problematisch. Omdat ik mijn eigen NAS ook nog had ingesteld gisteren op mail poppen bij mijn zus, zijn alle mails die ik als testmail gebruikt heb feilloos binnen gekomen bij mezelf. Het lijkt erop dan van buiten KPN mail poppen wel goed (ofwel beter) gaat.
Wim
-
Ik heb een tijdelijke oplossing gevonden.
Oorzaak is toch echt bij KPN.
Nadat ik log van fetchmail heb aangezet kreeg ik volgende messages in log :
fetchmail: starting fetchmail 6.3.17 daemon
fetchmail: 1 message for xxxxxxxx@kpnmail.nl at pop.kpnmail.nl (2321 octets).
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:1 not flushed
fetchmail: 2 messages (2 seen) for xxxxxxxx@kpnmail.nl at pop.kpnmail.nl (5766 octets).
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:1 not flushed
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:2 not flushed
De 2e message heb ik naar mijn account gestuurd na de eerste pol van fetchmail. Die kan dus nog niet gezien zijn, terwijl fetchmail wel zegt : (2 seen).
Dit duidt erop dat er iets niet in orde is met de mailbox handling van KPN. Ik heb de mails tenslotte nog niet gezien... Heb de verbose optie van de log nog niet aangezet.
Om probleem op te lossen heb ik optie fetchall in de configuratie voor de fetchmail van de betreffende users gezet.
Dat gaat als volgt
Telnet naar Syn
Login met root
cd /volume1/@appstore/MailStation/roundcubemail/ext
edit <username>_fetch bestand
wijzig poll statement zodat fetchall optie wordt toegvoegd, ziet er dan als volgt uit :
poll "pop.kpnmail.nl" with protocol POP3 and port 110:
user "xxxxxxx@kpnmail.nl" pass "######" is "<username>" here
fetchall
no keep
Save en stop en start mailstation.
Als ik tijd heb ga ik fetchmail verbose log nog aanzetten en kijken wat de exacte commands en responses zijn, maar voorlopig duidt eea. op fout bij KPN in het plaatsen van mij mails in mailbox.
Succes.
-
ter info op mijn vorige mail: vandaag blijven weer mails hangen. Het werkte dus niet.
Wim
-
ter info op mijn vorige mail: vandaag blijven weer mails hangen. Het werkte dus niet.
Wim
Dank voor je reactie dan hoef ik het ook niet te proberen.
Gerard
-
Eindelijk een heldere reactie waarin door KPN wordt bevestigd dat er grote problemen zijn met het vernieuwde email platform http://forum.kpn.com/t5/E-mail/Synology-NAS-kan-mails-niet-ophalen-via-POP-mailserver/m-p/130994/highlight/true#M1880 (http://forum.kpn.com/t5/E-mail/Synology-NAS-kan-mails-niet-ophalen-via-POP-mailserver/m-p/130994/highlight/true#M1880)
-
In het KPN forum wordt deze draad met interesse gevolgd door KPN medewerkes, dus mocht je nog meer info hebben RobRoos dan plaats maar.
gr Wim
-
Helemaal mee eens. Alle aanvullende informatie kan helpen. Ik krijg het gevoel dat na 2 maanden KPN eindelijk serieus naar het probleem kijkt.
Bij mij heeft de derde lijn vorige week naar de emailstructuur gekeken en tests uitgevoerd. Helaas zonder resultaat en met als gevolg dat een alias niet meer kan worden uit- of aangezet en een alias dubbel in het systeem staat. Er wordt aan gewerkt.
Het blijkt echter dat de relayserver van KPN op dit moment ook niet goed werkt. imap berichten verzonden naar mijn server komen niet altijd aan. Verzender ontvangt hiervan ook geen bericht. :o
-
probleem helaas nog steeds niet opgelost. Kpn is nog steeds op zoek naar oorzaak. Zelfs is een alias zoekgeraakt.
Mijn work around van email/forward naar eigen domein werkt ook niet altijd goed.
instellingen zijn:
mijndomein.nl MX 10 smtp.mijndomein.nl
mijndomein.nl MX 20 mailrelay.direct-adsl.nl
smtp.mijndomein.nl A ip adres extern.
poort 25 in 26 wijzigen had ook geen effect.
mailberichten vanuit kpn omgeving komen wel binnen van daarbuiten niet.
Bericht is dan bij verzender:
The error that the other server returned was:
550 5.7.1 Unable to relay.
Iemand een idee of suggestie?
-
Inmiddels tijd gehad om verbose logging aan te zetten.
Eerste poging, standaard Synology settings :
fetchmail: starting fetchmail 6.3.17 daemon
fetchmail: 6.3.17 querying pop.kpnmail.nl (protocol POP3) at Tue Sep 17 20:24:53 2013: poll started
fetchmail: Trying to connect to 213.75.3.100/110...connected.
fetchmail: POP3< +OK POP3 PROXY server ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< RESP-CODES
fetchmail: POP3< USER
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< .
fetchmail: pop.kpnmail.nl: opportunistic upgrade to TLS failed, trying to continue.
fetchmail: POP3> USER xxxxxxxx@kpnmail.nl
fetchmail: POP3< +OK Password required
fetchmail: POP3> PASS *
fetchmail: POP3< +OK 3 messages
fetchmail: POP3> STAT
fetchmail: POP3< +OK 3 80649
fetchmail: POP3> LAST
fetchmail: POP3< +OK 3
fetchmail: 3 messages (3 seen) for roosnas2@kpnmail.nl at pop.kpnmail.nl (80649 octets).
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:1 not flushed
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:2 not flushed
fetchmail: skipping message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:3 not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK POP3 server closing connection
fetchmail: 6.3.17 querying pop.kpnmail.nl (protocol POP3) at Tue Sep 17 20:24:53 2013: poll completed
Wat hier opvalt is dat fetchmail GEEN gebruik maakt van UIDL, terwijl dat standaard zou moeten zijn.
Ook blijkt dat het LAST command de waarde 3 retourneert, hetgeen fout is. De last seen value zou 1 moeten zijn. Hierdoor worden er geen messages gedownload.
Ik weet nog niet zeker, maar dat er een combinatie fout is. Fetchmail 6.3.17 is al verouderd, er is een veel nieuwere versie 6.3.26. In principe zou fetchmail gebruik moeten maken van UIDL aangezien de server dit ook als capability teruggeeft.
Hierna heb ik fetchmail config aangepast een UIDL geforceerd. V output van fetchmail :
This is fetchmail release 6.3.17+SSL+NLS.
Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2006, 2010 Sunil Shetye
Copyright (C) 2005 - 2010 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
Fallback MDA: (none)
Linux RoosNas1 2.6.32.12 #3776 SMP Fri Sep 6 17:19:50 CST 2013 ppc GNU/Linux synology_qoriq_413
Taking options from command line and /var/packages/MailStation/target/roundcubemail/ext/<user>_fetch
Poll interval is 300 seconds
Logfile is /var/services/homes/<user>/.Maildir/fetchmail.log
Idfile is /var/services/homes/<user>/.fetchids
Fetchmail will forward misaddressed multidrop messages to <user>.
Fetchmail will direct error mail to the sender.
Fetchmail will treat permanent errors as temporary (keep messages).
Options for retrieving from xxxxxxx@kpnmail.nl@pop.kpnmail.nl:
True name of server is pop.kpnmail.nl.
This host will be queried when no host is specified.
Password = "*********".
Protocol is POP3 (using service 110) (forcing UIDL use).
All available authentication methods will be tried.
Server nonresponse timeout is 300 seconds (default).
Default mailbox selected.
Only new messages will be retrieved (--all off).
Fetched messages will not be kept on the server (--keep off).
Old messages will not be flushed before message retrieval (--flush off).
Oversized messages will not be flushed before message retrieval (--limitflush off).
Rewrite of server-local addresses is enabled (--norewrite off).
Carriage-return stripping is enabled (stripcr on).
Carriage-return forcing is disabled (forcecr off).
Interpretation of Content-Transfer-Encoding is enabled (pass8bits off).
MIME decoding is disabled (mimedecode off).
Idle after poll is disabled (idle off).
Nonempty Status lines will be kept (dropstatus off)
Delivered-To lines will be kept (dropdelivered off)
No received-message limit (--fetchlimit 0).
Fetch message size limit is 100 (--fetchsizelimit 100).
Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
No SMTP message batch limit (--batchlimit 0).
No forced expunges (--expunge 0).
Messages will be delivered with "/var/packages/MailStation/target/bin/procmail -m '/var/packages/MailStation/target/roundcubemail/ext/<user>.
proc.xxxxxxxx.kpnmail.nl'".
Spam-blocking disabled
No pre-connection command.
No post-connection command.
Single-drop mode: 1 local name recognized.
<user>
No interface requirement specified.
No monitor interface specified.
No plugin command specified.
No plugout command specified.
No UIDs saved from this host.
No poll trace information will be added to the Received header.
Messages with bad headers will be rejected.
De log als gevolg van UIDL forceren :
fetchmail: starting fetchmail 6.3.17 daemon
fetchmail: 6.3.17 querying pop.kpnmail.nl (protocol POP3) at Tue Sep 17 20:36:56 2013: poll started
fetchmail: Trying to connect to 213.75.3.100/110...connected.
fetchmail: POP3< +OK POP3 PROXY server ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< RESP-CODES
fetchmail: POP3< USER
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< .
fetchmail: pop.kpnmail.nl: opportunistic upgrade to TLS failed, trying to continue.
fetchmail: POP3> USER xxxxxxxx@kpnmail.nl
fetchmail: POP3< +OK Password required
fetchmail: POP3> PASS *
fetchmail: POP3< +OK 3 messages
fetchmail: POP3> STAT
fetchmail: POP3< +OK 3 80649
fetchmail: POP3> UIDL
fetchmail: POP3< +OK
fetchmail: POP3< 1 581
fetchmail: POP3< 2 583
fetchmail: POP3< 3 585
fetchmail: POP3< .
fetchmail: 3 messages for xxxxxxxx@kpnmail.nl at pop.kpnmail.nl (80649 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 70910
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 70910 bytes
fetchmail: reading message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:1 of 3 (70910 octets) flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK message marked for deletion
fetchmail: POP3> LIST 2
fetchmail: POP3< +OK 2 2776
fetchmail: POP3> RETR 2
fetchmail: POP3< +OK 2776 bytes
fetchmail: reading message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:2 of 3 (2776 octets) flushed
fetchmail: POP3> DELE 2
fetchmail: POP3< +OK message marked for deletion
fetchmail: POP3> LIST 3
fetchmail: POP3< +OK 3 6963
fetchmail: POP3> RETR 3
fetchmail: POP3< +OK 6963 bytes
fetchmail: reading message xxxxxxxx@kpnmail.nl@pop.kpnmail.nl:3 of 3 (6963 octets) flushed
fetchmail: POP3> DELE 3
fetchmail: POP3< +OK message marked for deletion
fetchmail: POP3> QUIT
fetchmail: POP3< +OK POP3 server closing connection
fetchmail: 6.3.17 querying pop.kpnmail.nl (protocol POP3) at Tue Sep 17 20:36:57 2013: poll completed
Tenslotte , ten aanzien van niet gebruiken van UIDL door fetchmail, maar het LAST command het volgende :
This is a prehistoric feature, and I think it's a bad idea to include it.
(It was in RFC1460, removed in RFC1725 *eight* years ago, and the current
POP3 spec is RFC1939)
All mail clients should be able to use UIDL to detect new mail; LAST was
removed because it's conceptually broken (i.e. it assumes that conceptually
your mailbox consists of N read mails followed by M unread mails, which
often is not the case in real life)
Ik ga nog verder proberen uit te zoeken waarom fetchmail UIDL niet gebruikt in de default setting, maar daarvoor moet ik weer eea. opzetten en extra verbose logging aanzetten. Had ik nu geen tijd voor.
Voorlopig adviseer ik jullie om deze tip toe te passen :
Om probleem op te lossen heb ik optie fetchall in de configuratie voor de fetchmail van de betreffende users gezet.
wijzig poll statement zodat fetchall optie wordt toegvoegd, ziet er dan als volgt uit :
poll "pop.kpnmail.nl" with protocol POP3 and port 110:
user "xxxxxxx@kpnmail.nl" pass "######" is "<username>" here
fetchall
no keep
-
@robroos57
Als er al sprake zou zijn van een structurele fout waarom is bij mij het probleem van binnenhalen pop3 berichten bij 2mailboxen opgelost na uitzetten en reactiveren van aliassen op mailserver kpn?
Bij de andere mailboxen (nog) niet. Onderzoek KPN loopt nog
-
Wellicht een domme vraag, maar ik stel ze toch.
Kunnen we dan niet upgraden naar fetchmail 6.3.26?
Ik gebruik op de PC thunderbird laatste versie en die werkt ook met KPN, dus...
Wim
-
Zijn er nog diagnostische ontwikkelingen geweest of is de enige oplossing "fetchall" toe te voegen?
gr Wim
-
onderzoek/discussie met KPN loopt nog. Kwestie van geduld. Hoe lang nog?
Het blijft vreemd dat een aantal emails wel worden doorgezonden en andere weer niet. Soms kan het bericht van dezelfde afzender komen. Ik gebruik nog steeds telnet voor reset mailbox :(
-
Ik heb intussen de "fetchall" opdracht toegevoegd
elke dag resetten..............pff.
het probleem is niet aanwezig bij het eerste primaire email adres, wel alle andere adressen die ik heb aangemaakt. Dat zijn losse mailboxen, geen alias van dezelfde mailbox dus.
gr WIm
-
Leg mij even uit hoe ik fetchall kan gebruiken
-
Zie de posts van ROBROOS57 hierboven.
Je moet met bv putty contact maken en daarna via UNIX/LINUX (? weet nooit wat) de directorys doorlopen, de juiste file openen en die editen volgens zijn aanwijzingen.
Ben je hiermee niet vertrouwd, DOE HET DAN NIET, je kun t veel omzeep helpen.
Ik heb eerste een copy gemaakt van de bewuste files zodat ik altijd terug kan mocht er iets fout lopen. de editor is VI dus als je daarmee niet echt vertrouwd bent... is het lastig, erg lastig.
Het werkt wel.
gr Wim
-
KPN kan de oorzaak waarom berichten soms niet lokaal worden afgeleverd niet vinden.
Het uit- en aanzetten van aliassen biedt soms uitkomst. Bij mij bij 3 van de vier mailboxen.
Voor zover dat niet lukt kan TELNET gebruikt worden zoals eerder aangegeven. Om dit vervelende handmatige klusje te vermijden gebruik ik inmiddels de oplossing met FETCHALL zoals door ROBROOS57 is aangegeven.
Het blijft vanzelfsprekend onbevredigend dat KPN niet oplost wat door hen zelf is veroorzaakt.
Voor wat mij betreft mag er een slotje op dit onderwerp!
-
Nou, wat mij betreft niet hoor :o
Aangezien robroos57 half september meldde dat dit probleem veroorzaakt wordt door een verouderde versie van fetchmail (die standaard geen UIDL benut, ondanks dat de server van KPN correct meldt dat UIDL gebruikt dient te worden), lijkt het me een slotje op dit onderwerp verre van aan de orde...!
Daarenboven is dit mijns inziens dus ook niet iets wat KPN zich zou moeten aantrekken; hun mailserver reageert immers correct.
Ik heb Synology ongeveer een maand geleden al via het support-formulier gevraagd of er zicht is op het upgraden van fetchall (en RoundCube), maar daar kreeg ik een standaard "we zullen ernaar kijken, maar eigenlijk zeggen we hier helemaal niets mee" antwoord op. Toen ik daarop reageerde met de vraag of, en zo ja wanneer, ik daadwerkelijk actie kon verwachten, kreeg ik geen antwoord meer :x
Misschien is het een idee als iedereen die deze problemen ondervindt er eens een berichtje richting Synology aan waagt? Misschien worden ze dán wakker? :|
-
Nou, wat mij betreft niet hoor :o
Aangezien robroos57 half september meldde dat dit probleem veroorzaakt wordt door een verouderde versie van fetchmail (die standaard geen UIDL benut, ondanks dat de server van KPN correct meldt dat UIDL gebruikt dient te worden), lijkt het me een slotje op dit onderwerp verre van aan de orde...!
Daarenboven is dit mijns inziens dus ook niet iets wat KPN zich zou moeten aantrekken; hun mailserver reageert immers correct.
Ik heb Synology ongeveer een maand geleden al via het support-formulier gevraagd of er zicht is op het upgraden van fetchall (en RoundCube), maar daar kreeg ik een standaard "we zullen ernaar kijken, maar eigenlijk zeggen we hier helemaal niets mee" antwoord op. Toen ik daarop reageerde met de vraag of, en zo ja wanneer, ik daadwerkelijk actie kon verwachten, kreeg ik geen antwoord meer :x
Misschien is het een idee als iedereen die deze problemen ondervindt er eens een berichtje richting Synology aan waagt? Misschien worden ze dán wakker? :|
IK deel je opvatting niet!
De oorzaak van het probleem ligt bij KPN door de wijziging/vernieuwing mailservers KPN en nergens anders. Dit is door KPN erkend! Lees alle berichten in dit topic eens goed alvorens ongenuanceerd te stellen dat de mailservers van KPN correct reageren.
Dat door middel van een work around (FETCHALL) een oplossing wordt gevonden zegt niets over de oorzaak.
-
Uiteraard heb ik het complete topic gelezen; hieruit blijkt absoluut niet eenduidig dat een fout bij KPN de oorzaak van dit specifieke probleem is, laat staan dat men dit erkent. Ze hebben enorm veel tegenslag gehad bij de upgrade van het mailplatform (o.a. met aliassen), maar dit valt daar niet onder!
Want nu men na maanden eindelijk alle narigheid heeft opgelost, en iedereen met willekeurige POP-clients (persoonlijk getest met Windows Mail, Outlook, Apple Mail, Thunderbird, Android- en iOS-telefoons, om maar wat te noemen) weer vrolijk de juiste mails ophaalt, blijkt het bij gebruik van een Synology nog niet te werken zoals het hoort... ::)
Dus nogmaals: mijns inziens blijkt uit de laatste post van robroos57 (onderbouwd en wel) toch tamelijk duidelijk wat de oorzaak is: de fetchmail-versie die Synology meelevert is zó oud dat deze niet meer snapt wat de gemoderniseerde KPN-servers bedoelen.
Ik vraag me dus af op basis waarvan jij ongenuanceerd stelt dat dit wél aan KPN ligt?
Overigens hoef je, als je op het laatste bericht in een topic reageert, niet per sé dat complete bericht te quoten, maar dat terzijde ;)