First: Have any of the folks who've done surveys of the DNS for SPF
records archived the actual records they found?
I hope so; they may turn out to be useful down the road.
On 9/17/2004 3:16 PM, Douglas Otis sent forth electrons to convey:
On Thu, 2004-09-16 at 21:58, Matthew Elvey wrote:
Comparison of SPF3 and CSV+MPR:
Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires.
Technically, it's inferior, in that its usage of DNS is less efficient
and less standards-based. MPR also has the cool bit-mapped fields for
explicit protection of 2822.From:, etc. This could be added to SPF3.
Are you referring to web-based GUI interfaces for DNS entries to support
services?
ASPs providing DNS services. (Same thing said differently?)
Looking at their documentation, it was not clear that it was
possible to enter a TXT record either.
They support TXT records.
I would imagine do-it-yourself
providers will offer needed interfaces for elements supporting their
service once it becomes prevalently needed. CSV is simple enough to
have it defined without any user intervention other than selecting the
host.
In the case of SPF1, coming up with reasonable data to feed the wizard
at pobox.com is the main stumbling block.
Given a good result from the wizard and raw access to TXT, it's easy to
put the former into the latter.
But again, the data required for a good SPF1 record (e.g that doesn't
have ?0/0) is often difficult to determine.
CSV is simpler, so if raw access to the required RR type is available,
we'd be good; with a wizard, we'd be great.
It would be a bit of a 'stub' wizard- one or two questions, tops.
It is not clear what was being compared in this sentence. I will assume
you were saying CSV is inferior. : )
Uh, no. I was saying SPF3 is inferior in certain tecnical respects in
comparison to CSV+MPR!
It was clearer when it was in context.
The SRV record is used extensively...
Use of a TXT record which encodes other
domains, users, error messages, hostnames, addresses, settings, macros,
and is extensible will require a forever evolving parser.
With more and more flavors of TXT records employed due to the example
made by SPF, as well as adopting a practice of using wildcards, any use
of an extensible text script is not without risk. Unlike other DNS
records with content defined by the record type, the TXT record should
assume opaque text strings.
Right; there's a risk-benefit evaluation to me made. I'm sensing most
people prefer to take the risk and get the benefit; but I wouldn't call
it a rough consensus yet.
Unlike SPF, names are consistently used and do not require the double
entry of host addresses as SPF may. The alternative to replicate
address entry when using SPF, is to use record references and then cause
subsequent DNS lookups to then obtain the addresses for each reference.
SPF is neither more standard or efficient. The MPR name lists also
removes the need for subsequent lookups which are the bane of the SPF
approach.
Yes, SPF is neither more standard or efficient, etc.
In SPF3, domains are consistently used, and it's more efficent than
SPF/SPF1 or SenderID/SPF2.
The MPR lists, being a separate from the MTA authentication and
authorization, avoids the problems of "open" lists that invite
spoofing. MPR can be deployed with an "open" list as a SHOULD without
any exploit concerns. By marking or "coloring" the mail as being
outside the nominal mail channel, this should offer better consumer
protection than that achieved with Sender-ID's PRA algorithm yet not
breaking mail forwarding.
This would be so greatly clarified by specific sample M.A.R.I.D.
illustrating such open lists failing!
=-=-=-=-=
With respect to being able to outright reject forgeries without breaking
forwarding:
With HELO checks + A&R, I can see this becoming reasonable BCP. Here's how:
Forwarders (and mailing list hosts) will be expected to be running
MARID on their MTA. If they are too lazy to do so, then they will be
found to be forwarding on obvious (to anyone using MARID) forgeries, and
thus their reputations will (justifiably) suffer. It will probably not
be fair to blame 'em for all spam they forward, but it will be fair to
blame them for forwarding on obvious forgeries. The responsible
forwarders running MARID can be expected to have good HELO reputations.
Is this in reference to CSV?
It's in reference to any MARID scheme relying heavily on HELO, such as
CSV, or SPF3.
I'd wager you're in agreement.
I put SPF3 up here:
http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt
as it's not up at
iietf.org/internet-drafts yet.
To save folks time, I put up
http://asrg.sp.am/wiki?action=history&id=Spf3 .
Folks may want to look at that to see a quick diff showing the
"*Substantive Changes*" between my draft and draft-ietf-marid-prococol-03.