Re: Re: Problems with spf testsuite and dns specification

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> Julian Mehnle ha scritto:
>>> Stefano Bagnara wrote:
>>>> IMHO the problem is not "to compact or not to compact". The problem
>>>> is requiring a PermError (a specific different action) on something
>>>> that the DNS spec tell us is not different from a single record.
>>>> To use your "question": show me any other DNS application that
>>>> specifies a different behaviour on multiple identical RRs ;-)
>>> SMTP, MX records.  Multiple identical RRs make a typical SMTP client
>>> perform multiple lookups, not one.  At least, RFC 2821 section 5
>>> doesn't specify any MX RR compaction.
>> Well, on SMTP you will find me prepared as I'm a developer of Apache
>> JAMES SMTP server :-)
> 
>> rfc2821 DOES NOT add any specification related to multiple identical MX
>> RRs: it simply rely on what the underlying DNS implementation do, as it
>> is supposed to.
> 
> Exactly.  And if an SMTP client receives...
> 
>   example.com.  MX  10 mta.example.com.
>   example.com.  MX  10 mta.example.com.
> 
> ... then it will likely behave differently than if it had received just 
> _one_ of those records (i.e. it will try to connect to mta.example.com two 
> times if that host isn't reachable).  RFC 2821 does NOT specify that such 
> identical records must be treated as a single one.  So why should RFC 
> 4408?

There is IMO a big difference:

- The behaviour of an SMTP client does not change too much depending on
DNS consolidation: that mx server will be tried anyway, and the fact
that is tried one or multiple times already depends on implementation
details (e.g: the SMTP specification is already very relaxed about
interpretations of whether the use multihomed servers - multiple IN A
for the same MX host name - should be iterated or not, so I don't really
see this issue at the same level of the rfc4408 issue. Also how many
servers to check before giving up is left to the implementor)

- Instead in the case of rfc4408 the result is completely unpredictable:
if the dns chain consolidate the results then the SPF client will check
the SPF rule as valid, otherwise it will return a PermError.

Btw I think we can discuss similar interpretation for years with not so
useful results ;-) .. I think at least 2-3 guys here agree that the
testsuite should be updated and maybe some clarification text added to
the specification, let's work on this :-)

Stefano

>> The important thing to be noticed is that SMTP does not add any
>> specification that will alter the final behavior in a critical way
>> depending on the underlying dns chain "compression" policy.
> 
> That's true.
> 

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com



-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=6959932&user_secret=62b4c45f
Powered by Listbox: http://www.listbox.com