[Top] [All Lists]

Re: RFC2821bis-01 Issue 3: EHLO parameter

2007-03-30 08:30:11

On Fri, Mar 30, 2007 at 06:50:07AM -0400, Hector Santos wrote:

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 

I have trouble following this thread, and I could be wrong about my
interpretation of current 2821, so that's why I am asking this in
simple words:

I believe the current spec allows rejection, except for one clearly
defined case:

DNS_lookup(PTR,$incoming_ip_address) != $domain_name_parameter

In this particular case, section 4.1.4 says MUST NOT refuse.
Rejection based on other knowledge is (implicitly) allowed.

If a client uses my name, or my IP address, I know for sure that
this is not the client's property, so I can reject.  If protocols
such as SPF say the client is not authorized to use this domain
name, I can reject.  If the parameter is not a FQDN nor an address
literal, I can reject.

Is this correct, or not?

If it is correct: what is the proposed change?