Re: [Exim] local_scan() addition: views sought

Top Page
Delete this message
Reply to this message
Author: Nico Erfurth
Date:  
To: exim-users
CC: Marc MERLIN, Tabor J. Wells
Subject: Re: [Exim] local_scan() addition: views sought
Philip Hazel wrote:
> On Tue, 3 Dec 2002, Marc MERLIN wrote:
>
>>2) my request doesn't change the API, please go read it again.
>
>
> I'm afraid it *does* change the API. When the return code is "accept",
> it is defined that the value of the return string is placed in the
> $local_scan_data variable, for use by routers and transports. I'm sure
> people are using this.
>
> That is why I was trying to think of some semi-compatible way of
> splitting one string into two - part for $local_scan_data, and part for
> the return message. But this cannot be done tidily.
>
> Simply returning the string would be highly incompatible, and might
> expose private data.


Hmmm, can't we do it with a global string that's published in
local_scan.h? (I know, that's not clean, but it won't break everything).

something like
static uschar *smtp_return_text = NULL;

Scenario:

local_scan-funtion-returns
if smtp_return_text is set, it's returned in the response
with no smtp_return_text we just act like before.

How does that sound?

The most clean way (without breaking compatibility) would be a new
local_scan-interface (local_scan2), and a wrapper-function for the old
interface, like someone else mentioned.

ciao