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.