At 03:23 PM 8/4/2004, Forrest W. Christian wrote:

On Wed, 4 Aug 2004, Drew Weaver wrote:

...

It is generally the responsibility of the ISP to provide the outgoing mail transport for your connected users.

This BCP seems to be changing. The new BCP which seems to be evolving requires customers to authenticate to their home mail server on the MSA port and send mail that way. This appears to be being driven by SPF/Sender-ID-like mechanisms.

It is also driven by common sense. Using Submission with AUTH permits users to configure their email service once on their laptops, and use it from wherever they roam. Let's face it, the present crop of mail client software does not make it easy to quickly change outgoing servers, but all popular current mail clients support SMTP AUTH, and to at least some degree (i.e. with some coaching of the end user) support Submission port (587). Let's encourage this. It's good for users. It's good for help desks.

DAU> Date: Wed, 4 Aug 2004 14:46:02 -0700 DAU> From: David A. Ulevitch DAU> I don't think SPF is worthless [1] but it isn't a drop-in DAU> solution and the impact on infrastructure will be DAU> significant if it becomes widely adopted. When an architecture is "maxed out", it's difficult to make significant improvents that are drop-in. DAU> I think people will realize that if we're remodeling the DAU> boat that much we should have at least made sure we were DAU> fixing something in the process... Indeed. Hogging the TXT RR is a bit greedy. Assuming homogenous policy across a domain name is a stretch. Surely someone else noticed KRB5 and its interaction with DNS. Running something DNS-based that requires simple parsing is hardly an earth-shattering change; it smells similar to DNSBLs, yes? Yet it's still somewhat controversial. And then there's LDAP... In a situation where widespread agreement is mandatory, and consensus is better, drastic changes are difficult. If all netop-related technologies required NANOG-L agreement, nothing would ever get done. I'd like to see widespread adoption of authenticated SMTP, with per-user restrictions on sender address. Alas, that's more difficult than, say, SAV. Call me cynical, but I don't see anything like SMTP auth+restrict taking the world by storm in the near future. No, SPF isn't perfect. I'm trying to decide if it's even "good". Are the benefits worth the effort? I'm hopeful, but time will tell. Time will tell, but I'm hopeful. At this point, I'm game to give it a shot. 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.

On Aug 4, 2004, at 3:23 PM, Edward B. Dreger wrote:

DAU> I think people will realize that if we're remodeling the DAU> boat that much we should have at least made sure we were DAU> fixing something in the process...

Indeed.

[snip]

Running something DNS-based that requires simple parsing is hardly an earth-shattering change; it smells similar to DNSBLs, yes? Yet it's still somewhat controversial.

SPF's use of TXT records doesn't bother me so much. It's more that people are (blindly) clamoring for it. SpamAssassin is going to start checking SPF records. If I don't choose to implement SPF my DNS servers are still going to get those TXT record requests. I can't opt-out of that. I don't look forward to getting a taste of what the root-server operators see in their valid/invalid lookup ratios. I think there are going to be some negative consequences as more people implement SPF that will only become apparent at a certain scale. -david ---------------------------------------------------- David A. Ulevitch - Founder, EveryDNS.Net http://david.ulevitch.com -- http://everydns.net ----------------------------------------------------

Edward B. Dreger wrote:

DAU> Date: Wed, 4 Aug 2004 15:46:17 -0700 DAU> From: David A. Ulevitch

DAU> SPF's use of TXT records doesn't bother me so much. It's

Perhaps some other technology would like to use TXT RRs. If something hogs an entire RRTYPE at a given scope, it really should have its own RRTYPE. An acceptable alternative would be KRB5-style "_foo" entries. All IMHO.

Last time I looked, draft-ietf-marid-protocol-00.txt addressed this issue, 2.1.1 DNS Record Type The record type is a textual RR type to be allocated by the IANA for this purpose. However, because there is a large number of domains with these records already deployed as TXT type records, and because there are a number of DNS server and resolver implementations in common use that cannot handle new RR types, the record type can be TXT. Domains SHOULD publish records under both types. If a domain does publish under both types, then they MUST have the same content. Mail receivers SHOULD query for both types of records. If both are returned, then the new RR type MUST be preferred. It is recognized that the current practice (using a TXT type record), is not optimal, but a practical reality due to the state of deployed records and software. The two record type scheme provides a forward path to the better solution of using a RR type reserved for this purpose. For either type, the character content of the record is encoded as US-ASCII. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387

Edward, DAU>> I don't think SPF is worthless [1] but it isn't a drop-in DAU>> solution and the impact on infrastructure will be DAU>> significant if it becomes widely adopted. EBD> When an architecture is "maxed out", it's difficult to make EBD> significant improvents that are drop-in. On the theory that you mean the email architecture, rather than the DNS architecture: <diatribe against replacing current email> I think there has yet to be a careful, coherent analysis of the current architecture that describes the clear and accepted requirements and shows that they cannot be supported by the current architecture. The more serious problem, with respect to spam control, is the lack of broad consensus on those requirements, properly balanced against their impact on the human/social aspects of email, and stated in a way that gives useful technical guidance. So, instead, the technology side of things is forced to thrash around, searching for palliatives that might have only near-term benefit. </diatribe against replacing current email> On the theory that you mean the DNS architecture, then... huh? DAU>> I think people will realize that if we're remodeling the DAU>> boat that much we should have at least made sure we were DAU>> fixing something in the process... In general, the claim that we need to rebuild email is proving easier to make than it is to describe what we need... and get clear community consensus that it is correct. EBD> Hogging the TXT RR is a bit greedy. As noted, TXT is an expedient. None of the available choices for a DNS record is all that pleasant. TXT seems to have the best near-term utility. Everyone hopes to bypass it as soon as is practical. EBD> Running something DNS-based that requires simple parsing is EBD> hardly an earth-shattering change; it smells similar to DNSBLs, EBD> yes? Yet it's still somewhat controversial. Folks might want to take a look at the set of CSV specification, notably the DNA (accreditation) portion. (<http://brandenburg.com/CSV> for a single entry-point to the set of internet-drafts.) EBD> I'd like to see widespread adoption of authenticated SMTP, with EBD> per-user restrictions on sender address. Alas, that's more EBD> difficult than, say, SAV. Call me cynical, but I don't see EBD> anything like SMTP auth+restrict taking the world by storm in the EBD> near future. Some of us agree with you. The enormous volumes of legitimate mail suggest per-user and per-message "policy" mechanisms are likely to have a few scaling problems. EBD> No, SPF isn't perfect. I'm trying to decide if it's even "good". Would that more folks were trying to consider the various proposals carefully. d/ -- Dave Crocker <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

On Tue, 10 Aug 2004 04:00:56 -0000, "Edward B. Dreger" said:

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.

On the other hand, having to deploy a new BIND that supports the presumably newly-defined RR type just to publish an SPF record would almost certainly doom it to near-zero deployment. Also, remember that if we find out that the format was b0rked, publishing a new TXT is a lot easier than getting another version of an SPF RR deployed.... Compare and contrast the uptake of SPF with DNSSEC :) (Yes, I know there's *other* issues with deploying dnssec - but all those weird RR's probably scare off a lot of people...)

On Tue, 10 Aug 2004 05:17:17 -0000, Paul Vixie said:

i suspect it's not the number of RR's or even the obscurity of those RR's, but rather the fact that the RR's keep changing in number, kind, and name,

Well, "That RR looked totally different last month" certainly qualifies said RR as "weird" ;)

On Thu, Aug 12, 2004 at 12:17:47AM -0700, dhc2@dcrocker.net said:

Folks,

EBD> ... SPF isn't EBD> perfect, but it's something now, and IMHO probably better than

This is a very popular view these days.

However there are some fundamental problems with it:

1. It mistakes activity for progress.

2. It ignores opportunity cost, diverting energies to efforts that are likely to have no effect on spam rather than allocating those resources ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to basic improvement in the service.

I can't speak for anybody's network but my own ... but if everybody out there was merely using my published SPF records to reject forgeries, it would cut the amount of bogus SMTP traffic coming into my network by probably a third. Bounces from forgeries are rapidly becoming a significant problem for regular networks, where they used to mainly be a concern of large providers - I don't get many forgeries claiming to be from {hotmail.com,yahoo.com,aol.com,etc.} anymore. Cutting bogus traffic by a third is not a huge amount, but certainly non-trivial, IMO. Worth the effort of deployment? That probably depends on your network's size, traffic makeup and architecture (technical and social).

3. It ignores the difficulties with administration and operation of the mechanism, as it scales, such as its Procrustean limitation of usage scenarios that are reasonably supported.

that is definitely a sticking point with anti-forgery proposals, I will agree.

4. It treats a short-term mechanism as if it had long-term benefit; yet modification of a global infrastructure is always and only subject to long-term processes.

The problem with long-term solutions is that they require long-term development. At the rate the spam epidemic has been growing, if we wait until long-term solutions are ready before taking any action at a global level, there may not be much of an SMTP architecture left to save. Maybe I'm being overly dramatic ... maybe not. I suppose it depends on how much the userbase is willing to put up with. Maybe they're more willing to put up with the problem than with any of the proposed temporary measures (like SPF). Maybe the average user couldn't care less about things like SPF, because he/she is just using whatever setup his/her ISP set up, and all the complaining is coming from a small segment of the technically clued. I don't know.

If SPF is wonderful, it had better satisfy a higher criterion than that it "isn't perfect, but it's something now".

It works very well for me - but my personal network is small and not particularly complex. Obviously, mileage varies greatly by operator and network. I don't think it's reasonable to dismiss the solution out of hand, however, just because it doesn't meet the needs of _all_ networks. (Although a solution that's only implemented by a few isn't much of a solution, unless those few are Microsoft and the top 5 residential ISPs ...) The one thing that seems certain is that if we wait until a solution appears that works on all networks, and is supported by all players, and actually fixes the problem ... well, there will be some unusually cold weather in a very warm place when such a solution is announced, I suspect. Doesn't it seem reasonable to employ some temporary stop-gap measures in the short term, while waiting on permanent solutions to present themselves? Technical progress isn't entirely a zero-sum game - work on temporary measures like SPF does not necessarily preclude work on permanent solutions, does it? At any rate, this discussion is probably better taken up elsewhere (and I'm sure the points on both sides have already been beaten to death.) respectfully, -- Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527 <CaffeineHead> We have enough youth. What we need is a fountain of smart. -- http://bash.org/?70562

At 3:32 PM -0700 8/12/04, Douglas Otis wrote:

There is a proposal that should interest you. It is called Bounce Tag Address Validation By Dave Crocker.

http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.h...

This proposal is now in the IETF MASS WG.

There was a BoF called MASS held at the recent IETF meetings in San Diego; it has not yet been approved as a working group and no charter has been reviewed by the IESG. While I believe the work on BATV is interesting, I am not sure gating it on the approval of MASS is a good idea. One of BATV's advantages is that there are ways to use it which are workable within a single domain's administrative control. These do not eliminate a domain's need to do some handling of bounces, but they can avoid those bounces ending up in individuals' mailboxes. Reading the drafts, commenting to the authors, and trying out those elements of the system need not wait for action on the WG. Just my opinion, regards, Ted Hardie

DC> Date: Thu, 12 Aug 2004 00:17:47 -0700 DC> From: Dave Crocker DC> [ snip my "SPF isn't perfect but is something now" ] DC> DC> This is a very popular view these days. One only need to read a few NANOG-L analogy wars to understand why. Consensus? Ha. Majority? Yeah, right. I'd much rather have a system that is better thought out yet would require bigger changes. Good luck getting that to fly; until then, I'll settle for incremental improvements. DC> However there are some fundamental problems with it: DC> DC> 1. It mistakes activity for progress. Let's define "progress" as "improvement beyond the status quo". I hinted at that, but perhaps need to spell it out explicitly. DC> 2. It ignores opportunity cost, diverting energies to efforts DC> that are likely to have no effect on spam rather than DC> allocating those resources to basic improvement in the DC> service. I've suggested authenticated SMTP with restricted sender addresses a la SAV. There's something that would have real effect on joejobs. Are people implementing it? Or are they adopting SPF? Note that auth/restrict and SPF are somewhat orthogonal. The former relies on the sender operating in good faith, whereas the latter requests the receiver do so. However, I don't see as many drawbacks with auth/restrict. Few people need more than a few addresses, or perhaps domains, so there's not much admin headache. Blocking the problem at the source saves others the pain. (Remember blocking based on sender address/domain, before forged spam caught on?) You tell me why something with intraprovider implementation, real benefits, and lower side effects isn't flying. I agree that energies are misdirected... so how does this get changed? DC> 3. It ignores the difficulties with administration and DC> operation of the mechanism, as it scales, such as its DC> Procrustean limitation of usage scenarios that are DC> reasonably supported. 1. See above chunk 2. Let's hope nobody uses SPF as a definitive blocking mechanism 3. Prepare for "SPF override" whitelists. DC> 4. It treats a short-term mechanism as if it had long-term DC> benefit; yet modification of a global infrastructure is DC> always and only subject to long-term processes. DC> DC> If SPF is wonderful, it had better satisfy a higher criterion DC> than that it "isn't perfect, but it's something now". I believe I said "I'm trying to decide if SPF is good". That's hardly calling it "wonderful". Strict SPF will break popular greeting cards, eBay "send to a friend", Webmail, autoforwards, and many other things that "just work" now. Hence why I view SPF as a handy input -- much like we use DNSBLs as inputs as opposed to authoritative "do not accept mail" rules. The fact remains that SPF *does* provide additional intelligence in a standard method amenable to automated processing. I call that an improvement from a status quo, which translates to progress. 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.

David A.Ulevitch wrote:

...

1: SRS may just be a boondoggle, we'll see.

Considering MARID seems to be sender id first and the rest nowhere .. http://www.internetnews.com/xSP/article.php/3390221

This article has the state of these drafts stated incorrectly. See: http://www.imc.org/ietf-mxcomp/mail-archive/msg03062.html There is a last call coming but there is no assurance Sender-ID will escape this process. Judging by remaining flaws, I doubt that it will. CSV will go to last call in October. I think its prospects are better. There are also work ongoing in MASS such as BATV. See: http://www.ietf.org/ietf/04aug/mass.txt This agenda has been amended to include BATV. http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.h... It will be a draft written by Dave Crocker, John Levine, Sam Silberman, and Tony Finch. This will stop the bounces and virus notices without any help from the far end. I would also expect the Submitter draft in Sender-ID to be dropped. -Doug