> I'm adding some requested features to the local_scan() API. One of them > is the ability to specify a message as part of the 250 SMTP response > when local_scan() accepts a message. The current interface has only one > string that local_scan() passes back: for failures this string is
> already used for the SMTP response, but for successes, it is used to set > $local_scan_data to pass on data with the message for use by routers and > transports.
>
> I don't really want to change the function's API by adding another
> string because this will make everybody's function stop working.
>
> The returned string may not contain any newlines for the success case. > At the moment, newlines in the string are forced to become spaces. It > occurs to me that I could use newline as a separator in this string: >
> All characters before the first newline are saved in local_scan_data; > All characters after the first newline (including any more newlines) > become part of the 250 response.
>
> This is still an incompatible change, but a smaller one.
>
> Views?
>
I believe strongly that making a change to the local_scan() API at
this
stage would not be a good idea because, as you state, existing
functions
would stop working.
As I have worked with local_scan() functions over the last couple of
months I have found them very powerful. I do not have a problem with
the solution that you propose but perhaps a more general solution
might
be better. For example, each line in the returned string could be
identified by a prefix (in the absence of a prefix the default for
message accepted could be to save the string in local_scan_data). As
the exim code is updated for new suggestions/requests new prefixes
could be defined; existing functions would still work but not use
the
new features.
I'm not sure how many uses of the returned string have been
requested
(personally I am happy as it is). If no other uses of the returned
string can be envisaged my suggestion would add an unneccessary
element
of complexity and should be ignored. If, however, we can foresee a
multi-line (3 plus) return string, I prefer the prefix method to
avoid
having to make sure that the necessary lines (perhaps including
blank
lines) are returned in the right format and order.
