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
- CSA/DNA
- 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.
--
HLS