[Top] [All Lists]

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

2011-10-28 01:39:52

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:


that a MUST was appropriate for it to add a "retry=time-delay" when its 4zy rejections are greylist related.


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.




Hector Santos

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