Re: SPF again (Re: XO Mail engineers?)
On Tue, 10 Aug 2004 05:17:17 -, 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 ;) pgpwz0L2FpuQt.pgp Description: PGP signature
Re: SPF again (Re: XO Mail engineers?)
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:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301
Re: SPF again (Re: XO Mail engineers?)
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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: SPF again (Re: XO Mail engineers?)
On Tue, 10 Aug 2004 04:00:56 -, 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...) pgpBvtLAjtwvo.pgp Description: PGP signature
Re: SPF again (Re: XO Mail engineers?)
Without new code/libs to parse the TXT RR, SPF doesn't work. ... that could be one of the reasons why, two years before the advent of SPF, i wrote up and circulated jim miller's idea from 1998. if you want to know about the paths not taken, see http://sa.vix.com/~vixie/mailfrom.txt. 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 i think the TXT RR choice was made so that applications could treat the contents as a meta-language and extend it forever, thus not having to know in advance what the ultimate goals and means would turn out to be. personally i prefer the MX RR and a stylized name, but i was trying to solve the problem rather than create an industry. (ymmv.) 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...) 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, that makes dnssec seem like it's going to be hard to deploy. take heart, though -- we're *close*. real close. the next deployment barrier will be that your parent domain has to register your keys, and in the early days, will probably have an unjustifiably poor cost:benefit ratio for doing so. it will NOT, unless i'm completely confused, be that there are too many RR's. -- Paul Vixie
Re: XO Mail engineers?
Drew, Here's the straight scoop: The New XO SMTP servers are new in the sense that they go back to a 1997 platform rather than a 1993 platform that smtp.concentric.net derives from. They're both from the Concentric* part of XO, and both come out of my team, for what it's worth. What we've been doing is consolidating some of the extremely old systems onto the newer platforms, where we've been focusing our development cycles for some time. 'smtp.concentric.net' isn't ceasing to exist, but it's now (or rather, extremely soon) will be on the up-to-date systems. That said, we're not forcing people to host mail with us in order to use us for outbound relay. The one restriction that will be imposed by the new smtp.concentric.net that the old one didn't do was to require the sender domain to exist on-platform rather than to allow completely unchecked relay by domain. Domain hosting is bundled with all our DSL and other network access products, so for the vast majority of people, this is no problem, because we don't need to be authoritative, or have MX pointed to us, for this to work. The one situation where people are impaired is if they want to send mail via a domain name of some other ISP (e.g. aol.com), in which case they should use the relays provided by their other ISP (we don't block outbound port 25 across the board), or if a customer is running a mail server/mailing list/etc of their own, where said server might send out mail from any domain, in which case that server should be doing its own MX routing and not relying on a relay. Most of our DSL and other access customers that use an XO-provided relay are already on the newer platform and have been for a long time, and only a few remain with configurations still pointing at the older legacy systems. So the actual impact here is quite small. You may now all commence flaming this, and me :) --David Schairer VP/Chief Systems Architect XO Communications, Inc. * We have recently relaunched the Concentric brand for our email and hosting products -- www.concentric.com -- for those of you who remember it from the 'before time' :) I have a few discount codes left for email/hosting accounts -- send me an email if interested. On Aug 4, 2004, at 9:41 AM, Drew Weaver wrote: It has come to my attention that XO has done away with some of concentric's email systems and have replaced them with new XO SMTP servers these new XO SMTP servers aren't allowing people who don't have their mail hosted at XO to relay mail through them even though they are XO DSL customers, you guys may want to rethink your policy on this. It is generally the responsibility of the ISP to provide the outgoing mail transport for your connected users. -Drew
Re: XO Mail engineers?
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.html 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
Re: XO Mail engineers?
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. -forrest
Re: XO Mail engineers?
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.
Re: XO Mail engineers?
On Aug 4, 2004, at 12:23 PM, Forrest W. Christian wrote:
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.
And at some point in the not-so-distant future {net|sys}ops will look
up from their terminals, blink their eyes a few times and realize that
they have just spent the last $x months jumping through a terrible
number of hoops to support this SPF/SRS thing because everyone is
doing it. And they will realize that all that time/effort/money has
still required users to change the way they do things and that
operators had to waste time implementing a half-solution (or less) when
(this may be unspeakable) in a similar amount of time/effort/money a
real (drastic) solution could have been implemented.
I don't think SPF is worthless [1] but it isn't a drop-in solution and
the impact on infrastructure will be significant if it becomes widely
adopted.
I think people will realize that if we're remodeling the boat that much
we should have at least made sure we were fixing something in the
process...
-david
1: SRS may just be a boondoggle, we'll see.
David A. Ulevitch - Founder, EveryDNS.Net
http://david.ulevitch.com -- http://everydns.net
SPF again (Re: XO Mail engineers?)
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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: SPF again (Re: XO Mail engineers?)
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
Re: SPF again (Re: XO Mail engineers?)
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.
DAU more that people are (blindly) clamoring for it.
DAU SpamAssassin is going to start checking SPF records.
DAU
DAU If I don't choose to implement SPF my DNS servers are still
I don't choose to get bounces and other headaches from joe jobs.
DAU going to get those TXT record requests. I can't opt-out of
No, although you can return NODATA or a non-SPF TXT RR, giving
you your choice of negative or positive caching.
DAU that. I don't look forward to getting a taste of what the
DAU root-server operators see in their valid/invalid lookup
DAU ratios.
DAU
DAU I think there are going to be some negative consequences as
DAU more people implement SPF that will only become apparent at
DAU a certain scale.
Perhaps. However, the current { ease of performing } + { time to
educate people re } joe jobs doesn't exactly scale well. I'd not
call SPF a cure, but I still think the sickness is worse than the
experimental treatment.
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:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Re: SPF again (Re: XO Mail engineers?)
On Wed, 4 Aug 2004, David A.Ulevitch wrote: SPF's use of TXT records doesn't bother me so much. It's more that people are (blindly) clamoring for it. Maybe you should -- draft-ymbk-dns-choices-00.txt -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: SPF again (Re: XO Mail engineers?)
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: XO Mail engineers?
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 -- suresh ramasubramanian [EMAIL PROTECTED] gpg EDEDEFB9 manager, security and antispam operations, outblaze ltd
