DC> Date: Mon, 9 Aug 2004 15:08:12 -0700 DC> From: Dave Crocker DC> DAU>> I don't think SPF is worthless [1] but it isn't a drop-in DC> DAU>> solution and the impact on infrastructure will be DC> DAU>> significant if it becomes widely adopted. DC> EBD> When an architecture is "maxed out", it's difficult to make DC> EBD> significant improvents that are drop-in. DC> DC> On the theory that you mean the email architecture, rather Correct. My intended point, in response to DAU, was that pure SMTP won't do what's needed. Thus improvements will not be drop-in. However, this wasn't a huge pain with DNSBLs. IOW, "SPF is not pure SMTP, but I don't think that's an inherent or insurmountable problem." DC> DAU>> I think people will realize that if we're remodeling the DC> DAU>> boat that much we should have at least made sure we were DC> DAU>> fixing something in the process... DC> DC> In general, the claim that we need to rebuild email is DC> proving easier to make than it is to describe what we need... DC> and get clear community consensus that it is correct. *nod* The community is large enough that we can forget consensus. I'd be thrilled with majority agreement. Plurality is realistic. Alternatively, $large_provider might be able to put its weight behind a method... DC> EBD> Hogging the TXT RR is a bit greedy. DC> DC> As noted, TXT is an expedient. None of the available choices DC> for a DNS record is all that pleasant. TXT seems to have the DC> best near-term utility. Everyone hopes to bypass it as soon DC> as is practical. Without new code/libs to parse the TXT RR, SPF doesn't work. As long as new code is being written, it seems logical to have another RRTYPE assigned -- that's one less thing to change later. DC> Some of us agree with you. The enormous volumes of DC> legitimate mail suggest per-user and per-message "policy" DC> mechanisms are likely to have a few scaling problems. Particularly during ramp-up. That's what started the XO thread... Incremental changes are the only realistic way. SPF isn't perfect, but it's something now, and IMHO probably better than continuing to do without. I just hope future improvements aren't met with too much inertia. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.