----- Original Message -----
From: "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <ietf-smtp(_at_)mail(_dot_)imc(_dot_)org>
Sent: Saturday, March 27, 2004 8:27 PM
Subject: Re: deferred RCPT responses
I'm specifically referring to scenarios where:
1) the envelope loop identifies multiple recipients
2) the recipients are valid and would normally return 250
3) each recipient has different policies for the message body
The envelope exchange loop currently only deals with 1 and 2.
The data transfer logic currently only applies to the transfer process,
and not to the delivery process.
So... there's no way to say "I'll accept the message for this user, but
not for that user" after the envelope loop has completed.
I understand your point. If you are proposing that the DATA responses offer
RCPT rejection, then I will support it. But as you said, its not standard
practice. I might be wrong, but I think YAHOO does this, not sure how they
handle a mailing list though. But they do delay the RCPT rejection until
DATA is reached.
I just think SMTP is complicated with mail content interpretation. You are
really only left with mail acceptance with bounce potential.
Lets say we have 4 users which the following example restrictions:
user1(_at_)example(_dot_)com allowed 5 messages
user2(_at_)example(_dot_)com allowed 10 meg storage
user3(_at_)example(_dot_)com No Porn
user4(_at_)example(_dot_)com no restrictions
For user1, RCPT has to logic potential to reject user1. It has the ability
to count what would be become 6th message and reject this user.
For user2, SMTP has the potential to restrict if the SIZE attribute was
added to MAIL FROM. If not, it has to be accepted or rejected at DATA once
the type bytes are known. But this can kill user3 and user4.
For user3, SMTP needs to accept the message. You can't reject at DATA
because it will might kill user2 and user4.
For user4, no restrictions so mail delivery is desirable for this user.
The most problematic issue in the example above is the storage limit
enforcement. Lets say the email would be within the user1 limit, and it is
not porn but the size is enough to put user2 over. If SIZE was not
provided with MAIL FROM, then you can't use DATA to reject this.
So, you really have no choice but to accept the messages and have potential
bounce conditions.
But overall, IMTV, this has nothing to do with SMTP. Ours examples are
exactly why we need to remove all fuzzy mail content interpretation concepts
from the SMTP mail transport level, so that you won't have these and similar
type of issues. However, that doesn't say some level of logic can be
applied to the DATA state where it might apply some system level user
policies concepts. But as you say, it doesn't cover all.
Can DATA cover this this?
Again, not smtp related. A system has various ways to handle this, but it
has to accept the message:
a) Put user2 mail on hold and send a MAIL ROOM message to user2 saying
something like:
"your storage limit as been exceeded. 1 message(s) on hold"
b) Accept the message, the first time, then mark user2 for future RCPT
rejections.
Now lets throw in another issue: Viruses?
If the email was detected at the DATA stage as an virus, then the
transaction is can be "legally" rejected for all. I see no problem with
post smtp rejection to the waste bin as well (no bounce), but only for this
level of malicious mail and these types of systems are best serve by moving
the AVS logic to the data stage and couple that move by upgrading to a
high-performance SMTP server.
But beyond that I think it is asking for trouble, don't you think?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com