[Top] [All Lists]

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

2011-10-27 18:41:53

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:


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


   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.


Hector Santos

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