s/probably/very occasionally/, so it's not as much of an issue. I think
a 'refuse' that works perfectly as long as there aren't multiple
*envelope* recipients (which, keep in mind, is much rarer than multiple
recipients of any kind) ( and handles the special case by causing an MDN
to be sent on behalf of the rejecting recipients) is much better than no
'refuse' at all.
Having multiple RCPT TO's is quite common. What you define as much
better is false-positive which for me would be much worse. I would rather
have a filter miss than a false hit.
No, there is no false positive. The non-rejecting recipients get the
message. (The rejecting recipients don't, but that's their intention.
Labeling that a false positive 'refuse' isn't correct, no matter how bad
the reason for the rejection.)
Forgive me. I though from reading your message that the intention was
to refuse the whole message (all routing recipients as specified by the
RCPT TO's) after the message has been "sent" (as by sending the "."
and CRLF) by sending a "5xx Filtered xxx".
So to understand this. SIEVE will reject per RCPT TO at the time
of the RCPT TO? Not later.
Multiple RCPT TO's on email that some folks would refuse with Sieve is
far from probable, for every user population I can think of, and
certainly for all of them considered together, but sure, it happens.
I think any efficiency lost by restricting multiple RCPT TO would be far
outweighed by the efficiencies gained by 'rejecting' spam instead of
'refusing' it.
So you want to perform the above by only having a single RCPT TO
per submission? Does that include the session? Do you allow RSET?
I think the net computer resources used would be reduced, and far more
importantly, the net human resources used would be reduced.
I think there's is zero chance to "modify SMTP" or turn Sieve into a
Mieve that can direct every stage of an SMTP session.
Let us know of any objections you still have to the multiple RCPT TO
scheme currently specified by the spec, which is to simply accept the
message when at least one RCPT TO wants it, causing no false positives,
as discussed above.
Ahh, ok. So a single "positive" for any RCPT TO will outweigh any other
RCPT TO. So if I have a filter, the filter "hits" on a specific RCPT TO, but
not on any other RCPT TO, the message is allowed through?
But what's the point then? If this is for catching SPAM messages I think
they will get the message very quickly and circumwent it...
Furthermore, if you filter on the whole message and then check for the
RCPT TO's applicability to the filter you are probably wasting a lot of
resources.
My feeling is there are too many IFs here. This kind of thing needs to be
analyzed and verified as to what effect it may have on SMTP servers.
Rgds,
-GSH