On Wed, 2007-02-07 at 15:14 -0800, John W. Baxter wrote:
> On 2/7/07 8:53 AM, "David Woodhouse" <dwmw2@???> wrote:
>
> > Do we have to take the hackish approach of doing a lookup
> > to check if we find the object we just tried to insert?
>
> As one who wrote a (Python) script which now and then crashed our master
> LDAP server (whichever server was the master at the time, and openLDAP) when
> inserting a new user, I'm nervous about that approach. The script inserted
> the data then immediately read some of it out to display as a result.
>
> After several needs to rebuild, I finally associated what I had just done
> with the slapd crash which corrupted the database (fortunately without
> inducing slurpd to send out the corruption to the other servers).
>
> I just put in a brief delay between writing the data and reading it back and
> all was well. Then, of course, we rationalized our account creation and
> stopped using the script...within about 6 weeks of the fix.
That has to be a database bug. But even so, checking for success isn't
good enough -- I want the damn error message for the logs.
This helps...
--- exim-4.66/src/expand.c~ 2007-01-08 14:25:36.000000000 +0000
+++ exim-4.66/src/expand.c 2007-02-07 17:31:02.000000000 +0000
@@ -507,6 +507,7 @@ static var_entry var_table[] = {
{ "return_path", vtype_stringptr, &return_path },
{ "return_size_limit", vtype_int, &bounce_return_size_limit },
{ "runrc", vtype_int, &runrc },
+ { "search_error_message", vtype_stringptr, &search_error_message },
{ "self_hostname", vtype_stringptr, &self_hostname },
{ "sender_address", vtype_stringptr, &sender_address },
{ "sender_address_data", vtype_stringptr, &sender_address_data },
.. but leads to ugly ACL code...
# If the mail isn't already the database, defer it with an appropriate
# message, and add it. Do the addition to the greylist database as a
# hackish side-effect of the log-message. This is where the 5 minute
# timeout is set ($tod_epoch + 300), should you wish to change it.
defer condition = ${if eq {$acl_m_greyexpiry}{} {1}}
set acl_m_dontcare = ${lookup sqlite {GREYDB INSERT INTO greylist \
VALUES ( '$acl_m_greyident', \
'${eval10:$tod_epoch+300}', \
'$sender_host_address', \
'${quote_sqlite:$sender_helo_name}' );}}
condition = ${if eq {$search_error_message}{} {1}}
log_message = Greylisting <$h_message-id:> (from <$sender_address>) for offences: ${sg {$acl_m_greylistreasons}{\n}{,}}
message = Your mail was considered suspicious for the following reason(s):\n$acl_m_greylistreasons \
The mail has been greylisted for 5 minutes, after which it should be accepted. \
We apologise for the inconvenience. Your mail system should keep the mail on \
its queue and retry. When that happens, your system will be added to the list \
genuine mail systems, and mail from it should not be greylisted any more. \
In the event of problems, please contact postmaster@$qualify_domain
# By means of the second 'condition' line above, we only actually defer the message if the
# SQL insertion succeeded. If the insertion fails, just accept it and log a nasty message.
warn condition = ${if eq {$acl_m_greyexpiry}{} {1}}
log_message = Greylist insertion failed: $search_error_message
accept condition = ${if eq {$acl_m_greyexpiry}{} {1}}
... and although it does seem to do the right thing and accept the
message instead of greylisting it (because if the db insertion isn't
working, it'd just keep deferring it for ever), it still seems that
$search_error_message doesn't manage to get into the log intact. It
seems to be empty by then.
2007-02-07 18:12:10 1HErH7-0000lQ-SN H=pmac.infradead.org [81.187.2.168] Warning: Greylist insertion failed:
--
dwmw2
