[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-30 04:03:47

Hector Santos wrote:

Conversely, it would be require a change in thinking here, but in my view, not breaking the spirit of promoting the primary focus of assuring delivery, if it was "MAY REJECT", I think it will fit better today without making developers feel that they are violation specs because they are not following the MUST NOT recommendation. The difference is that delivery should come with proper SMTP compliance. I [do not]
> think that this breaks the overall spirit of maintaining the email
> connectivity.

One final thought I forgot to mention.

One reason I think this might be better, using a MAY REJECT semantics as oppose to a "MUST NOT reject" or "SHOULD NOT reject" is to help promote new and future generation SMTP augmentation software such as:

 - SPF
 - OPES based shims, hooks

or other new SMTP level HELO/EHLO verification technology.

With the MUST NOT/SHOULD NOT approach, it is discouraging future development.