> One might imagine cleanup sending a negative reply as soon as it > is available, and smtpd(8) peeking at the cleanup(8) socket before > calling end-of-data checks, which can short-circuit end-of-data > checks for mail rejected by header/body checks and content processing > in milters. However no such code exists at this time.
Ok, that's all a bit annoying. I see that there are smtp_header_checks that must run during the smtp sending phase, would it be worth adding smtpd_header_checks (with some restrictions likes the smtp_* ones) that run in smtpd during the message reading phase? Alternatively, would it be possible to add a "run_cleanup" action that could be put in smtpd_end_of_data_restrictions to explicitly run cleanup and wait for the response? So you could have: smtpd_end_of_data_restrictions = run_cleanup check_policy_service ...blah... That way people can at least explicitly choose if they want to run the cleanup actions before the policy check rather than the implicit check that's done at the very end. Alternatively, I guess you could add something like a smtpd_end_of_session_restrictions that runs after the cleanup commit is complete? > In the mean time you can replace the end-of-data checks and header > checks with a milter that does both the header checks and the > requisite end-of-message processing. Replacing a long term extremely well tested policy daemon and having to rewrite it as a brand new milter protocol daemon just to solve this one particular case is, to put it a bit mildly, really annoying. I'd prefer to come up with a patch that implements one of the above solutions, but I'd only do it if there's some hope it might be accepted upstream. We already maintain a few of our own patches, but I obviously prefer to minimise them... -- Rob Mueller r...@fastmail.fm
