Lloyd Zusman wrote:
[ ... ]
But now, I have a new challenge: coming up with a patch/enhancement to
the filtering mechanism which will cause a message to be accepted
without any further filtering. In other words, every filtering step
would result in a three-possibility outcome:
1. Reject the message.
2. Pass the message on to the next filtering step.
3. Accept the message without any further filtering.
Since there are no 0xx SMTP status codes, it's seems to be safely
backward compatible to do special processing when such codes are
encountered. Here, they would be treated as a signal to accept the
message by returning the corresponding 2xx code to the sender, and then
to cease processing. All other status codes would be processed in the
same way as they are currently being handled.
There is a couple of other functionalities that would make sense here:
4. drop the message (currently done by marking all users as delivered)
5. give a diagnosis, in the form of a piece of data that local filters may use.
Those two points can be developed using the same kind of logic, that is
encoding the filter response in something that is not a valid SMTP response.
For that reason, I would use, say, 'A' (for Accept) rather than '0' as the
leading character. That will lead to uniform syntax that will be nicer to
document whenever more functionalities are added. E.g. a filter may return
(syntax to be refined)
"Accept; 250 accepted unconditionally",
"Drop; 251 the message will be dropped", or
"Var SPAM_GRADE=75%; 200 message accepted with some reservations".
We are still not allowing a filter to change the MIME text of the message,
but paving the way to a more significant enhancement.
Shall I provide an alternative patch?
13 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: Interaction b...
.patch
