Jose Luis Martinez wrote: > Robert Spier escribió: >> The patch itself looks fine, I'm not sure whether we actually should >> support this or not. >> > > Why not? After all, if you don't need it, you don't use it. What about a > warning in the docs saying something like "be careful! If you drop the > connection: legal MTAs will retry, spammers will probably not". I'm sure > you can do even nastier things within plugins code, and this hook can be > helpful for having plugins that want to set a note for later dropping > the message (if you want to be RFC compliant), or just saving processing > time not doing antivirus or antispam checking just looking at the headers.
To riff on this a bit: 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. [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. - 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 don't see a problem with adding it per-se. It'd make my plugins/config file ordering a trifle simpler, but it doesn't really add any functionality. I agree there should be a big warning about rejects/disconnects potentially being very dangerous.
