In
<1086793209(_dot_)27362(_dot_)30(_dot_)camel(_at_)betelgeuse(_dot_)theinternetco(_dot_)net>
Aredridel <aredridel(_at_)nbtsc(_dot_)org> writes:
With the appending and prepending of XML namespace attributes, the most
expensive part of XML is avoided being transmitted: It is merely
implied. That's a big boon, a big plus over the Caller-ID draft. The
remaining XML is a bit more verbose than SPF's syntax, though not really
much. It will only affect the cases near the edge anyway, which is
avoidable through a multiple lookup, just as in SPF. It just lowers the
bar a very few tens of characters.
I'm not sure how you can claim that the XML representation of SPF is
only a few tens of characters more than the SPF syntax. First,
nothing with the XML representation is finalized, a problem in itself,
so it is nearly impossible to measure. Second, the reason why the New
SPF XML representation currently is as small as it is is because much
of the terse SPF syntax remains. In particular, you still have to
parse the CIDR notation and the macro variables.
But, let's take a look at the costs of XML:
In SPF, each mechanism or modifier is separated by spaces, usually
just one. So, the cost is 1 space + the length of the mod/mech name.
For example, " a" takes up 2 characters.
In XML, the equivalant of " a" is "<m><a/></m>", or 11 characters.
In XML, the mechanism name appears twice if there is any data
(e.g. <a>example.com</a>) while in SPF, there is just a colon, so add
in a few characters there.
In XML, you need to bracket the document with <ep><out> ... </out></ep>
while in SPF, you need to prefix the document with "v=spf1", so add in
14 characters.
In XML, the equivalent of " -a" is "<m><a result="deny"/></m>", which
is 22 characters longer.
How this will total up in real world usage, I'm not sure. The spec
isn't finalized enough for me to really evaluate it.
It is also important to remember that the 512 byte UDP packet size
limit on DNS doesn't mean you can have 512 bytes of email policy
text. UDP headers have to be taken into account, as do the DNS
headers. The DNS packet will also usually contain other records, such
as name servers. All told, you are looking at at least 100 bytes, and
sometimes around 200 bytes of overhead. So, when you are dealing with
only 350-400 bytes of usable space for your email policy, even "a few
tens of characters" is a large percentage.
If you want to avoid
a full XML parser, a minimal subset for the spec will do a lot, so
that's not really an issue, either. It's about as bad as SPF in the
first place.
NO!
NO!
NO!
Geez, how many times does this have to be pointed out?
The whole point of XML is that you can extend it. If all the SPF-ID
implementations don't use complete XML parsers, then they won't be
able to deal with extended XML documents.
- Once a message passes 2821 tests and we allow the SMTP-client to proceed
to DATA, it is to our advantage to identify any _inexpensive_ tests that can
be done that permit us to reject at the end of DATA. We should look for
these opportunities because it is better to reject at the end of DATA than
to discover the problem later and silently drop the message.
Absolutely. Avoiding DSNs is a good thing.
If you use SPF, instead of SPF-ID, then you can do post-accept
rejections (bounces) without the problems of the bounces going to the
wrong people.
While avoiding generating bounces is a good thing, and always will be,
it is not always possible. Especially in large organizations that
have many internal MTAs and complex email infrastructures.
-wayne