ietf-mxcomp
[Top] [All Lists]

Re: consensus call on pra/mailfrom deployment and versioning/scope

2004-09-09 17:08:34


IMO, the scope should be implicit from the specification.

 "Implicit" instructions in specifications have historically meant
inter-operability problems, and security flaws.

 The specifications exist to make scope/intent explicit.  Adding a
few more sentences to clarify the scope would be a good idea for any
specification.


Of course and I my suggestion is completely consistent.  Read on below to the 
end...

The point I am making is not against specifying the scope of the data being 
exposed, but against specifying multiple scopes in multiple records, because 
this will lead to confusion, fragmentation, etc..  Some examples of possible 
confusion:

1. "Why are there two different ways to specify the approved mail servers for 
my domain?"

2. "Which is better?"

3. "Which is required?"

etc..

You create a proliferation of issues, proliferation of debate, proliferation of 
DNS records, proliferation of competitive issues, ... in short, you do not 
create a useful standard.

If there is a compelling technical reason to need multiple scopes on the DNS 
record, then you can consider the tradeoffs.  There is no compelling technical 
reason.




And if so, do you actually think it is better for the receiver to have 
to guess the intended scope of the sender?

Yes because inherent in the design of the specification should be
acknowledged the *REALITY* that the sender can not control the
receiver (verifier).

 Control is different from intent.  MX records in DNS are intended to
be used as destination IP's for SMTP traffic to a domain, and that
intent is explicit in the specifications.  Yet nothing stops anyone
from doing:

$ ping `host -t mx example.com`


Your analogy is comparing apples to oranges.  In the case of MX records, the 
scope specified is a 100% solution to the need that it is for.

In the case of per-domain anti-forgery authentication, all the current 
algorithms for processing the approved mail servers DNS record do not give a 
100% result.  Thus it is impossible to declare the *FINAL* scope.  No one knows 
today what the *FINAL* scope will be.

Instead the best we can do is declare what the data that is being exposed means 
and what it is intended to be used for.

In short, with MX there is no compelling need to use the data in any other way 
than the exact scope specified.  Whereas in our case, the data is going to be 
used in creative ways to accomplish the goals of the receiver.

And I assert that by fragmenting the scope into multiple DNS records, you will 
actually have the reverse of the intended effect.  Instead of limiting scope, 
you will cause all sorts of adhoc algorithms to try to give the anti-forgery 
results desired by recipient based on multiple records.

It seems your logic above assumes that recipient will only deal with one DNS 
record orthogonally.  So what does recipient do with multiple scopes?  What 
does recipient do when the result from scope(s) is neutral or error or 
inconclusive?


 For MARID issues, the intent of the publisher of the records should
be made explicit in the specifications, if not the protocol.  For the
vast majority of recipients who use the records as expected, having
that intent explicit makes their jobs easier.  For the recipients who
don't follow the publishers intent, it makes no difference to have
that intent explicit, because they won't follow it.


Make explicit how I can deal with the case with PRA where the Resent-Sender: is 
not forged but the From: header is forged?  Ditto for MAILFROM: and From: in 
SPF?

Make explicit how I can use the the results from either scope algorithm to help 
fight spam?

Make explicit how I can combine multiple results from multiple scopes?


I think it would be folly and brittle for us to attempt to specify
*ALL* the ways that the data in the DNS record can be used and
interpreted, ...

 Similarly, it would be follow to specify *no* standard way for the
data to be used and interpreted.


We should specify what we can specify.  But adding uncompelling scopes when it 
is the same underlying data is not useful.


 There is a happy medium.  We should find it, and use it.


Agreed.  I think that happy consensus medium would be to specify the approved 
mail servers for a domain, and then specify some of the possible algorithms 
that might be applied by receivers.