IME, most standard protocols (at least the goods one) where designed
with the idea of flexibility and growth. If being creative is part of
that process, then it was successful in its intent.
By your definition, writing SMTP extensions is a creative
interpretation of the standard SMTP process which was meant to be
locked in to any one particular method of usage. Nes Pas! And I
believe you meant that.
We can only work with a common backbone mechanism that can not
deviate. The SMTPGREY extension does not alter that. The questionable
new issue, the "moving cheese" so to speak is using the text part to
add more server information for the client to read because SMTP is
currently is incapable of providing more response information outside
the reply code. With the exception of Extended Status Code, its
client/server negotiation capabilities are limiting and not backward
compatible.
But it does not mean we can't use the text part because the Extended
Status Codes standard proves we were willing to read more beyond the
just the standard SMTP reply codes. Compliant clients can use the
EXTENDEDSTATUSCODE to definitively get that "signal" that parsing text
is possible for these special extended sections.
So what is different that a GREYLIST SMTP Extension Keyword offering?
Really not that much difference idea.
One can make a note that the special reading is only possible when the
GREYLIST service keyword is presence. Lets get that RFC2019 lingo
correct.
I currently have it that its all optional because I did not wish to
limit it to just EHLO sessions but also clients who issue HELO. The
only MUST is when the server issues:
250-GREYLIST RETRY
that a MUST was appropriate for it to add a "retry=time-delay" when
its 4zy rejections are greylist related.
--
HLS
SM wrote:
Hi Hector,
At 16:25 27-10-2011, Hector Santos wrote:
considerations. You can see this with the change in 450:
The subject line says "temporary rejections". The term used in the SMTP
specification is "temporary error status code".
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.
The hunting season is not open yet. :-)
From RFC 5321:
"Unfortunately, variations, creative interpretations, and outright
violations of Internet mail protocols do occur; some would suggest
that they occur quite frequently."
The draft discusses about a creative interpretation of SMTP. Dave
Crocker commented on why greylisting works [1].
BTW, RFC 1651 has been obsoleted by RFC 5321. The correct reference for
DKIM is RFC 6376.
Regards,
-sm
1. http://www.imc.org/ietf-smtp/mail-archive/msg06860.html
--
Sincerely
Hector Santos
http://www.santronics.com