Chris Lewis escribió:
Functionally, just about anything you can do here you can do just as
easily with a data_post plugin.
- By putting your header checks in this hook, you can more explicitly
control sequencing and enable/disable of header versus body checking.
_However_, you can do this just as easily by ordering of config/plugins.
Eg: I don't have any problem now disabling body scans (eg:
spamassassin/clamav/ad-hoc string filter) if I decide to block based on
a Subject string filter plugin.
I get your point. I'm not all that sure about dropping a connection in
the data stage myself, but it's always good to have the option ;) ...
Having this hook can permit a couple of tricks also. If I don't remember
badly, when you're in the data hook, you have spooled the entire message
to disk, so you have to seek(0), and then read the headers. In the
headers_hook, you potentially have them in memory. Maybe (DANGER AHEAD!
I'M JUST THINKING OUT LOUD!) if you're sure you don't want the message,
you can continue accepting lines from the client, but just obliviate
them, so you don't even pay the penalty of disk I/O while spooling the
message.
[Note previous thread regarding common inter-plugin communications.]
- It _might_ provide an opportunity for reduced latencies by partial
overlapping with reading the rest of the body.
+1
- If you try issuing rejects/disconnects here (in the midst of DATA
transfer), very bad things might happen with certain very badly written
yet still legitimate-purpose MTAs. Eg: woodpeckering.
I think it's all up to the developer and the responsibilties he's
willing to assume. After all, he could come up with a scheme that
detects if a legitimate MTA is resending the same message that was
dropped before, and then accept it.
Regards,
Jose Luis Martinez
jlmarti...@capside.com
