Hector Santos wrote:
check out this *published book" with an entirely different
(and very logical) interpretation for 1yz:
http://www.tcpipguide.com/free/t_SMTPRepliesandReplyCodes-2.htm
Maybe it's only me, but I've never before heard of this book
and the author. Aren't we all trying to figure out how stuff
works, or how it's supposed to work, where the answers to both
questions are at best related ?
Nothing's wrong with your concept as new concept, we could
of course still discuss if there are better solutions. But
it MUST NOT be imposed on existing clients and servers in
the SMTP standard when it breaks existing implementations.
You'd have real difficulties to find somebody who's more
conservative than me wrt backwards compatibility. I often
say "real SMTP" when talking about RFC 821 reverse paths,
as opposed to the postmodern 1123 5.3.6(a) spam universe.
If you find a source written by Jon Postel I'm all ears.
Sendmail's VERB is apparently compatible with 2821bis-02.
Nitpicking typos:
- 1yz Positive Preliminary reply The command has been
+ 1yz Positive Preliminary reply: The command has been
- 2yz Positive Completion reply The requested action has
+ 2yz Positive Completion reply: The requested action has
- 3yz Positive Intermediate reply The command has been
+ 3yz Positive Intermediate reply: The command has been
- 4yz Transient Negative Completion reply The command was
+ 4yz Transient Negative Completion reply: The command was
- 5yz Permanent Negative Completion reply The command was
+ 5yz Permanent Negative Completion reply: The command was
Yeah, that's stupid, the RFC editor could fix it anyway, but
I think that 2821bis should be a show case. As you said
nobody will ever touch it again. It goes straight to STD
if they get issue 21 right. And after all that's possible,
for the "IPv6 only" case I'm less confident.
If makes you wonder why the AUTHOR wrote this
Not really, anybody is free to write whatever they like, and
nobody is forced to read it. Maybe the author copied a piece
of text from ftp, see:
http://www.tcpipguide.com/free/t_FTPRepliesReplyCodeFormatandImportantReplyCodes-2.htm
Another author wrote this, easy to guess what I believe:
| The command has been accepted, but the requested action
| is being held in abeyance, pending confirmation of the
| information in this reply. The sender-SMTP should send
| another command specifying whether to continue or abort
| the action.
|
| [Note: SMTP does not have any commands that allow this
| type of reply, and so does not have the continue or
| abort commands.]
Frank