On Mon, Mar 19, 2012 at 10:47 AM, Jeremy Harris <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
