SPF again (Re: XO Mail engineers?)

Tue Aug 10 04:00:56 UTC 2004

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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
Sending mail to spambait addresses is a great way to get blocked.