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
- 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.
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?
thanks
Alex