[ Jason L Tibbitts III writes: ]
> >>>>> "DW" == Dave Wolfe <email@example.com> writes:
> DW> I see the little UNDOCUMENTED trick Jason put in there now to overload
> DW> restrict_post.
> I don't believe that was me. I honestly don't recall mucking about with
> access_check; that definitely isn't my comment style.
My sincere apologies. Rolling back my screen shows comments by Chan on
> DW> I'll let Jason clean up his mess for 1.94.2 (hint, hint).
> As I haven't been following this discussion closely, I'm not sure what
> needs to be fixed. If someone's going to start blaming this on me I guess
> I'll pull the messages out of the archives to see what the big deal is.
Not your problem, but basically, 'restrict_post' is used for two similar
duties but handled differently for each. The '*_access' variables use it
via access_check(), which *always* prepends the list directory to the
paths and doesn't care if the resulting path doesn't exist. Resend uses
it via check_sender(), which prepends the list directory *only* when the
string isn't an absolute path and bitches when the file can't be opened.
None of this dichotomy is mentioned in any of the config file comments
or anywhere else a user is expected to find it.
Do we break compatibility and stop accepting absolute paths in
check_sender? Or expand the problematical use of absolute paths in
access_check()? Either a new config variable should've been used for the
'*_access' stuff in the first place or 'restrict_post' should've been
renamed to something more fitting and the expanded use documented. I
suppose that's still an option as well but is somewhat more pervasive
for a bug fix release.