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
to'.
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
reading.
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
elaborete
verdicts to the MTA for each statement. Wouldn't this be easier and more
SMTP friendly than what is described above?
Rgds,
-GSH