On Mon, 2004-06-14 at 15:53, James Couzens wrote:
<snip>
Now can anyone see whats wrong with this picture, because *I* for one
certainly can. So I am supposed to link a 1.3M library against my MTA,
___JUST___ to validate senders? Can someone please explain this to me?
I would ask why XML is even being considered but I'm not out looking to
start a flame, I simply would like to illustrate to everyone here that
there are some very deeply wrong things with XML, completely outside the
realm of publishing XML within DNS.
XML needs more characters to encode data than an encoding scheme
specifically designed for CIDR information for outbound SMTP hosts.
Something like BGP comes to mind. By making the XML headers virtual,
standalone, and cast in stone by the standard, then it should not
require an XML parser for the records as the syntax should then be
fairly simple for basic scripts.
This is not likely to happen however, as there is a desire from some
vendors to leave this header open while claiming not to understand the
meaning of 'standalone' in the XML standards or accept a concept of
keeping this record definition a function of the standards process. The
reason is to rapidly evolve this record, their stated goal, likely into
a largely proprietary format where the size of the record will grow well
beyond reasonable limits for DNS. Their previously stated limit for this
record was 2 K bytes and then changed to no limit. : (
In this regard of size, I was not happy to see a macro language added to
SPF. Simple error messages as part of refusal or standardized header
notices could offer the same information. These errors should be
enumerated to the degree needed and include related fields.
There is also a concern as to the number of queries needed and how many
times a record can be dereferenced. If this becomes even moderately
used, it will seriously limit an ability to handle a mail stream with
the number of transactions. Looking within the message is also based
upon trust. To enable such trust, trust is forwarded to other entities,
or taken over by rewriting parameters as a means to claim trust. As
proposed, there is no means to publish a comprehensive list of such
relationships or to detect breaks in this chain. It would be better to
stop mail at its source rather than "perhaps" stopping a bounce.
If this even remotely puts a dent in the amount of mail abuse, expect
the system to be taken to its knees by the complexity allowed in the
standard.
-Doug