Mailing List Archive

[WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT
This patch is not final, it needs some pointers/input.

So I found myself wanting to have an ACL run on every single exit of an
SMTP connection for whatever reason so that I could use it to figure out
if a host was being nice and using quit or just dropping the connection,
and finding that information out sooner rather than later.

I have delved into the code and tried to produce something that wont
blow up any old configurations and should work to fill pretty much
everyone's wishes. It's a little bit ugly, but I can work on that if
this is deemed to not be a complete waste of everyone's time.

It has a few limitations due to the number of ways that a connection can
fail and the complexity of some of exit functions that I was not game to
touch for fear of really screwing something up. I should revisit
smtp_handle_acl_fail in smtp_in.c and see if I can more closely tie in
the exit acl instead of its present implementation where the user_msg
and log_msg are not used.

When the connection is terminated due to a local configuration or system
problem, the exit acl is also not called as it makes a pair already
cyclic function calls into a self calling triple.

A variable $smtp_notquit_reason is available to the acl for the user to
figure out what went wrong.
command-timeout - exim timed out waiting for next SMTP command
sigterm - got sigterm while in initial conversation
acl-drop - an ACL in the conversation returned "drop"
tls-failed - TLS failed to start
connection-lost - connection was lost at any stage
synchronization-error - sync error
bad-commands - too many SMTP commands in a row, or too many non mail
logging-error - one of the log errors I could handle
data-timeout - no data in DATA section in a long time
config-eror - something went boom in your config
signal-exit - got sigterm or sigint while receiving message body

I did not make a new ACL for sync errors as, I thought it was a bad
idea. If people really want it I can probably add it in a matter of
minutes now that I know how this section of the exim code works.

I want to blacklist the "delay" term from being used in the acl as it's
completely useless and may screw things over as this acl is called
during a number of signal handlers. From what I understand of how the
signals have been setup in an exim receiving process, this isn't really
that big an issue as the signal is left disabled during the processing
of the signal, but it still leaves an opening for people to be stupid.
What little I tried to this front ended up not working in the slightest.

I guess now the question is, what do I need to do to this make it good
enough to be accepted or should I just /dev/null it?

I also added the QUIT ACL being called in one extra place where I
thought it should be, just for completeness. There was another place I
wanted to add it but I can't find it right at this very moment.

Ted.

--
The Exim Manual
http://www.exim.org/docs.html
http://www.exim.org/exim-html-current/doc/html/spec_html/index.html
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
On Fri, 13 Jul 2007, Ted Cooper wrote:

> This patch is not final, it needs some pointers/input.

I will take a look in due course, but probably not until after the Exim
course is over at this stage (i.e. not till August).

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
On Fri, 13 Jul 2007, Ted Cooper wrote:

> This patch is not final, it needs some pointers/input.

FYI: I have finally got to this and am in the process of implementing
it, with a few tidies, but mostly as is.

> I should revisit smtp_handle_acl_fail in smtp_in.c and see if I can
> more closely tie in the exit acl instead of its present implementation
> where the user_msg and log_msg are not used.

I don't think that is necessary. Control gets there only when another
ACL has obeyed "drop" - and *its* user_msg and log_msg have been used.
It is, I think, easiest just to document this.

> I want to blacklist the "delay" term from being used in the acl as it's
> completely useless and may screw things over as this acl is called
> during a number of signal handlers.

That should be possible.

> I also added the QUIT ACL being called in one extra place where I
> thought it should be, just for completeness.

Good point.

Philip

--
Philip Hazel, University of Cambridge Computing Service.

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
Philip Hazel wrote:
> On Fri, 13 Jul 2007, Ted Cooper wrote:
>
>> This patch is not final, it needs some pointers/input.
>
> FYI: I have finally got to this and am in the process of implementing
> it, with a few tidies, but mostly as is.
>
>> I should revisit smtp_handle_acl_fail in smtp_in.c and see if I can
>> more closely tie in the exit acl instead of its present implementation
>> where the user_msg and log_msg are not used.
>
> I don't think that is necessary. Control gets there only when another
> ACL has obeyed "drop" - and *its* user_msg and log_msg have been used.
> It is, I think, easiest just to document this.
>
>> I want to blacklist the "delay" term from being used in the acl as it's
>> completely useless and may screw things over as this acl is called
>> during a number of signal handlers.
>
> That should be possible.
>
>> I also added the QUIT ACL being called in one extra place where I
>> thought it should be, just for completeness.
>
> Good point.
>
> Philip
>

I found another place where the QUIT ACL may possibly want to be called
but I had reservations about it when I spotted it. Unfortunately we've
been preparing for a trade show ever since I did that patch so I haven't
been able to change it and test it. So far, the rest of the patch has
been running on my mail.linuxwan.net server without fail.

The function void smtp_closedown(uschar *message) (smtp_in.c - line 720
in mine) is another function that sits in a loop waiting for
disconnection or QUIT. It probably needs to call both the QUIT ACL and
not-QUIT ACL when EOF_CMD and QUIT_CMD occur. As soon as that function
returns, the thread is seems to be terminated hence the reason for
calling both. I can throw it together but if you've already cleaned up
my code then whatever I add will probably just snuff it all up again.


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

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
On Sat, 18 Aug 2007, Ted Cooper wrote:

> I found another place where the QUIT ACL may possibly want to be called
> but I had reservations about it when I spotted it.

Hmm. It is documented that the QUIT ACL does not run for certain kinds
of disastrous failure. See 40.8. I can't remember why I did this, but I
imagine I thought the ACL would be used on for "normal" QUITs. But I
don't really mind either way.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
Philip Hazel wrote:
> On Sat, 18 Aug 2007, Ted Cooper wrote:
>
>> I found another place where the QUIT ACL may possibly want to be called
>> but I had reservations about it when I spotted it.
>
> Hmm. It is documented that the QUIT ACL does not run for certain kinds
> of disastrous failure. See 40.8. I can't remember why I did this, but I
> imagine I thought the ACL would be used on for "normal" QUITs. But I
> don't really mind either way.

I was just trying to cover every single exit path for an Exim process
that was in a conversation with a remote host entirely for selfish
reasons :)

I run a daemon on a socket that dictates what exim does based on the
available evidence, but it does so by tracking the connection from
connection to exit. For every connection, I wanted an appropriate exit.

Considering the cases where Exim doesn't call a QUIT (or not-QUIT now)
ACL, it's probably just fine to leave it as is, without every exit
covered. If something is that wrong with Exim, then I'd like to think I
would have noticed and fixed the situation before it gets out of hand.
The numerous entries in the panic log and perhaps an exited daemon
should give it away.

Or maybe the not-QUIT ACL could be the collector for all terminal errors
like that - setting the variable $smtp_notquit_reason to yet another
creative string. It would probably need to be renamed if its role
changed that much.

I have remembered my reservations about touching the smtp_closedown
function. If the not-QUIT function which calls the ACL fails because it
is not able to write a log line, it calls smtp_closedown again creating
an infinite loop. I suspect calling an ACL at this stage would be more
trouble that it's worth.


For disastrous errors that don't occur unless there's something
seriously wrong with Exim that it can't receive messages anyway, at
least for my purposes, not calling the QUIT or not-QUIT ACL is
acceptable. I defer the choice to the court.


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

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [WL 413 & 343] An exim ACL called when the SMTP connection ends without QUIT [ In reply to ]
On Tue, 21 Aug 2007, Ted Cooper wrote:

> For disastrous errors that don't occur unless there's something
> seriously wrong with Exim that it can't receive messages anyway, at
> least for my purposes, not calling the QUIT or not-QUIT ACL is
> acceptable. I defer the choice to the court.

I have chosen not to call an ACL in these "Exim is in really bad
trouble" situations. The code is now committed, with documentation in
NewStuff. It will be in tonight's snapshot and ultimately in the 4.68
release in a week or two.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##