Email notificatie werkt niet meer. Maar de testmail komt wel aan.

[Basalt]

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)
Maar nog niet gelukt, ga ik binnenkort mee verder...

[Basalt]

Het komt er op neer om het volgende aan de main.cf file toe te voegen:

Code: [Selecteer]

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

Zal ik ook eens naar kijken, ook al helpt het niet 

[Briolet]

Via de termina kun je het certificaat van de ziggo mailserver opvragen met "openssl s_client -starttls smtp -connect smtp.ziggo.nl:587":

Code: [Selecteer]

:~$ 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:

Code: [Selecteer]

…
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?

[Basalt]

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)

Code: [Selecteer]

smtp_tls_CApath = /etc/ssl/certs/
En zie nu in  /volume1/@maillog/maillog

Code: [Selecteer]

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!

[Basalt]

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 .
- 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):

Code: [Selecteer]

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?

[Briolet]

- De "CONNECTED(00000003)" krijg ik direct, de rest komt meestal pas na 10...30 seconden .

Hier is het altijd instantaan.

Gaat het bij een andere mailserver wel vlot? b.v:

Code: [Selecteer]

openssl s_client -starttls smtp -connect smtp.gmail.com:587 -debug

[Basalt]

Naar gmail gaat het wel aldoor super snel en goed (naar Ziggo nog steeds traag en meestal fout)

[Basalt]

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.

[Briolet]

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.

[Basalt]

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:

Code: [Selecteer]

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?

[Basalt]

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 

[Basalt]

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

[Basalt]

...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 

[Briolet]

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.