[Top] [All Lists]

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

2003-11-02 03:19:11

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 

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. 


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