Tracing emails from SMTP delivery into SmarterMail to delivery to user mailbox
Idea shared by Ciaran Morgan - 7/25/2017 at 5:48 PM
I often get requests from users to say that they have not received an email that the sender verifies has been sent.
At the moment, what I do is to search the SMTP log and sure enough I can see an entry such as:
[2017.07.25] 23:35:30 [][1705207] Data transfer succeeded, writing mail to 73493815.eml
My next step is to then search the Delivery log for a reference to this email.  However there is NO reference to 73493815.eml in the delivery log but there is a reference to ID:73493815. I'm still trying to understand what the number in square brackets after the IP address relates to because it is different between the SMTP and Delivery logs.
For the one of email request, that is not really a big issue but if I have *lots* to check, or the local user receives a significant amount of email from the same sender and something happens (e.g. spam/virus checks are taking significant time to process), it is a really boring any time consuming process having two tabs open as the SM administrator and cutting and pasting the numbers part of the email from the SMTP delivery report and pasting it into the other tab where I first have to type "ID:". and then repeating this for the following day depending upon the time of SMTP reception.
Can this be automated please?
My proposed method that would be that the filename (i.e. 73493815.eml in my example) be made a hyperlink in the SMTP log that causes a new tab to open in the "View Logs" tool which is preset to search the delivery report, automatically fills in the search criteria (in my example ID:73493815) and let the search the delivery logs for the day idenified from the SMTP log  and the day after the date it was received via SMTP?  Why this last part - if an email is received via SMTP at any time and for what ever reason there is a delivery delay in SM, (easy examples here being close to midnight), the delivery may occur to the users mailbox on a different day to which the SM server received it.
Doing this means that it is really quick to find the cause via the spam/virus checks report as to what the problem is. 
All the above is, of course, workable for incoming mail but a different process has to be used for my users complaining that their recipients have not received an email they have sent. There are two scenarios I see that can happen - the first one I have regularly encountered:-
1. Delivery really has happened - however searching the delivery log if that user sends a lot of emails to the same person, cant give my a time of sending for whatever reason or has multiple recipients can result in a lot of data to shift through.  The record that tells you everything if it has been delivered looks like
[2017.07.25] 23:18:01 [93811] Delivery for to user has completed (Delivered)
If such a record exists, it is possible to then tick the "Display related traffic" and, depending on the time, adjust the search criteria to include day before/after and this narrows down the data to shift through.  It is then easy to report back to my user to say that the remote server was succesfuly connected to, the time, and the remote server response.  It is then the problem of the remote server admin to figure out why the email has not been delivered.
2. The user has mistyped the email address (or some other odd reason) and the email has ended up in the "Waiting to deliver" queue or somewhere else (there was an internal SM error for that particular email - here I imagine that the error log might have something)- here it would be good to report on emails from that local user that are stuck in the waiting to deliver queue either by opening a separate tab on the "waiting to delivery" queue filtered to that local user. Here, I amdit I have not been able to trap enough logs to see what SM actually does so in this is the case I do not what I am looking for - again some advice from the developers on what SM does would be helpful?
Pretty much all my experience is related to finding out why something is in the SMTP log and cross checking it to the delivery log. Looking forward to your consideration of these features, or identification of methods/features that are actually already there but which I an obviously not aware of..
I am currently using SM v15 (latest release) - I have not done enough testing/not enough time on SM16 to see if this capability has been implemented or not.
Ciaran Morgan

1 Reply

Reply to Thread
Yes, some form of a unified delivery log that would show all of the related info would be very welcome.

Reply to Thread