[Top] [All Lists]

Re: 4yz Temporary Rejections is part of the SMTP Protocol

2011-10-28 08:49:15

--On Thursday, October 27, 2011 19:25 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

As I tried to say in an earlier note, whether use of 4yz codes
in an attempt to block spam, or even as a traffic control
measure, is a clever extension of SMTP to use an existing
feature in a new way or a serious conception abuse of the base
protocol is mostly in the mind of the beholder.  But I don't
think it moves things forward to pretend that this sort of
usage was there all along.  

I agree, but it did evolve to include local policy user and/or
system wide considerations.   You can see this with the change
in 450:


    450 Requested mail action not taken: mailbox unavailable
        (e.g., mailbox busy)


    450  Requested mail action not taken: mailbox unavailable
         mailbox busy or temporarily blocked for policy

Yes, definitely.

I'm not suggesting it, but, to the extent to which SMTP
extension are involved here (rather than a description of how
to use the base protocol in a particular way and improve
interoperability if it is used that way), one could even
thinks about a new series of reply codes for traffic
management of various types (6yx?  9yz?) rather than trying
to do tricky things with 4yz.  

I consider this and even a special extended status code but
stopped because the key part of the SMTP extension is parsing
the response text, which as far I am aware of, there are no
known SMTP practice to do so (outside of proprietary or
localized) due to the idea we can't rely on it to be

I'm not sure what you mean.  Certainly the responses to VRFY and
EXPN have to be parsed and 5321 is moderately specific about
their syntax.    For other commands, yes, the pattern has been
to try to be sure there is no need for information in the
response text that isn't in the codes themselves.  If nothing
else, that facilitates both machine processing and localization.

Honestly, I was surprise I have didn't get any resistance
based on that concept (parsing of text) alone because frankly,
it would be very hard to argue against and might have been a
show stopper for me.
But the atmosphere did not reject the idea, hence I went
forward with the "reply=time-delay."  It helped that there
were already GL servers out that already supply an informal
time in in their responses.

The SMTP extension model clearly allows for doing just about
anything.  Either coming up with a new first-digit reply code
and associated text model or modifying an existing code would be
consistent with "just about anything" as long as the conditions
for advertising and accepting the extension are well-documented
and the interactions with legacy (un-extended) systems, if any,
are well-understood.

By contrast, taking a reply code that is specified in the SMTP
specs and in wide use without clients needing to interpret text
and hoping that some specific text will be given particular
treatment would almost certainly be a terrible idea.  But I
didn't understand you to be suggesting that.

Whether it is a good idea or not is a separate issue, for which
the comments of others that the discussion hasn't really started
are relevant.
What do you think?  or do we have enough history, including
amony the other internet client/server text based protocols
that provides some protocol for a format text structure
command response output?

Again, we do it already with the VRFY and EXPN responses, so it
is nothing new in that regard.  But, while the syntax of those
responses has gotten more specific over the years, the intent of
the reply code and information returned as its text really is
not.  Other protocols built on the FTP model are, IMO, less
interesting because each has its own rules.  And, again, if one
were planning a clean extension rather than a trick, moving to
either a new code structure or, e.g., a 46z code (with x6z
defined as "server traffic or connection management requests")
would have a certain amount of appeal. 



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