[Top] [All Lists]

Re: Sieve reject at SMTP time possible with which implementations?

2003-11-01 15:04:41

On 11/1/2003 1:47 AM, Guðbjörn S. Hreinsson sent forth electrons to convey:
<various folks> said:

The problem with filtering before storing in the end users mailbox is as Ned
says, the concept of the mail envelope.  At the SMTP level, the envelope
probably has many recipients,
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.) 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. 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.

"Sieve evaluation as typically implemented requires having the entire message on hand....
Yes, Cyrus Sieve is likely to stay that way, I'd wager. But, any Sieve script evaluation that doesn't use the (not-yet-standard) body test can (potentially, that is it's possible to code any implementation so that they) run as soon as the header has been received.

And apologies to Mark - I think I misunderstood what he was communicating and should have been more friendly than I was - especially as I don't want to discourage feedback.

<Prev in Thread] Current Thread [Next in Thread>