Heart-Profit ERP

Zo af en toe komt dit op het scherm tevoorschijn. Hoe kun je nu herleiden welke mail wel of niet is verstuurd?

Maar misschien nog wel belangrijker: Hoe zijn dergelijke mailfouten te voorkomen? De terminal servers staan nu op de Whitelist, dus ik gok er op dat niet meer met het spamfilter heeft te maken.
:19c:

In ieder geval maar eens proberen iets zinnigs achter die : te krijgen.
:swoon:

Johan,

Na analyse blijkt de oorzaak te liggen in de mailserver die niet op tijd reageert.

Tijdens de 'konversatie' tussen Profit en de mailserver krijgt de mailserver na elke stap in die konversatie 30 sekonden de tijd om met een antwoord te komen. Daar is de mailserver toe verplicht. Wat er bij jullie gebeurt, is dat de mailserver niet altijd binnen dit genoemde tijdsbestek van 30 sekonden antwoordt.
Na de 30 sekonden wachttijd verbreekt Profit zèlf de verbinding met de mailserver, in de veronderstelling dat er vast geen antwoord meer zal komen.

Let wel: we hebben het in dit geanalyseerde geval over het verzenden van een email van ca. 80 kilobyte groot; dat de mailserver er dan meer dan 30 sekonden over moet doen om te antwoorden lijkt me behoorlijk lang. Ik denk dan ook dat het raadzaam is om daar eens naar te (laten) kijken.

Normaliter toont de popup in geval van een fout-situatie de response van de mailserver op de laatste door Profit verzonden stap in de konversatie, maar in het geval van een time-out is juist het probleem dàt er geen response meer komt; ik zal een aanpassing doen zodat ook in dat geval een zinnige melding komt.

Voor wat betreft de vraag hoe te herleiden welke mail wel of niet is verstuurd, is voor zover ik weet is voor wat betreft deze situatie de enige mogelijkheid je eigen Inbox te bekijken; emails die daar niet in terecht zijn gekomen zullen ook niet bij de Debiteur zijn aangekomen.

Wij hebben de laatste weken bij het versturen van de orderbevestigingen dezelfde problemen. Gelukkig komt dit niet echt vaak voor.
Ik laat de mensen ook altijd via mijn eigen mail box controleren of de mail verstuurd is.
Nu heb ik twee kleine vraagjes
1) zit de zinnige tekst er in bij de volgende upgrade volgende week??
2) heeft johan al enig idee waarom de mailserver niet reageert...

mvgr Berny

Op dit moment zit de zinnige tekst er nog niet in; volgende week zal dat vast wel lukken, maar of dat op tijd is voor jullie upgrade hangt af van wanneer volgende week jullie die upgrade willen gaan uitvoeren.

Wij wachten op niet iets speciaal, dus ook jij moet de tijd krijgen anders mis je alle mooie wedstrijden van het EK dus wij stellen het wel uit naar eind week 25....

Volgende week woensdag (13-6) heb ik een afspraak staan met iemand, om eens naar die mailserver te kijken, als ik meer weet bericht ik het even.

oke.
Johan alvast bedankt.
Tijdens onze maandelijke check (01/06) heb ik geen foutmeldingen gezien.
Zal voor de zekerheid de melding doorgeven aan ons computerbureau, kijken of zij iets weten.
 :smile:

Wat ik heb geleerd van die mailfout is het volgende:

in de logging van profit zie je dit staan:

09:56:59.07: Start
220 mijn.mailserver Microsoft ESMTP MAIL Service ready at Thu, 31 May 2012 09:58:43 +0200
EHLO verkooplaco
250-mijn.mailserver Hello [x.xx.x.xxx]

....
die vette tijd, dat is de tijd van mijn mailserver. (althans dat is mij zo uitgelegd)
Om 09:58:44 zie ik in de logging staan dat hij verder verwerkt wordt door de mailserver. Dat betekend dat "Profit" de mail volledig afgeleverd heeft bij de mailserver, en dat de mailserver dat bericht volledig ontvangen heeft. (en daarna dat ontvangen bericht  zal versturen naar geadresseerden en dergelijke acties)

Al die Acties zijn voor Profit Server niet relevant. Daarom stuurt Mailserver een berichtje "U wordt Bedankt! Ik heb bericht ..... ontvangen".
Dat schijnt volgens de Exchange man die mij dit uitgelegd heeft, een SMTP-standaard te zijn. (alleen de inhoud van dat berichtje zal wel wat anders zijn dan ik hier schrijf uiteraard)

Profit Server hoort volgens diezelfde SMTP standaard ook te wachten op dat berichtje van Mailserver. Dit berichtje is echter blijkbaar nooit ontvangen door Profit Server. (Natuurlijk kun je je ook af vragen of dat berichtje door Mailserver überhaupt wel is verstuurd. )Omdat dat niet gebeurd, volgt er even later een MailFout en
Timed out
09:58:57.74: End
in de logging.

Wél is de mail volledig leesbaar en compleet verstuurd.

Vraag is dus: Waarom ontvangt Profit Server hier dat berichtje niet. Hier heb ik geen antwoord op, en de exchange man die hier vanmiddag was ook niet. Iemand die dit wel heeft: Ideeën zijn welkom.

Johan,

Je laat 2 tijden uit het maillog-bestand van Profit zien in je laatste post, nl.:

09:56:59.07: Start
09:58:57.74: End

Net geen 2 minuten benodigd om een email te versturen??
Dan moet dit toch wel zijn gegaan om een email van een flink aantal MB's, anders is dit al waanzinnig lang; het kan natuurlijk ook zijn dat deze 2 regels uit de logfile niet tot dezelfde SMTP konversatie behoren.

Exchange kent van zichzelf uitgebreide logging mogelijkheden, het enige wat je hoeft te doen is deze aanzetten en je kunt dan precies bekijken hoe het een en ander aan de Exchange-zijde verloopt. Google maar eens op "exchange smtp log" en er komen genoeg resultaten naar boven om je verder te helpen. De instructies kunnen verschillen per Exchange-versie uiteraard, dus let daar even goed op.

Als dat is gebeurd (logging aanzetten), is het een kwestie van wachten op de eerstvolgende Timeout en je kunt gaan kijken wat Exchange in zijn log-files te melden heeft.

Hier dan de message tracking log van Exchange. De client id eindigend op  .221 is 1 van onze terminal servers waar mijn gebruiker vanuit Profit de Facturen aan het versturen is.

Binnen 2 seconden is deze mail door mijn mailserver ontvangen voor verdere verwerking. En daar komt het even: Wat is "Versturen"?

Wat ik van het verhaal van gister heb begrepen, is het zo dat er tussen de eerste bovenste EventId "RECEIVE" en de "Resolve" , danwel de daar op volgende "Transfer", het verhaal voor Profit eindigd. Op dat moment heeft Mailserver de volledige mail binnen om verder te verwerken, en hoort daarvan bericht te geven aan Profit. Daarna kan Profit verder, en gaat Mailserver het verhaal verder afhandelen. (dat zie je terug in de EventId's Receive, Defer, Deliver etc. )

Kan het zijn dat Profit daadwerkelijk kan / moet / wil wachten op de bevestiging:
250 2.1.5 Ok
die bij het event id "SEnd" vermeldt staat?


Want dan krijg ik een beetje het gevoel dat reden helder wordt Je ziet een aantal malen deze melding voorbij komen:

450 4.7.1 Recipient address rejected: Greylisting in action, please try later

Dat is een vorm van een spamfilter, en ja, dat kan enkele minuten duren. Een vreemde manier welliswaar. De mailserver probeert het gewoon een paar keer totdat de mail doorgelaten wordt. En als Profit daar op moet wachten, ja, dan gaat het fout.

Robert, kun je aangeven op welk signaal je precies wacht en waar dat signaal zou moeten ontstaan in deze logging?

Het blijft nog even een vreemd verhaal.

Greylisting is een spam-defensie mechanisme; tarpitting is er nog zo een.
Mijn eerste indruk was dat jullie eigen mailserver greylisting toepaste, maar dat blijkt bij telefonische navraag niet zo te zijn - het is de mailserver van de ontvanger die dat doet.
Maar wat mij betreft speelt greylisting zich in dit geval af tussen mailservers onderling en niet tussen Profit (een mailclient) en jullie mailserver.

Waar Profit op wacht is de volgende melding:

250 2.6.0 <1234@mijn.mailserver> [InternalId=23456] Queued mail for delivery

Slechts de vette numerieke code is hierbij van belang.
Hiermee geeft jullie mailserver aan de email te hebben ontvangen en dat deze de verdere bezorging voor zijn rekening heeft genomen.
Maar het zal toch niet zo zijn dat die hierboven genoemde melding pas door Profit wordt ontvangen als de bezorging verderop in het traject is geslaagd??
Dat lijkt mij niet de bedoeling!

Telefonisch is er afgesproken dat Johan gaat kijken in hoeverre er nog meer informatie uit de Exchange mailserver kan worden gehaald om daar uitsluistel over te krijgen.

Ik had gister met Robert min of meer afgesproken dat ik terug zou komen op de 250 2.6.0 melding. Ik ben zelf niet een Exchange expert, dus ik heb even hulp ingeroepen. ONderstaand even de belangrijkste elementen uit de wijsheid die ik daar uit haal:

__________
De exchange server ontvangt het mailtje goed, dat is normaal een teken dat de exchange server de handshake goed afhandelt met een melding 250 2.6.0. Dit vind je niet terug in de message tracking, het kan wezen dat we daar extra logging voor aan moeten zetten.

Deze logs zeggen echter weinig, omdat het probleem hoogstwaarschijnlijk is, dat de exchange server de melding wél geeft, maar dat deze niet aankomt bij de client (Profit). Dit ga je niet terugvinden in de logging van de exchange server zelf.

Wat we daarom moeten weten is : Wanneer het verkeerd gaat, wordt dan de mail wel goed verstuurd (in dat geval is de storing elke keer hetzelfde) Daarna kijken of de de ip packets kunnen capturen om te  zien of daar iets misgaat. (het capturen van de ip packets die er plaats vinden tussen de client en server.) Dit is geen logging die je aan kunt zetten, maar software die je daarvoor in moet stellen.
______________


Dat betekend weer even huiswerk voor ons / mij, want ik ben benieuwd welke software daarvoor nodig is en hoe dat ingesteld moet worden etc. Wordt vervolgd op 2 juli. Maar misschien gaat er iemand met deze informatie nog een lichtje branden.

Met wireshark kan je packets capture maken.
Deze draai je op de terminal server waar het heart probleem zich voor doet.

Vanmorgen is er door onze leverancier weer gekeken naar dit probleem, dit omdat het nog steeds regelmatig fout gaat; de emails worden wel verzonden maar het duurt allemaal erg lang omdat er steeds een time-out foutmelding komt (niet altijd trouwens).
We hebben nu de anti-virus op de exchangeserver uit gezet zodat die geen problemen kan veroorzaken. Vlak daarna overigens nog wel een time-out fout gehad dus dat was waarschijnlijk ook niet de oorzaak.
Kan een mogelijke oorzaak ook het formaat van de PDF zijn? We hadden een template gemaakt van 188kb waardoor de PDF iets meer dan 200kb werd. Ik heb nu een template van 33kb gemaakt zodat de PDF iets meer dan 50kb wordt. We gaan het nu weer in de gaten houden.
Als iemand nog ideeën heeft dan verneem ik dat graag!

In ons geval lijkt het er inderdaad op dat de mailserver geen respons geeft richting de TerminalServer. Ook al heb ik weinig gereageerd de laatste tijd, dit onderwerp houdt ook ons nog wel degelijk bezig.

Wat nu sinds een week wel werkt, is dat we de smtp server instelling bij de bedrijfsparameters aangepast hebben. Ik weet niet precies hoe onze leverancier dit noemde, dus vergeef me eventuele foute betiteling.

De smtp server stond ingesteld op x.x.x.224, zijnde onze mailserver (exchange). Nu heeft hij iets ingebouwd op x.x.x.216, zijnde een applicatieserver. Daar staat nu smtprelay of iets dergelijks (geen idee hoe dit precies heet) op ingesteld, en die levert dat vervolgens weer af bij de mailserver.

Kortom; we hebben er een stapje tussen gebouwd. Dat tussenstation is de nieuwe smtpserver instelling van de bedrijfsparameters van Heart geworden. het is dus eigenlijk gewoon een soort dummy-mailserver, een doorgeef-luik. Hiermee hebben we deze week goede ervaring.

Ik weet niet of dat bij ons hetzelfde is maar hier is de smtp instelling zo gemaakt dat de email wordt gestuurd naar een 'Receive Connector' die voor dit doel is gemaakt.

Het lijkt mij niet dat die schamele 200KB een probleem kan vormen. Een virus scanner wel. Maar ja ...

Dom idee misschien : Stel dat die bijlage moet komen van een disk die intussen stil staat; hoort voor een server niet te gebeuren, maar voor een PC op je bureau kan dat gemakkelijk (zie Power Settings). Dan hoef je maar een spin-up time te hebben die te lang duurt en daar ga je.

De PDF-template staat op DATA1\TROEP zodat iedereen die kan gebruiken.