ietf-smtp
[Top] [All Lists]

Re: 2821bis AUTH48 fix (?)

2008-08-16 09:07:32




--On Friday, August 15, 2008 6:07 PM -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

>> Unless it did so as one of the "shutting down service" or
>> equivalent messages.  I.e., 450 might make sense, other 4yz or
>> 5yz codes would be very unusual.
>
> 452 insufficient reousrce sorts of codes are also a
> possbibility here.

But I would stand by "unusual" in the sense that an insufficient
resource status ought normally to be detectable, and probably
should be reported, earlier.

THat depends on the resource. Queue space whne the SIZE extension is used is a
good example. Depending on how the queue is organized an MTA may not be able to
compute the amount of queue space needed until it's sure the recipient list is
complete. Since DATA signals the recipient list is complete, it's the logical
place to perform such a check.

The unusualness of this case is really more a matter of modern systems being
sufficiently endowed with storage that they rarely run out.

I did not mean to suggest it
couldn't happen (in particular, race conditions are clearly
possible) or that the standard should prohibit those other codes.

>> Of course, if there were no
>> valid recipients, even "command out of sequence" (or
>> equivalent) would be plausible.
>
> Other permanent failures are also possible, e.g., various
> things along
> the lines of "Something you have said caused me to hate you
> and I'm rejecting this tranaction in toto".

Which, again, would "usually" be delivered after MAIL or some
RCPT command ("if you are trying to send to _her_, I hate you
and...").

Again, it depends on the check. A "more than this number of recipients causes
summary rejection" check, or a "sending to this poisoned address marks you as a
spammer" check cannot be enforced prior to the condition being tripped.

The unusual and edge cases are why there is so much flexible
language in 2821/ 2821bis and I would resist  removing that
language --or inserting new rules to badly constrain the cases
that require the flexibility -- as, or more, strongly than you
would.

Agreed.

                                Ned