On Mon, Mar 19, 2012 at 10:47 AM, Jeremy Harris <jgh@???> wrote: > Actually, despite the comment on extract_option() I don't see it being
> called at RCPT. Maybe I'm missing something, or maybe the
> comment needs correcting.
I took it at face value, but it appears to need correcting since it's
not called in the RCPT_CMD case.
>> So the extract_option requires a key=value pair. At this point, the
>> has not yet verified that the options are valid/invalid, it's just
>> splitting them from the email address. With contemporary exim design
>> standards in mind:
>> 1) would it better to pass a variable to extract_option() to indicate
>> that "=" is not required?
>
> Given the limited number of callers I'd be happy with such a mod.
> The problem is that it's still required for the current options,
> and you've not determined what the option is yet.
>
> I'd like a code refactor from the if/elseif chain into a table-driven
> approach, using a static data table of acceptable option names
> each with a "supplies argument" indicator. This would be in line
> with (eg.) the parsing in acl_verify().
...that makes a lot of sense. Until now, everything that exim
supported required an argument, so bailing on the absence of an "="
was sufficient for a quick sanity check. To support non-argument
options, each option will have to be sanity checked and validated at
the same time. Doing this in a table would be, theoretically, better
able to do both at once.
> Good luck; it looks like a worthwhile project.
Thanks for the encouragement.
...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding
