SMTP activity log!
To whom it may concern,
I have Sun ONE Messaging Server 6.0 (built Oct 29 2003)
libimta.so 6.0 (built 17:32:22, Oct 29 2003)
One requirement is that we can monitor smtp activity through logs. e.g. whether a particular email of a particular user has been succesfully delivered/rejected by the remote server, etc.
In order to achieve this I put the logging keyword in the defaults channel in the imta.cnf file and issue the rebuilt and dispatcher restrart commands.
Finally I restarted the whole mail server.
After some time I notice that I got a mail.log_current file generated at /opt/SUNmsgsr/log location.
I found that mail.log_current describes just the transactional entries but it doesnot logs any smtp activity at a finer detail level.
Could anyone tell me how I can generate logs for smtp activitiy at a granular level so that i can do forensic level investigation for even a single email level.
Regards,
Farhan Ahmed.
Vision Valley, Dubai, UAE.
# 3
Dear Jay,
The scenario is somewhat like this:
I have to prove someone(a company) that a specific email is going succesfully out from my mail server to his company's mail server. But their mail server is keep rejecting this email.
I have to gather all the communication between my mail server and their mail server for this particular email and send them as a proof that the mail is going out perfectly fine from my system and is received on other domain mail servers perfectly fine but that particular mail server is keep on rejecting it.
For this reason, I put "defaults logging" so to get mail.log but this mail.log file just gathers transactional information. It does not logs details of communication between mail servers.
I hope I have made my point clear jay,
Hoping to get your support soon,
Regards,
Farhan Ahmed.
# 4
Ah. Ok.
Your mail.log_current will show if a message failed or succeeded. Each line in the file will have a key letter telling you what it's for.
"E" is Enqueue.
"D" is Dequeue
"Q" is reQueue
If we get some error from an external server, we will requeue the message, and try it again later.
The reason for the requeue is actually placed in the log, AND in the actual message.
You can use the
imsimta qm
command,with the history flag, to get the actual failure from the file in the queue.
You can use the
imsimta qm directory
command to see what's there
also,
imsimta qm sum
gives a summary of what's in the queue.
If you need MORE than what's normally logged, you need to put debug logging on, but that is very verbose.
Add the keyword:
slave_debug
to the channel configuration line for tcp_local in imta.cnf
add
MM_DEBUG=5
to the end of the option.dat file.
run:
imsimta cnbuild
imsimta restart
and send a test message to the problematical host
then remove the slave_debug from the imta.cnf, and rerun the above commands. You can leave the MM_DEBUG=5, it'll have no effect without the slave_debug command.
