Re: [ietf-dkim] Re: DNS wildcarding behavior scenarios

On Jun 18, 2007, at 3:03 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > Both wildcard and non-wildcard records need to be placed at  
> > _every_ valid node existing within the zone.
> Yes, thanks for the correction, the wildcard counts as "at", not as  
> "below".  I had that wrong.  But the opposite was hopefully okay, a  
> wildcard above an existing node isn't visible at or below this node.
> IOW to cover everything below x.example you'd need wildcards at all  
> existing nodes below x plus x itself.
See RFC 4592.  A wildcard will blocks itself.  Both a wildcard RR and  
a non-wildcard RR record is therefore required.  Synthesis is  
prevented at any existing node, terminal or not.
> For SPF it was simpler to ignore the issue, nodes without MX and  
> without IP anyway can't send mail, or rather they can try, but it's  
> possible to reject this crap. For SPF you only need wildcards where  
> they already are (MX, A, or AAAA).
> No recipe for SSP unfortunately, nobody checks 2822-From addresses  
> for plausibility at the MX, rejecting anything that can't be okay.
Sender-ID depends upon these SPF records and refers to email- 
addresses within 2822-From addresses.  It seems many limit email- 
addresses to the Internet namespace.  While some systems may utilize  
a different namespace, whether this namespace is accepted and what  
determines the policy associated with this namespace is outside the  
scope of SSP.  An email-address within the Internet namespace must  
resolve a discovery record, or it is not a valid Internet email-address.
DKIM uses only an Internet namespace, however SSP should be able to  
make exceptions.  The general goal behind DKIM is to curtail invalid  
email messages.  A message containing what the recipient considers an  
invalid email-address is also likely to be considered an invalid  
message and refused.  Establishing what is a valid email-address  
establishes a basis for acceptance, and hence limits where policy  
records must also be published.
There are significant advantages in allowing SSP to selectively apply  
to just parameters seen within the RFC 2821 envelope, the SMTP client  
hostname and the MAIL FROM.  This could then allow namespaces to  
safely mix and still simplify where policy must be checked.
To further minimize locations where policy records are checked,  
deprecate A record discovery.
This deprecation offers two significant benefits:

 1- Policy can be referenced from only MX record locations.
 2- CNAME discovery (allowed with A records) is also deprecated.

-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html