Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: Stefonline op 12 december 2019, 12:18:10
-
Hallo allen,
Uit het niets komen er geen email meldingen meer binnen. Dit heeft altijd goed gewerkt. Als ik bij meldingen en test mail verstuur komt die gewoon aan. Maar meldingen betreft het systeem komen niet aan.
Ik gebruik geen Gmail maar gewoon de smtp instellingen van mijn mail provider.
Wie heeft hier ook ervaring mee?
Stefan
-
Sinds 1 december heb ik ook regelmatig dat een van de backup e-mails niet aankomt.
In /var/log/messages staat dan:
Dec 12 05:49:41 Basalt synolocalbkp: smtp.c (161) Timeout while reading server reply.
Dec 12 05:49:41 Basalt synolocalbkp: smtp.c (406) Failed to write smtp command.
Dec 12 05:49:41 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Deze e-mails gaan rechtstreeks naar de smtp van Ziggo (niet via relay op de nas).
Ik vermoed dat daar iets niet helemaal lekker zit.
@Stefonline : zit jij ook bij Ziggo?
-
@Basalt ja ik heb ook Ziggo en maak ook rechtstreeks gebruik van de SMTP
Ik ben dus niet de enige
-
Op een ziggo forum zag ik gisteren wel een melding die beweerd dan een ziggo medewerker had beweerd dat er momenteel problemen zijn met smtp. (Dan is inmiddels uit 3e hand)
Welke smpt server gebruik je? smtp.ziggo.nl? Ik gebruik die voor al mijn mail en heb tot nu toe geen probleem ervaren.
-
Terwijl ik er over nadenk, bedenk ik me nu dat ik het verkeerd uitleg aan jullie. Maar het probleem blijft hetzelfde.
Mijn Provider is Ziggo dus ik ging ervan uit dat ik ook mail verstuur via ziggo maar dat is helemaal niet zo. Ik heb ivm eigen domein een andere mail provider nl mijndomein.nl. Dus dat was verkeerde info waarvoor sorry.
Neemt niet weg dat het probleem hetzelfde is. Test mail komt wel aan en b.v. backup mailtjes niet.
Mogelijke oplossing zou kunnen zijn om wel via ziggo te gaan versturen.
Sorry voor de verwarring.
Stefan
-
Bedenk ook dat er twee soorten mail zijn binnen dsm. Beide moet je apart instellen.
-
ik ken alleen de instellingen bij configuratie > melding. Welke mis ik dan?
-
Die bij je account instellingen rechtsboven. Maar de backup meldingen lopen via de instellingen die jij kent, dus dat is het niet.
-
@2Briolet grote kans dat dat het was. Ik laat het weten.
Dank allemaal
-
Bij mij gaat het alleen maar slechter. Laatste 4 dagen is geen van de 2 backup e-mails verzonden.
Ook het testbericht versturen ging eerst 3x fout, pas de 4e keer lukte het.
Foutmelding was bij die drie keer telkens:
Het verzenden van het testbericht is mislukt. Controleer uw instellingen en probeer het opnieuw.
Timeout while reading server reply
En in /var/log/messages:
Dec 19 21:39:10 Basalt entry.cgi_SYNO.Core.Notification.Mail[1].send_test[11580]: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dit zijn mijn instellingen bij "Melding"
[attachimg=1]:
-
Oh, wow, ik heb een generiek probleem met het verzenden van e-mails :o
Tussen 22:05 en 22:06 heb ik vijf test mails (Test 1...5) naar mezelf verzonden met mijn e-mail client.
Resultaat:
Test 1: ontvangen om 22:13
Test 2: ontvangen om 22:06
Test 3: nog steeds niet ontvangen!
Test 4: ontvangen om 22:23
Test 5: ontvangen om 22:07
Rond 22:13 in de Wachtrij van Mailserver gekeken, daar stonden nog 2 e-mails (inmiddels nog maar 1 dus):
[attachimg=1]
Vervolgens ook gekeken in /volume1/@maillog/maillog (het ">>>>" commentaar heb ik uiteraard toegevoegd)
Dec 19 22:12:44 Basalt postfix/qmgr[8763]: 32CA89304022: from=<MIJN_EMAIL_ADRES>, size=1613, nrcpt=1 (queue active)
Dec 19 22:12:58 Basalt postfix/smtp[17310]: 32CA89304022: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=431, delays=416/0.21/14/0, dsn=4.4.2, status=deferred (lost connection with smtp.ziggo.nl[212.54.42.9] while performing the EHLO handshake)
>>>> Mislukt
Dec 19 22:12:58 Basalt postfix/smtp[17308]: Untrusted TLS connection established to smtp.ziggo.nl[212.54.42.9]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 19 22:12:59 Basalt postfix/smtp[17308]: 839B49304021: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=473, delays=458/0.4/15/0.07, dsn=2.0.0, status=sent (250 OK id=1ii36R-0001CH-1k)
Dec 19 22:12:59 Basalt postfix/qmgr[8763]: 839B49304021: removed
>>>> Gelukt
Dec 19 22:13:03 Basalt postfix/smtp[17309]: D65069304023: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=422, delays=402/0.21/20/0, dsn=4.4.2, status=deferred (lost connection with smtp.ziggo.nl[212.54.42.9] while performing the EHLO handshake)
>>>> Mislukt
Dec 19 22:15:06 Basalt postfix/anvil[15940]: statistics: max connection rate 5/86400s for (587:IP_VAN_MIJN_PC) at Dec 19 22:06:18
Dec 19 22:15:06 Basalt postfix/anvil[15940]: statistics: max connection count 1 for (587:IP_VAN_MIJN_PC) at Dec 19 22:05:06
Dec 19 22:15:06 Basalt postfix/anvil[15940]: statistics: max cache size 1 at Dec 19 22:05:06
Dec 19 22:22:43 Basalt postfix/qmgr[8763]: D65069304023: from=<MIJN_EMAIL_ADRES>, size=1615, nrcpt=1 (queue active)
Dec 19 22:22:43 Basalt postfix/qmgr[8763]: 32CA89304022: from=<MIJN_EMAIL_ADRES>, size=1613, nrcpt=1 (queue active)
Dec 19 22:23:07 Basalt postfix/smtp[19068]: Untrusted TLS connection established to smtp.ziggo.nl[212.54.42.9]:587: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 19 22:23:07 Basalt postfix/smtp[19068]: D65069304023: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=1025, delays=1001/0.08/24/0.07, dsn=2.0.0, status=sent (250 OK id=1ii3GF-0008Qb-99)
Dec 19 22:23:07 Basalt postfix/qmgr[8763]: D65069304023: removed
>>>> Gelukt
Dec 19 22:23:07 Basalt postfix/smtp[19069]: 32CA89304022: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=1039, delays=1015/0.08/24/0, dsn=4.4.2, status=deferred (lost connection with smtp.ziggo.nl[212.54.42.9] while performing the EHLO handshake)
>>>> Mislukt
Vreemd genoeg gaat het met een "Untrusted TLS connection" wel goed.
Wie weet wat hier aan de hand is?
-
@BasaIt, ik zie dat je ook mailserver gebruikt. Waarom zendt je de meldingen naar Ziggo en houdt ze niet op de nas?
Verder zijn jouw instellingen identiek als bij mijn voor de relayserver van Mail Server naar ziggo.
Ik zie alleen niet waarom hij bij jou dan 'untrusted' is. Ik krijg altijd 'trusted' bij Ziggo met dezelfde cipher:
2019-12-19T16:00:14+01:00 postfix/smtp[6655]: Trusted TLS connection established to smtp.ziggo.nl[212.54.42.9]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2019-12-19T16:00:14+01:00 postfix/smtp[6655]: 4E4671234D2: to=<xxx@domein.com>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=7.8, delays=7.2/0.17/0.29/0.15, dsn=2.0.0, status=sent (250 OK id=1ihxHi-0001HF-T7)
Maar dit staat los van TS. Als er bij de testmails geen probleem is, zal het daar niet in de verbinding met de provider zitten.
-
Nog even verder teruggekeken in de maillog, die loopt vanaf 13 mei: ik heb kennelijk altijd al een "Untrusted TLS connection" ?!
Ik draai DSM 5.2, misschien dat de Mailserver daarom wat anders reageert?
De meldingen verstuur ik trouwens rechtstreeks naar Ziggo omdat ik tijdens hibernation enkele mail processen uitgeschakeld heb (mbv "Mail Relaxer").
Maar zowel rechtstreeks als via Mailserver gaat het versturen dus regelmatig fout, volgens de maillog vanwege "lost connection with smtp.ziggo.nl[212.54.42.9] while performing the EHLO handshake"
Dat kwam vroeger sporadisch voor (1x op 24 September), sinds December regelmatig, zie grep op /var/log/messages:
Basalt> cat messages|grep mail_smtp_error_call_back.c
Jan 1 01:01:58 Basalt synonotify: mail_smtp_error_call_back.c (29) Failed to send email. (Failed to resolve host address.)
Jan 1 01:04:23 Basalt syno_disk_health_record: mail_smtp_error_call_back.c (29) Failed to send email. (Failed to resolve host address.)
Jan 9 09:42:49 Basalt synonotify: mail_smtp_error_call_back.c (29) Failed to send email. (Failed to resolve host address.)
Jan 9 09:42:53 Basalt synonotify: mail_smtp_error_call_back.c (29) Failed to send email. (Failed to resolve host address.)
Jan 9 22:30:34 Basalt synonotify: mail_smtp_error_call_back.c (29) Failed to send email. (Failed to resolve host address.)
Sep 24 06:00:27 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 1 05:46:19 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 1 07:23:55 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 2 05:48:35 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 5 05:50:09 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 8 07:24:07 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 9 05:48:02 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 9 07:24:39 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 10 07:10:22 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 11 07:05:53 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 12 05:49:41 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 12 07:11:24 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 13 07:13:55 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 15 07:16:25 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 16 05:57:48 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 16 07:22:24 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 17 05:44:06 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 17 07:21:54 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 18 05:46:37 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 18 07:22:35 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 19 05:44:13 Basalt synolocalbkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 19 07:21:02 Basalt timebkp: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 19 21:39:10 Basalt entry.cgi_SYNO.Core.Notification.Mail[1].send_test[11580]: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 19 21:39:45 Basalt entry.cgi_SYNO.Core.Notification.Mail[1].send_test[11666]: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
Dec 19 21:40:05 Basalt entry.cgi_SYNO.Core.Notification.Mail[1].send_test[11750]: mail_smtp_error_call_back.c (29) Failed to send email. (Timeout while reading server reply)
De "Test 3" mail is nu ook net binnengekomen (om 00:33), uiteindelijk lukt het verzenden dus wel...
-
Heb je soms ook wel eens problemen met het versturen van E-mail, naar provider Ziggo, buiten DSM om ?
-
Ik heb even naar dat 'Untrusted' gekeken. Zelf zie ik alleen "Trusted" en "anonymous". (Dat laatste ligt blijkbaar aan de gebruikte ciphers )
Het untrusted ligt er blijkbaar aan dat hij het certificaat niet kan valideren. Of de gebruikte domeinnaam staat niet in het certificaat, of hij weet niet waar de root certificaten staan. (Zie b.v. hier (https://serverfault.com/questions/858311/postfix-untrusted-tls-connection))
Het komt er op neer om het volgende aan de main.cf file toe te voegen:
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs
Bij mij staat er alleen
smtp_tls_CApath = /etc/ssl/certs/
Dat is bij mij blijkbaar voldoende. Het kan ook zijn dat in dsm 5.2 een bepaald root certificaat mist.
Echter, dit zal niets met de problemen te maken hebben.
-
Heb je soms ook wel eens problemen met het versturen van E-mail, naar provider Ziggo, buiten DSM om ?
Al mijn mail gaat via de NAS, dus: Nee.
Gisterenavond al wel even wat geëxperimenteerd met telnetten naar de SMTP van Ziggo, op basis van een melding van een ander smtp probleem (blocked?) dat ik op de Ziggo site zag (https://community.ziggo.nl/e-mail-103/smtp-geblocked-synolgy-nas-48098 (https://community.ziggo.nl/e-mail-103/smtp-geblocked-synolgy-nas-48098))
Maar nog niet gelukt, ga ik binnenkort mee verder...
-
Het komt er op neer om het volgende aan de main.cf file toe te voegen:
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs
Zal ik ook eens naar kijken, ook al helpt het niet ;D
-
Via de termina kun je het certificaat van de ziggo mailserver opvragen met "openssl s_client -starttls smtp -connect smtp.ziggo.nl:587":
:~$ openssl s_client -starttls smtp -connect smtp.ziggo.nl:587
CONNECTED(00000003)
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
verify return:1
depth=1 C = BM, O = QuoVadis Limited, CN = QuoVadis Global SSL ICA G2
verify return:1
depth=0 C = NL, ST = Utrecht, L = Utrecht, O = Ziggo Services B.V., OU = Global Security, CN = smtp.ziggo.nl
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Utrecht/L=Utrecht/O=Ziggo Services B.V./OU=Global Security/CN=smtp.ziggo.nl
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Global SSL ICA G2
1 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Global SSL ICA G2
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
2 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
Hij staat inderdaad op naam van "CN = smtp.ziggo.nl", en is uitgegeven door het intermediate certificaat van "QuoVadis Global SSL ICA G2". Deze wederom is uitgegeven door het root-certificaat "QuoVadis Root CA 2".
En als je dan in je "/etc/ssl/certs" folder kijkt, heb ik daar staan:
…
PSCProcert.pem
QuoVadis_Root_CA_1_G3.pem
QuoVadis_Root_CA_2_G3.pem
QuoVadis_Root_CA_2.pem
QuoVadis_Root_CA_3_G3.pem
QuoVadis_Root_CA_3.pem
QuoVadis_Root_CA.pem
Root_CA_Generalitat_Valenciana.pem
…
QuoVadis_Root_CA_2 staat er bij bij dus tussen. In dsm 5.2 misschien niet?
-
Het goede nieuws:
Op aangeven van Briolet heb de volgende regel toegevoegd aan /var/packages/MailServer/target/etc/main.cf
(dat stond er nog niet in)
smtp_tls_CApath = /etc/ssl/certs/
En zie nu in /volume1/@maillog/maillog
Dec 20 22:17:29 Basalt postfix/smtp[19659]: Trusted TLS connection established to smtp.ziggo.nl[212.54.42.9]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 20 22:17:29 Basalt postfix/smtp[19659]: 275669304021: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=2345, delays=2342/0.08/3/0.07, dsn=2.0.0, status=sent (250 OK id=1iiPeL-0002xW-Nk)
Dec 20 22:17:29 Basalt postfix/qmgr[13102]: 275669304021: removed
Er staat nu "Trusted", dat werkt dus!
-
Het minder goede nieuws:
Zoals verwacht heeft dit niets geholpen voor de verzendproblemen.
Ik heb met het openssl commando geëxpirimenteerd en zie het daar in de meeste gevallen al fout gaan met het opzetten van de verbinding:
- De "CONNECTED(00000003)" krijg ik direct, de rest komt meestal pas na 10...30 seconden :wtf:.
- En in de meeste gevallen reageert Ziggo niet meer nadat openssl er "EHLO openssl.client" naartoe gestuurd heeft
Zie onderstaande log met debug optie aan (de hele bups komt vanzelf na het openssl commando in de shell):
Basalt> openssl s_client -starttls smtp -connect smtp.ziggo.nl:587 -debug
CONNECTED(00000003)
read from 0x80da8f8 [0x80da9b0] (4096 bytes => 297 (0x129))
0000 - 32 32 30 2d 73 6d 74 70-37 2e 74 62 2e 6d 61 69 220-smtp7.tb.mai
0010 - 6c 2e 69 73 73 2e 61 73-39 31 34 33 2e 6e 65 74 l.iss.as9143.net
0020 - 20 45 53 4d 54 50 20 46-72 69 2c 20 32 30 20 44 ESMTP Fri, 20 D
0030 - 65 63 20 32 30 31 39 20-32 32 3a 31 36 3a 30 37 ec 2019 22:16:07
0040 - 20 2b 30 31 30 30 0d 0a-32 32 30 2d 53 65 6e 64 +0100..220-Send
0050 - 69 6e 67 20 73 70 61 6d-20 6f 72 20 75 6e 73 6f ing spam or unso
0060 - 6c 69 63 69 74 65 64 20-63 6f 6d 6d 65 72 63 69 licited commerci
0070 - 61 6c 20 65 2d 6d 61 69-6c 20 74 6f 20 74 68 69 al e-mail to thi
0080 - 73 20 73 65 72 76 65 72-20 69 73 20 73 74 72 69 s server is stri
0090 - 63 74 6c 79 0d 0a 32 32-30 2d 70 72 6f 68 69 62 ctly..220-prohib
00a0 - 69 74 65 64 20 62 79 20-6f 75 72 20 4e 4f 20 55 ited by our NO U
00b0 - 42 45 20 2f 20 4e 4f 20-55 43 45 20 70 6f 6c 69 BE / NO UCE poli
00c0 - 63 79 2e 20 41 62 75 73-65 20 77 69 6c 6c 20 62 cy. Abuse will b
00d0 - 65 20 70 72 6f 73 65 63-75 74 65 64 20 61 6e 64 e prosecuted and
00e0 - 2f 6f 72 0d 0a 32 32 30-20 63 68 61 72 67 65 64 /or..220 charged
00f0 - 20 70 65 72 20 61 74 74-65 6d 70 74 65 64 20 72 per attempted r
0100 - 65 63 69 70 69 65 6e 74-20 61 74 20 69 6e 74 65 ecipient at inte
0110 - 72 6e 61 74 69 6f 6e 61-6c 20 70 6f 73 74 61 6c rnational postal
0120 - 20 72 61 74 65 73 2e 0d-0a rates...
write to 0x80da8f8 [0x80db9b8] (25 bytes => 25 (0x19))
0000 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69 EHLO openssl.cli
0010 - 65 6e 74 2e 6e 65 74 0d-0a ent.net..
read from 0x80da8f8 [0x80da9b0] (4096 bytes => -1 (0xFFFFFFFF))
didn't found starttls in server response, try anyway...
write to 0x80da8f8 [-0x778164] (10 bytes => -1 (0xFFFFFFFF))
read from 0x80da8f8 [0x80d42a8] (8192 bytes => 0 (0x0))
write to 0x80da8f8 [0x80da940] (291 bytes => -1 (0xFFFFFFFF))
write:errno=32
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 297 bytes and written 25 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1576876567
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Command exited with non-zero status 1
Soms gaat het wel goed, en kan ik na inloggen met deze command line interface ook een e-mail verzenden.
Ik heb hetzelfde ook op een Raspberry Pi geprobeerd met dezelfde resultaten.
Dit lijkt me een Ziggo probleem te zijn, maar ben ik dan de enige die daar last van heeft?
-
- De "CONNECTED(00000003)" krijg ik direct, de rest komt meestal pas na 10...30 seconden :wtf:.
Hier is het altijd instantaan.
Gaat het bij een andere mailserver wel vlot? b.v:
openssl s_client -starttls smtp -connect smtp.gmail.com:587 -debug
-
Naar gmail gaat het wel aldoor super snel en goed (naar Ziggo nog steeds traag en meestal fout)
-
Heb je soms ook wel eens problemen met het versturen van E-mail, naar provider Ziggo, buiten DSM om ?
Ik heb nu Windows Mail ingesteld met IMAP/SMTP naar Ziggo.
Als ik daarmee een e-mail verstuur dan blijft die enkele minuten in Postvak Uit hangen, maar wordt vervolgens wel netjes verstuurd.
Die paar minuten vertraging is geen drama natuurlijk, maar het geeft wel aan dat er een probleem is.
Misschien probeert Mail het wat sneller achter elkaar dan mijn NAS, waarbij het tot enkele uren kan duren voordat het lukt.
-
Blijft toch vreemd want ik zie nooit problemen op dat IP adres. (En vrijwel al mijn uitgaande mail loopt daarlangs) Maar het kan zijn dat dit IP naar verschillende hardware wijst, naargelang de locatie van oorsprong.
-
Nog even terug naar het vorige voorbeeld waarbij de e-mail uiteindelijk verstuurd werd, nu is de maillog gefilterd op alle logging die op dat ene bericht van toepassing is:
Basalt> cat maillog |grep 839B49304021
Dec 19 22:05:06 Basalt postfix/smtpd[15936]: 839B49304021: client=NAAM_VAN_MIJN_PC[IP_VAN_MIJN_PC], sasl_method=PLAIN, sasl_username=MAIL_NAAM
Dec 19 22:05:06 Basalt postfix/cleanup[15944]: 839B49304021: message-id=<em12b3f503-e888-4e81-9ca4-7758a557c776@carbon-1>
Dec 19 22:05:06 Basalt postfix/qmgr[8763]: 839B49304021: from=<MIJN_EMAIL_ADRES>, size=1615, nrcpt=1 (queue active)
Dec 19 22:05:33 Basalt postfix/smtp[15953]: 839B49304021: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=27, delays=0.24/0.16/26/0, dsn=4.4.2, status=deferred (lost connection with smtp.ziggo.nl[212.54.42.9] while performing the EHLO handshake)
Dec 19 22:12:43 Basalt postfix/qmgr[8763]: 839B49304021: from=<MIJN_EMAIL_ADRES>, size=1615, nrcpt=1 (queue active)
Dec 19 22:12:59 Basalt postfix/smtp[17308]: 839B49304021: to=<MIJN_EMAIL_ADRES>, relay=smtp.ziggo.nl[212.54.42.9]:587, delay=473, delays=458/0.4/15/0.07,
dsn=2.0.0, status=sent (250 OK id=1ii36R-0001CH-1k)
Dec 19 22:12:59 Basalt postfix/qmgr[8763]: 839B49304021: removed
Interessant is "delays=458/0.4/15/0.07" in de op-een-na-laatste regel, dat betekent:
458 = time before queue manager, including message transmission
0.4 = time in queue manager
15 = connection setup including DNS, HELO and TLS;
0.07 = message transmission time.
De eerste poging had delays=0.24/0.16/26/0, waarbij de connection setup dus 26 seconden duurde, maar mislukte.
Ik heb nog wat verder gekeken, maar ook met een langere connection setup van 30 seconden kan het wel goed gaan, het is dus niet een kwestie van een te korte timeout.
Ik denk dat deze connection setup de tijd is tussen CONNECTED(00000003) en de rest van het verhaal.
Bij Briolet (en bij mij via gmail) is dat altijd heel snel.
In de maillog tot op 2 december is bij succes (status=sent) de connection setup altijd onder de 1 seconde.
Vanaf 5 december is het ineens tussen de 10 en 30 seconden (een enkele keer wel onder de 1 seconde).
Alhoewel dat op zich geen probleem hoeft te zijn, lijkt het wel een indicatie dat er ergens (bij Ziggo?) iets mis is.
Hoe zou ik dit het beste kunnen aankaarten bij Ziggo?
-
Nog een leuk weetje: "dsn" in de deferred berichten is de Delivery Status Notification volgens RFC3463.
Ik zie aldoor 4.4.2, dat betekent:
X.4.2 Bad connection
The outbound connection was established, but was unable to complete the message transaction, either because of time-out, or inadequate connection quality. This is useful only as a persistent transient error.
Nou ja, dat wisten we eigenlijk al 8)
-
Ik heb als experiment mijn Raspberry Pi verbonden met de WiFi hotspot van mijn mobieltje, die met 4G op het netwerk van KPN zit.
Nu gaat op de Raspberry Pi de "openssl s_client -starttls smtp -connect smtp.ziggo.nl:587" wel altijd snel en goed.
(bedraad via Ziggo netwerk nog steeds traag en vaak fout).
Dus afhankelijk van mijn internet verbinding (via hotspot en 4G/KPN of bedraad via Ziggo) gaat het wel of niet goed.
Dit lijkt mij toch een Ziggo probleem :wtf:
-
...en het wàs ook een Ziggo probleem.
Deze discussie is voorgezet op een Ziggo forum, er bleken meerdere mensen precies hetzelfde probleem te hebben, en die mensen hadden allemaal een Extern IP adres in een bepaalde range.
En opeens was het vandaag opgelost: e-mails worden weer lekker snel en betrouwbaar verstuurd, en de 10-30 seconden vertraging die ik zag met het openssl tooltje na "CONNECTED(00000003)" is ook helemaal weg. Ik hoop er nog achter te komen wat er nou precies fout zat bij Ziggo, maar begrijp ook wel dat ze hun vuile was liever binnenshuis willen houden.
In ieder geval, @Briolet: nog bedankt voor het meedenken en mee-testen :thumbup:
-
Extern IP adres in een bepaalde range.
Dan was het toch een bepaalde server bij Ziggo. Of een bepaalde route. In elk geval goed dat het nu vlot werkt.