[Top] [All Lists]

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

2003-11-01 02:47:54

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. 

"Sieve evaluation as typically implemented requires having the entire 
message on hand.
In SMTP this means the only response code that's left is the final one, 
where the server accepts or rejects the message on behalf of all 
recipients. This becomes a problem when there are multiple recipients 
and some reject the message and some do not.  In this case, reject MUST 
cause an MDN to be sent on behalf of the rejecting recipients. (Idea: 
allow MTA to tempfail the rejecting recipients and accept the others, 
until all recipients are rejecting the email; then it can be refused.)"
[I now reject that latter idea:] Is the additional complexity introduced 
by specifying how the tempfail would work to make SMTP rejects work even 
in the relatively rare case of multiple recipients on the envelope 
really worth it?  Making this mandatory would make the implementation of 
this spec considerably more work, I think.   I don't want to make it 
optional, I'd rather leave it out than make it optional.  (By the way, 
tempfail means to send a 4xx SMTP response code)  It would work as 
follows:  when there are multiple recipients and some reject the message 
and some do not, a tempfail response code is sent.  The recipient server 
has to maintain state about the message so it can recognize it when (if) 
delivery is reattempted. (some spamware never reattempts delivery!)  
When delivery is reattempted, the rejecting recipients are tempfailed, 
but the others aren't.  (This is perfectly acceptable, per RFC2821.) 
When the third delivery attempt is made, the previously rejecting 
recipients are not tempfailed and (assuming) all the recipients in this 
delivery are confirmed to be rejecting recipients, the whole email can 
be permanently refused.  (Unfortunately, some spamware reattempts 
delivery even after permanent failures!)  I'd be surprised if a spec 
requiring this would be broadly implemented, even though I think it 
would reliably provide the desired result.  I don't want to write a 
Standards Track document that never gets past the I-D stage!

I'm sorry, I think this is a direction in a very wrong direction. Just to 
wait until you have all the message and the remote MTA states ".CRLF" 
is a very dramatic effort for an MTA. It can turn traumatic since the 
filter may take more than two minutes to finish it's work, especially 
if it's so loaded because it's waiting for 500 ".CRLF"'s before filtering 
on the messages. 

Some MTA's do this though, but they usually are very streamlined for 
just that. They usually also wait for X kbytes before issuing a denial 
or keep accepting the message stream. That may be non-standard but 
implementers are known to turn corners, but I don't think RFC authors 
are allowed to. 

I think it would be better to modify SMTP ti better suit what you want. 
so who's configuration do you use?  It's only
when you are about to put a message in a users INBOX will you know that you
can take action on behalf of all the recipients (cos there is only one).

Some messaging environments have local deliver agents that can deliver 
to multiple mailboxes where the message has multiple recipients. It's very 
efficient for the messaging environment, i.e. a 'feature'. 

Yeah- what one would need to do is do an attempted delivery for
each SMTP "mail to" recipient and deal with rejections based on
that attempt.  You would have to have access to each individual's
filter program to do this.  Furthermore you would need something
other than SMTP, since once you have said "OK" to the "mail to"
you can't take it back later. 

No.  Actually RFC2821 specifies when the server takes responsibility:
"In sending a positive completion reply to the end of data indication, 
the receiver takes full responsibility for the message (see section 6.1).'
Until then, the server can drop the message and connection and be 
RFC compliant, even if it has said OK to all the recipients.
Also there is no such thing as a "mail to" command; I assume you mean 'rcpt 

I think what the originator of the "mail to" text meant is that after you 
have said "250 recipient <xxx> ok" you can not selectively take that 
statement back. I.e. you can not say later "5xx this recipient blocked 
your message". 

If you drop the connection willfully w/o trying to tell the remote mta that 
you are going to do so then you are not really rfc compliant either, but 
it's a minor offense. But the remote MTA will just go ahead and contact 
you again with the same message, what will you do then? Just keep 
dropping connections?

 Or you would have to have a way
of enforcing only one recipient per SMTP session.  (accepting
the first "mail to" and giving 4xx responses for each subsequent
one would be very hackish.)  

I would be open to something like: an implementation MAY tempfail 
recipients after the first one to facilitate per-user 'refuse' actions.  
An implementation could, for example choose to do this for mail from any 
blacklisted IPs, and safely do so even using aggressive blacklists that 
list IPs that send both ham and spam.  It's not clear whether this would 
violate any RFCs.  RFC 2821 does not allow "Rejection of messages (for 
excessive recipients)" < 100 but a 450 rejection of that sender because 
the mailbox is unavailable for policy reasons seems acceptable to my 

Same thing, you are opening your box up to a lot of connection attempts.
Don't forget, multiple rcpt to's are very efficient (for messages you want 
to receive). It would be a shame to hack it away.

In general, instead of this hacking and SMTP/MTA unfriendly behaviour, 
why not have the SIEVE script/scripts/engine respond to every command 
that is sent to the MTA. The script can then state "pass/fail" or more 
verdicts to the MTA for each statement. Wouldn't this be easier and more 
SMTP friendly than what is described above?


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