Mailing List Archive

On Mon, 20 May 2002, Ephraim Silverberg wrote:

> We have a router condition in our configuration file that looks like this:
>
> condition = ${perl{check_content}{$message_headers}{$message_body}}
>
> Every few messages, we get this error message:
>
> 2002-05-20 16:20:22 failed to expand condition"${perl{check_content}{$message_headers} {$message_body}}" for content_checker router: unknown variable name "message_headers"
>
> It doesn't happen every message (almost all messages pass through this router)
> and no message seems to be adversely affected in its delivery by this failure.
>
> Any ideas?

I think I can see what's going on here, but just to be doubly sure: Are
you verifying senders or recipients in your ACL for checking RCPT
commands? I suspect that you are, and Exim is giving this incorrect
error because there are no header lines in existence at that stage.

You could double-check this by running a test with "exim -bh".

Assuming I've got this right, I'll fix it for the next release (and send
you a patch to try out.)


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

On Tue, 21 May 2002, Philip Hazel wrote:

>> Any ideas?
>
> I think I can see what's going on here, but just to be doubly sure: Are
> you verifying senders or recipients in your ACL for checking RCPT
> commands? I suspect that you are, and Exim is giving this incorrect
> error because there are no header lines in existence at that stage.

Yes, we do for non-local domains -- this must be the source of the messages.

> You could double-check this by running a test with "exim -bh".

Indeed, this illustrates the error.

> Assuming I've got this right, I'll fix it for the next release (and send
> you a patch to try out.)

Okay, thanks very much.

Ephraim
___________________________________________________________________________
Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521
Hebrew University, Jerusalem, Israel. Fax number: 972-2-5617723
WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim@cse.huji.ac.il

Quoth Ephraim Silverberg on Tue, May 21, 2002:
> On Tue, 21 May 2002, Philip Hazel wrote:
> > I think I can see what's going on here, but just to be doubly sure: Are
> > you verifying senders or recipients in your ACL for checking RCPT
> > commands? I suspect that you are, and Exim is giving this incorrect
> > error because there are no header lines in existence at that stage.
>
> Yes, we do for non-local domains -- this must be the source of the messages.

Indeed, since we changed the router to no_verify (two hours ago),
we get no errors. Thanks.

But the interesting thing is that when I ran the daemon with
debugging, we got *no* errors about unknown variables, but
instead we got errors like the following for some messages:

2002-05-21 14:55:57 17A8FB-000NPp-00 internal problem in system filter: failure to transfer data from subprocess
2002-05-21 14:55:57 17A8FB-000NPp-00 Error in system filter file: internal problem in system filter: failure to transfer data from subprocess

And the "unknown variable" error was given only to some messages,
not all of them, which confused me a lot.

Vadik.

--
( Forth ) base dup @ swap hex dup @ 2 swap over + * over ! 22a s51u1t
sw3alw vr20io vqo5mc ux1z4w wb72ve wb72v7 :noname 2dup - swap dup
- do begin dup while 74 /mod swap emit repeat drop loop ! ; execute

On Tue, 21 May 2002, Vadim Vygonets wrote:

> And the "unknown variable" error was given only to some messages,
> not all of them, which confused me a lot.

Well, I don't want to make it too easy for you, do I? :-)

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

Quoth Philip Hazel on Tue, May 21, 2002:
> On Tue, 21 May 2002, Vadim Vygonets wrote:
> > And the "unknown variable" error was given only to some messages,
> > not all of them, which confused me a lot.
>
> Well, I don't want to make it too easy for you, do I? :-)

I'm all for "what's in the source?" quiz.

I must say that I didn't debug it enough, because I read your
message with the workaround and it has been well since that. But
if you have any hints about where I should put debug messages and
the like, I'll happily use them.

Vadik.

--
Prof: So the American government went to IBM to come up with a data
encryption standard and they came up with ...
Student: EBCDIC!

Quoth Philip Hazel on Tue, May 21, 2002:
> On Tue, 21 May 2002, Vadim Vygonets wrote:
>
> > And the "unknown variable" error was given only to some messages,
> > not all of them, which confused me a lot.
>
> Well, I don't want to make it too easy for you, do I? :-)

More info: it seems that if I send the message with "-d+all", the
delivery fails immediately, but succeeds at the next queue run.
The error is:

2002-05-23 01:10:31 17AeJT-000CW4-00 internal problem in system filter: failure to transfer data from subprocess
2002-05-23 01:10:31 17AeJT-000CW4-00 Error in system filter file: internal problem in system filter: failure to transfer data from subprocess

And the last few pages of the log are filled with:

---0 Get 135185128 32 string.c 346
---0 Get 135185160 16 string.c 346
---0 Get 135185176 24 filter.c 688
---0 Get 135185200 24 filter.c 480
---0 Get 135185224 24 string.c 346
---0 Get 135185248 16 string.c 346
---0 Get 135185264 224 string.c 346
---0 Get 135185488 24 filter.c 1000
---0 Get 135096968 80 string.c 346

And the last Malloc line is:

--Malloc 135180288 8192 store.c 133 111968 1605

If I do "-d-all+memory", the last few lines are:

---0 Get 135132936 8 transport.c 474
---0 Rst 135132936 ** transport.c 617 32768
---0 Get 135132712 64 string.c 1059
---0 Get 135132776 40 tree.c 32
---0 Get 135132816 40 tree.c 32
---0 Rst 135132816 ** tree.c 35 32768
---0 Get 135132816 256 deliver.c 698

(and there's a chunk of Free in search.c a page before that), and
the last Malloc is:

--Malloc 135070912 16 search.c 381 40960 19177

Tomorrow I'm going to do some more testing and see what debug
flags triggers the panic. It's stranger than fiction.

Vadik.

--
This is a test. This is only a test. Had this been a real
emergency, you would all be dead by now.