--On Friday, 30 March, 2007 17:13 +0200 Alex van den Bogaerdt
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:
- OPES based shims, hooks
or other new SMTP level HELO/EHLO verification technology.
With the MUST NOT/SHOULD NOT approach, it is discouraging
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
I think you have written that backwards. In other words, the
prohibited test is
( DNS_lookup(A,$domain_name_parameter) != $incoming_ip_address
( DNS_lookup(AAAA,$domain_name_parameter) !=
Where "!=" is interpreted as "any of match" if the DNS lookup
returns multiple addresses.
Because contemporary DNS practices often results in multiple
names that have the same IP address in their labels but PTR
records that often identify a much smaller set of names, the
test, as you wrote it (assuming I understand your intent), would
be rather dangerous.
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.
And, to make the point even more strongly, if you don't accept
mail from any IPv4 address whose first octet is lower than 128
on Tuesdays, just because you are perverse, you can reject.
Is this correct, or not?
It is correct.
If it is correct: what is the proposed change?
I've been trying to figure that out too.