On May 21, 2012, at 3:26 PM, Jared Johnson wrote: >> There's several plugins that have something like what you've suggested: >> >> plugin action [ add-header | deny | denysoft ] >> >> And here's a sampling of the arguments that various plugins use with >> action: >> >> add-header, log, continue, reject, deny, denysoft, accept, delete, add >> >> Reject has a simple, explicit, and universal meaning in every plugin, and >> thus my preference for it. > > This makes sense to me, but what I thought I had seen come down the line > (and what I just noticed in another commit, at any rate) was that 'reject' > is not exactly boolean; it's tied to the reject-type field.
When I use reject, it's a toggle switch. When we set reject 0, then the message gets past that plugin. Period. When we set reject 1, (or any true value) the message does not get past that plugin. Period. I purposefully made the switch binary to help resist the tendency of options to get overloaded over time. Speaking of that, I have already made one extension in the dspam plugin, where there's also a reject agree option. But agree is still a true value. It just makes the rejection conditional on whether or not SpamAssassin also agreed the message is spam. After we've decided to reject, it might make sense to offer options for 45X, 55X, or disconnect options. For that, I've been using reject_type [ temp | perm | disconnect ]. I think those terms are the most precise and readily understood. > it seems like > this field is just as easy to get crufty over time as the 'action' field, > although it at least has fewer potential values. I would contend that > reject=1,reject_type=defer is not really rejecting at all, which makes it > confusing that you have to "turn on" rejection in order to defer. > > I have to admit I haven't been reading your patches closely, so I could be > missing things that make this an obviously better idea than I'm > perceiving. I might have just kept my mouth shut, but I thought I'd see > what you think :) I would counter that reject_type defer is a form of rejection. It's a mild one, and we are not necessarily rejecting the message, but a deferral is rejecting the connection, temporarily. Which is why I used the syntax reject_type temp instead. The terms I chose apply to the message and the connection. They are also very flexible. I had considered reject [ 0 | temp | perm | disconnect ], but that's much more complex for anything but than the simple cases. It requires gymnastics or a long list of options to allow one to choose a temporary deferral when dspam & SA agree (instead of the default permanent rejection). Well, that's as much thought as I've given it. Thanks for the questions though. It made me think this through better when you first asked. :-) Matt
