ssl accept error op smtpd van postfix wat is hier nu echt aan de hand

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische informatie
ontvangt van een mail server bij webish.nl. Als deze een email stuurt
naar mijn debian stable uptodate postfix smtpd systeem dan genereert
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
sepaip2.webish.nl[77.243.228.161]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te zorgen
dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert certificaten
en ik maak er mijn persoonlijke trots van om al mij beheerde systemen
altijd zeer netjes en veilig op orden te hebben, dus ik heb er een
beetje de pest is dat op een of andere reden de mail van webish.nl
geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs staan en
mail van andere servers komen allemaal aan. Ook is het sterk dat een
update op mijn beheerde server een probleem geeft gezien de problemen
volgens de gebruikers ongeveer in een tijds periode is geweest dat er
geen enkele update van pakken is geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet, helemaal
uit dus en nu kan de webish.nl server wel verbinding maken, maar dit
is een tijdelijke oplossing en ik ben hier niet blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet wat
er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-webish-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik heb het idee dat de certificaten van webish.nl door hen zelf gemaakt zijn want ik zie er localhost in staan: /C=US/ST=Someprovince/L=Sometown/O=none/OU=none/CN=localhost/emailAddress=***@localhost

Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw server kijkt hier strikt naar en kan e.e.a. niet valideren. Er moet toch minstens serieuze informatie in hun certificaat staan, want localhost daar kan je niks mee natuurlijk. Voor een ICT bedrijf zou dat toch eigenlijk wel een serieus certificaat moeten zijn van een betrouwbare certificeringsinstantie...

--
Mvg,
Arlé

Jelle de Jong

2009-06-17 18:39:08 UTC

Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw server kijkt hier strikt naar en kan e.e.a. niet valideren. Er moet toch minstens serieuze informatie in hun certificaat staan, want localhost daar kan je niks mee natuurlijk. Voor een ICT bedrijf zou dat toch eigenlijk wel een serieus certificaat moeten zijn van een betrouwbare certificeringsinstantie...
--
Mvg,
Arlé

Dank Arlé voor de response. Ik heb inderdaad gezien dat webish een zelf
gemaakt certificaat gebruikt. Dat ze daarin alles op niets zegende
waarden zetten kan ik niets aan doen, maar mijn beheerde server heeft
standaard smtpd_tls_security_level op may staan dus optioneel.

Hiernaast zou er toch geen ssl_accept error moeten komen als er een
selfsigned cert wordt gebruikt?

Ik vind het inderdaad ook wat vreemd dat een hosting bedrijf zulke
vormgeven certificaten gebruikt, maar dat zou in theorie toch moeten
blijven werken?

Met vriendelijke groet,

Jelle de Jong

Arlé Mooldijk

2009-06-17 19:01:06 UTC

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische informatie
ontvangt van een mail server bij webish.nl. Als deze een email
stuurt naar mijn debian stable uptodate postfix smtpd systeem dan
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
sepaip2.webish.nl[77.243.228.161]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te zorgen
dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert
certificaten en ik maak er mijn persoonlijke trots van om al mij
beheerde systemen altijd zeer netjes en veilig op orden te hebben,
dus ik heb er een beetje de pest is dat op een of andere reden de
mail van webish.nl geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs staan
en mail van andere servers komen allemaal aan. Ook is het sterk dat
een update op mijn beheerde server een probleem geeft gezien de
problemen volgens de gebruikers ongeveer in een tijds periode is
geweest dat er geen enkele update van pakken is geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet,
helemaal uit dus en nu kan de webish.nl server wel verbinding
maken, maar dit is een tijdelijke oplossing en ik ben hier niet
blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet wat
er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-webish-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik heb het idee dat de certificaten van webish.nl door hen zelf
Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw
server kijkt hier strikt naar en kan e.e.a. niet valideren. Er moet
toch minstens serieuze informatie in hun certificaat staan, want
localhost daar kan je niks mee natuurlijk. Voor een ICT bedrijf zou
dat toch eigenlijk wel een serieus certificaat moeten zijn van een
betrouwbare certificeringsinstantie...

Dank Arlé voor de response. Ik heb inderdaad gezien dat webish een
zelf gemaakt certificaat gebruikt. Dat ze daarin alles op niets
zegende waarden zetten kan ik niets aan doen, maar mijn beheerde
server heeft standaard smtpd_tls_security_level op may staan dus
optioneel.
Hiernaast zou er toch geen ssl_accept error moeten komen als er een
selfsigned cert wordt gebruikt?
Ik vind het inderdaad ook wat vreemd dat een hosting bedrijf zulke
vormgeven certificaten gebruikt, maar dat zou in theorie toch moeten
blijven werken?

Ik kan me heel goed voorstellen dat Postfix het niet accepteert als er fake certificaten worden gebruikt, want er staat helemaal niets in wat naar die server wijst.

Je zou eens kunnen proberen met een servertje opgezet in VMware oid en daarbij een soortgelijk certificaat aanmaken, dus zelfde waarden als webish gebruikt en dan kijken wat er gebeurt als je vanaf die server mail probeert af te leveren op je mailserver. Moet je wel weer even je Postfix instellen zoals eerst waarbij de mail van webish niet aankwam. Als het dan ook foutgaat met jouw virtuele testserver dan kun je eens een certificaat maken met echte waarden erin (maar nog steeds self-signed) en kijken of het dan wel goed gaat. Dan weet je daarna meer en kun je webish met goede argumenten aanspreken op hun fouten en aangeven wat ze moeten doen om de problemen op te lossen, eventueel via de klant.

--
Mvg,
Arlé

Jelle de Jong

2009-06-19 14:36:55 UTC

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische informatie
ontvangt van een mail server bij webish.nl. Als deze een email
stuurt naar mijn debian stable uptodate postfix smtpd systeem dan
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
alphap2.bravo.nl[77.243.228.161]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te zorgen
dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert
certificaten en ik maak er mijn persoonlijke trots van om al mij
beheerde systemen altijd zeer netjes en veilig op orden te hebben,
dus ik heb er een beetje de pest is dat op een of andere reden de
mail van bravo.nl geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs staan
en mail van andere servers komen allemaal aan. Ook is het sterk dat
een update op mijn beheerde server een probleem geeft gezien de
problemen volgens de gebruikers ongeveer in een tijds periode is
geweest dat er geen enkele update van pakken is geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet,
helemaal uit dus en nu kan de bravo.nl server wel verbinding
maken, maar dit is een tijdelijke oplossing en ik ben hier niet
blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet wat
er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-bravo-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik heb het idee dat de certificaten van bravo.nl door hen zelf
Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw
server kijkt hier strikt naar en kan e.e.a. niet valideren. Er moet
toch minstens serieuze informatie in hun certificaat staan, want
localhost daar kan je niks mee natuurlijk. Voor een ICT bedrijf zou
dat toch eigenlijk wel een serieus certificaat moeten zijn van een
betrouwbare certificeringsinstantie...

Dank Arlé voor de response. Ik heb inderdaad gezien dat bravo een
zelf gemaakt certificaat gebruikt. Dat ze daarin alles op niets
zegende waarden zetten kan ik niets aan doen, maar mijn beheerde
server heeft standaard smtpd_tls_security_level op may staan dus
optioneel.
Hiernaast zou er toch geen ssl_accept error moeten komen als er een
selfsigned cert wordt gebruikt?
Ik vind het inderdaad ook wat vreemd dat een hosting bedrijf zulke
vormgeven certificaten gebruikt, maar dat zou in theorie toch moeten
blijven werken?

Ik kan me heel goed voorstellen dat Postfix het niet accepteert als er fake certificaten worden gebruikt, want er staat helemaal niets in wat naar die server wijst.
Je zou eens kunnen proberen met een servertje opgezet in VMware oid en daarbij een soortgelijk certificaat aanmaken, dus zelfde waarden als bravo gebruikt en dan kijken wat er gebeurt als je vanaf die server mail probeert af te leveren op je mailserver. Moet je wel weer even je Postfix instellen zoals eerst waarbij de mail van bravo niet aankwam. Als het dan ook foutgaat met jouw virtuele testserver dan kun je eens een certificaat maken met echte waarden erin (maar nog steeds self-signed) en kijken of het dan wel goed gaat. Dan weet je daarna meer en kun je bravo met goede argumenten aanspreken op hun fouten en aangeven wat ze moeten doen om de problemen op te lossen, eventueel via de klant.

Ik heb wat debug informatie van de andere server ontvangen. Ik denk niet
dat het aan het certificaat ligt, als er vanaf de ander server een
geforceerde aflever poging wordt gedaan dan gaat het wel goed met TLS
encryptie in de verbinding:

http://archives.neohapsis.com/archives/postfix/2009-06/att-0723/debug-information-from-other-sending-server.tar.gz

Ik wil ook nog even mijn excuses aanbieden dat ik in mijn vorige email
de informatie van de andere hosting partij niet discreet heb veranderd
met wat anders, hier was geen opzet bij. Ik ben enkel op zoek naar een
oplossing en heb er niet aan gedacht even wat sed replace commandos over
de file te laten gaan.

De ander server gebruikt exim, ik ben niet zo bekend met exim, zou
iemand aub eens naar de debug informatie kunnen kijken? Waarom zou het
in eerste instantie niet lukken en met een geforceerde poging wel? Zou
het een hardware of resource limiet kunnen zijn?

Alvast bedankt,

Met vriendelijke groet,

Jelle de Jong

Jelle de Jong

2009-06-19 20:24:54 UTC

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische informatie
ontvangt van een mail server bij webish.nl. Als deze een email
stuurt naar mijn debian stable uptodate postfix smtpd systeem dan
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
alphap2.bravo.nl[XX.XXX.XXX.XXX]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te zorgen
dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert
certificaten en ik maak er mijn persoonlijke trots van om al mij
beheerde systemen altijd zeer netjes en veilig op orden te hebben,
dus ik heb er een beetje de pest is dat op een of andere reden de
mail van bravo.nl geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs staan
en mail van andere servers komen allemaal aan. Ook is het sterk dat
een update op mijn beheerde server een probleem geeft gezien de
problemen volgens de gebruikers ongeveer in een tijds periode is
geweest dat er geen enkele update van pakken is geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet,
helemaal uit dus en nu kan de bravo.nl server wel verbinding
maken, maar dit is een tijdelijke oplossing en ik ben hier niet
blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet wat
er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-bravo-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik kan me heel goed voorstellen dat Postfix het niet accepteert als er fake certificaten worden gebruikt, want er staat helemaal niets in wat naar die server wijst.
Je zou eens kunnen proberen met een servertje opgezet in VMware oid en daarbij een soortgelijk certificaat aanmaken, dus zelfde waarden als bravo gebruikt en dan kijken wat er gebeurt als je vanaf die server mail probeert af te leveren op je mailserver. Moet je wel weer even je Postfix instellen zoals eerst waarbij de mail van bravo niet aankwam. Als het dan ook foutgaat met jouw virtuele testserver dan kun je eens een certificaat maken met echte waarden erin (maar nog steeds self-signed) en kijken of het dan wel goed gaat. Dan weet je daarna meer en kun je bravo met goede argumenten aanspreken op hun fouten en aangeven wat ze moeten doen om de problemen op te lossen, eventueel via de klant.

Ik heb wat debug informatie van de andere server ontvangen. Ik denk niet
dat het aan het certificaat ligt, als er vanaf de ander server een
geforceerde aflever poging wordt gedaan dan gaat het wel goed met TLS
http://archives.neohapsis.com/archives/postfix/2009-06/att-0723/debug-information-from-other-sending-server.tar.gz
Ik wil ook nog even mijn excuses aanbieden dat ik in mijn vorige email
de informatie van de andere hosting partij niet discreet heb veranderd
met wat anders, hier was geen opzet bij. Ik ben enkel op zoek naar een
oplossing en heb er niet aan gedacht even wat sed replace commandos over
de file te laten gaan.
De ander server gebruikt exim, ik ben niet zo bekend met exim, zou
iemand aub eens naar de debug informatie kunnen kijken? Waarom zou het
in eerste instantie niet lukken en met een geforceerde poging wel? Zou
het een hardware of resource limiet kunnen zijn?

In de van de exim serve logs staat dat bij de eerste poging van het
verzenden via een webform het proces exit met signal 11 of wel
segmentation fault... Na wat zoeken om de exim foutmelding diverse
dingen tegen gekomen over exim en niet goed gelinkte systemen met
opensll libs en apache modules. Nu kan een segmentation fault van alles
betekenen, maar de kans is volgens mij klein dat het aan mij postfix
(ontvangende server) systemen ligt. Ik heb nog maar een mailtje gestuurd
naar de betreffende hosting partij en ik hoop dat ze meer informatie
kunnen geven over mogelijke oplossingen.

Als iemand nog tips heeft hoe dit aan te pakken of ervaring heeft dit
soort exim probleem, ik sta open voor help.

Hopelijk later meer met een bericht dat het probleem is opgelost...

Met vriendelijke groet,

Jelle de Jong

Arlé Mooldijk

2009-06-20 10:26:56 UTC

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische
informatie ontvangt van een mail server bij webish.nl. Als deze
een email stuurt naar mijn debian stable uptodate postfix smtpd
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
alphap2.bravo.nl[XX.XXX.XXX.XXX]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te
zorgen dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert
certificaten en ik maak er mijn persoonlijke trots van om al mij
beheerde systemen altijd zeer netjes en veilig op orden te
hebben, dus ik heb er een beetje de pest is dat op een of andere
reden de mail van bravo.nl geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs
staan en mail van andere servers komen allemaal aan. Ook is het
sterk dat een update op mijn beheerde server een probleem geeft
gezien de problemen volgens de gebruikers ongeveer in een tijds
periode is geweest dat er geen enkele update van pakken is
geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet,
helemaal uit dus en nu kan de bravo.nl server wel verbinding
maken, maar dit is een tijdelijke oplossing en ik ben hier niet
blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet
wat er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-bravo-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik heb het idee dat de certificaten van bravo.nl door hen zelf
Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw
server kijkt hier strikt naar en kan e.e.a. niet valideren. Er
moet toch minstens serieuze informatie in hun certificaat staan,
want localhost daar kan je niks mee natuurlijk. Voor een ICT
bedrijf zou dat toch eigenlijk wel een serieus certificaat moeten
zijn van een betrouwbare certificeringsinstantie...

Ik kan me heel goed voorstellen dat Postfix het niet accepteert als
er fake certificaten worden gebruikt, want er staat helemaal niets
in wat naar die server wijst.
Je zou eens kunnen proberen met een servertje opgezet in VMware oid
en daarbij een soortgelijk certificaat aanmaken, dus zelfde waarden
als bravo gebruikt en dan kijken wat er gebeurt als je vanaf die
server mail probeert af te leveren op je mailserver. Moet je wel
weer even je Postfix instellen zoals eerst waarbij de mail van
bravo niet aankwam. Als het dan ook foutgaat met jouw virtuele
testserver dan kun je eens een certificaat maken met echte waarden
erin (maar nog steeds self-signed) en kijken of het dan wel goed
gaat. Dan weet je daarna meer en kun je bravo met goede argumenten
aanspreken op hun fouten en aangeven wat ze moeten doen om de
problemen op te lossen, eventueel via de klant.

Ik heb wat debug informatie van de andere server ontvangen. Ik denk
niet dat het aan het certificaat ligt, als er vanaf de ander server
een geforceerde aflever poging wordt gedaan dan gaat het wel goed
http://archives.neohapsis.com/archives/postfix/2009-06/att-0723/debug-information-from-other-sending-server.tar.gz
Ik wil ook nog even mijn excuses aanbieden dat ik in mijn vorige
email de informatie van de andere hosting partij niet discreet heb
veranderd met wat anders, hier was geen opzet bij. Ik ben enkel op
zoek naar een oplossing en heb er niet aan gedacht even wat sed
replace commandos over de file te laten gaan.
De ander server gebruikt exim, ik ben niet zo bekend met exim, zou
iemand aub eens naar de debug informatie kunnen kijken? Waarom zou
het in eerste instantie niet lukken en met een geforceerde poging
wel? Zou het een hardware of resource limiet kunnen zijn?

In de van de exim serve logs staat dat bij de eerste poging van het
verzenden via een webform het proces exit met signal 11 of wel
segmentation fault... Na wat zoeken om de exim foutmelding diverse
dingen tegen gekomen over exim en niet goed gelinkte systemen met
opensll libs en apache modules. Nu kan een segmentation fault van
alles betekenen, maar de kans is volgens mij klein dat het aan mij
postfix (ontvangende server) systemen ligt. Ik heb nog maar een
mailtje gestuurd naar de betreffende hosting partij en ik hoop dat ze
meer informatie kunnen geven over mogelijke oplossingen.
Als iemand nog tips heeft hoe dit aan te pakken of ervaring heeft dit
soort exim probleem, ik sta open voor help.

Weet je of de andere partij wel naar andere partijen kan mailen met TLS/SSL of hebben ze dit speciaal voor jou ingericht?

--
Mvg,
Arlé

Jelle de Jong

2009-06-21 12:03:21 UTC

Post by Jelle de Jong
Hallo allemaal,
Ik heb een server onder mijn beheer die bedrijfskritische
informatie ontvangt van een mail server bij webish.nl. Als deze
een email stuurt naar mijn debian stable uptodate postfix smtpd
Jun 16 10:42:04 emily postfix/smtpd[25488]: read from B88E0F90
[B88EAC50] (11 bytes => -1 (0xFFFFFFFF))
Jun 16 10:42:04 emily postfix/smtpd[25488]: SSL_accept error from
alphap2.bravo.nl[XX.XXX.XXX.XXX]: -1
Ik ben hier al een goed aantal dagen op en af mee bezig om te
zorgen dat ik het probleem en een oplossing kan vinden.
De server onder mij beheer maakt gebruik van valid CACert
certificaten en ik maak er mijn persoonlijke trots van om al mij
beheerde systemen altijd zeer netjes en veilig op orden te
hebben, dus ik heb er een beetje de pest is dat op een of andere
reden de mail van bravo.nl geen ssl verbinding wil opzetten.
Ik heb geen SSL_accept errors van andere servers in mijn logs
staan en mail van andere servers komen allemaal aan. Ook is het
sterk dat een update op mijn beheerde server een probleem geeft
gezien de problemen volgens de gebruikers ongeveer in een tijds
periode is geweest dat er geen enkele update van pakken is
geweest.
Ik heb nu de postfix smtpd_tls_security_level op none gezet,
helemaal uit dus en nu kan de bravo.nl server wel verbinding
maken, maar dit is een tijdelijke oplossing en ik ben hier niet
blij mee.
Ik hoop nu dat er iemand is die mij kan helpen en misschien weet
wat er nu echt aan de hand is.
http://filebin.ca/vfcxs
Hieronder een selectie van de logs die makkelijk toegankelijk is.
ssldump-smtpd-v-helmwijk-bravo-fail.txt
http://debian.pastebin.com/m8ce090e
postconf-n-helmwijk.txt
http://debian.pastebin.com/m4bf47368
openssl-helmwijk-check.txt
http://debian.pastebin.com/m708bd459
smtp-helmwijk-gmail-ok-test.txt (debian pastbin werkte niet)
http://filebin.ca/mvtjq/smtp-helmwijk-gmail-ok-test.txt

Ik heb het idee dat de certificaten van bravo.nl door hen zelf
Da's vermoedelijk de oorzaak van je probleem denk ik, want jouw
server kijkt hier strikt naar en kan e.e.a. niet valideren. Er
moet toch minstens serieuze informatie in hun certificaat staan,
want localhost daar kan je niks mee natuurlijk. Voor een ICT
bedrijf zou dat toch eigenlijk wel een serieus certificaat moeten
zijn van een betrouwbare certificeringsinstantie...

Ik kan me heel goed voorstellen dat Postfix het niet accepteert als
er fake certificaten worden gebruikt, want er staat helemaal niets
in wat naar die server wijst.
Je zou eens kunnen proberen met een servertje opgezet in VMware oid
en daarbij een soortgelijk certificaat aanmaken, dus zelfde waarden
als bravo gebruikt en dan kijken wat er gebeurt als je vanaf die
server mail probeert af te leveren op je mailserver. Moet je wel
weer even je Postfix instellen zoals eerst waarbij de mail van
bravo niet aankwam. Als het dan ook foutgaat met jouw virtuele
testserver dan kun je eens een certificaat maken met echte waarden
erin (maar nog steeds self-signed) en kijken of het dan wel goed
gaat. Dan weet je daarna meer en kun je bravo met goede argumenten
aanspreken op hun fouten en aangeven wat ze moeten doen om de
problemen op te lossen, eventueel via de klant.

Ik heb wat debug informatie van de andere server ontvangen. Ik denk
niet dat het aan het certificaat ligt, als er vanaf de ander server
een geforceerde aflever poging wordt gedaan dan gaat het wel goed
http://archives.neohapsis.com/archives/postfix/2009-06/att-0723/debug-information-from-other-sending-server.tar.gz
Ik wil ook nog even mijn excuses aanbieden dat ik in mijn vorige
email de informatie van de andere hosting partij niet discreet heb
veranderd met wat anders, hier was geen opzet bij. Ik ben enkel op
zoek naar een oplossing en heb er niet aan gedacht even wat sed
replace commandos over de file te laten gaan.
De ander server gebruikt exim, ik ben niet zo bekend met exim, zou
iemand aub eens naar de debug informatie kunnen kijken? Waarom zou
het in eerste instantie niet lukken en met een geforceerde poging
wel? Zou het een hardware of resource limiet kunnen zijn?

In de van de exim serve logs staat dat bij de eerste poging van het
verzenden via een webform het proces exit met signal 11 of wel
segmentation fault... Na wat zoeken om de exim foutmelding diverse
dingen tegen gekomen over exim en niet goed gelinkte systemen met
opensll libs en apache modules. Nu kan een segmentation fault van
alles betekenen, maar de kans is volgens mij klein dat het aan mij
postfix (ontvangende server) systemen ligt. Ik heb nog maar een
mailtje gestuurd naar de betreffende hosting partij en ik hoop dat ze
meer informatie kunnen geven over mogelijke oplossingen.
Als iemand nog tips heeft hoe dit aan te pakken of ervaring heeft dit
soort exim probleem, ik sta open voor help.

Weet je of de andere partij wel naar andere partijen kan mailen met TLS/SSL of hebben ze dit speciaal voor jou ingericht?

Ik heb geen idee, het is een normale simpele website met web formulier
dat er gehost wordt en belangrijke mails doorstuurt naar mijn beheerde
postfix server. Het kan best zo zijn dat ik inderdaad de enige ben
waarbij de situatie zo is dat er vanaf hun systemen een web formulier
met tls/ssl email naar een andere server moet worden afgeleverd.

Het is wat jammer dat deze hosting partij zo langzaam reageert het
systeem is nu al weken kapot en vanaf afgelopen maandag is het bij mij
klant pas opgevallen en ben ik er direct aan gaan werken. Hiernaast is
het eerste wat aan mij is doorgegeven dat alle concrete acties van mij
als ontvangende kant moeten komen, terwijl er segmentation faults in hun
logs bestanden blijken te staan.

We wachten af, hopelijk loopt de hosting partij de systemen na en
repareert het de systemen.

Met vriendelijke groet,

Jelle de Jong

Arlé Mooldijk

2009-06-21 13:02:18 UTC