Re: [exim] Full SMTP session log functionality

Top Page
Delete this message
Reply to this message
Author: Ted Cooper
Date:  
To: exim-users
Subject: Re: [exim] Full SMTP session log functionality
Adam Osuchowski wrote:
> Ted Cooper wrote:
>> That's what debug mode is for. Having that much raw data stuffed into
>> the logs would be one hell of a space hog, especially when you only need
>> that information when something is wrong and you need to test a specific
>> case.
>
> Ok, but in most cases I need to diagnose problems have already occurred
> in the past. In such situations it's easier for me (and probably for
> some other people too) to have that informations about SMTP dialog.
> Turning off mail daemon and running it in debug mode only to solve problems
> with individual clients is not good solution.


If you have a system with multiple clients and any kind of load, then
all this logging is going to be quite volumous.

>> You could already do it with the existing functionality anyway, using
>> log_write and the appropriate ACL hooks. The only command I can think of
>> without an ACL is RSET, but you could mimic it with some smart thinking
>> in the MAIL FROM ACL.
>
> Do you mean log_write() function from local scan or Perl? Great, but it
> requires writing extra code and/or rebuilding exim (which could be
> problematic during upgrades on many hosts). So, if it is already possible,
> why don't put that functionality into existing exim sources, permanently?
> It does not need to be active by default, but if necessary, somebody could
> easily turn it on through ,,log_selector = +smtp_dialog'' or something
> similar. Then, for people who don't need it, nothing will change.


Oops, no. I meant "log_message", which is available in the ACLs. Oops.
It's all described in the ACL section of the manual. It doesn't require
you to recompile exim or write any "code", just add some stuff the to
ACLs, maybe referencing $smtp_command. And add a few extra hard drives
for all the logging.

The SMTP conversation is not particularly difficult to understand and is
very predictable. The existing error messages and log messages provided
in the default logging allow for easy interpretation of exactly where in
the conversation any errors occurred.



--
The Exim Manual
http://www.exim.org/docs.html
http://docs.exim.org/current/