John C Klensin wrote:
Hector Santos wrote:
One may suggest SMTP did document the basic idea of
greylisting by using the term "temporary" for a 4yz reply
code. It just [kept] it open ended and did not get into ideas
of what is "temporary" and/or how it relates to "time."
..
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:
RFC2821:
450 Requested mail action not taken: mailbox unavailable
(e.g., mailbox busy)
RFC5321:
450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons)
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 persistent.
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.
But I am still concern about the idea of parsing text. No one here
rejected it but it may come up under IETF/IAB review if it got that
far - I know if I was part of the review board I would raise that
question.
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?
Off hand:
- FTP has the parsing for the data port establishment.
- POP3 as the parsing for the totals, indices, etc.
- NNTP also has similar parsing of numbers.
But we don't any think in SMTP that comes comes to parsing text for
anything, as far I think of right now.
--
Sincerely
Hector Santos
http://www.santronics.com