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
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
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.
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.
Date: Wed, 4 Aug 2004 14:46:02 -0700
From: David A. Ulevitch
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.
When an architecture is "maxed out", it's difficult to make
significant improvents that are drop-in.
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...
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
> Date: Wed, 4 Aug 2004 14:46:02 -0700
> From: David A. Ulevitch> 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.When an architecture is "maxed out", it's difficult to make
significant improvents that are drop-in.> 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...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.
Sender-ID is not SPF. Sender-ID ignores the RFC 2821 MAIL-FROM and thus
does not stop the bounce technique. It does not stop the virus filter
response. Sender-ID does not allow for accurate accreditation. Microsoft
wants everyone to sign a mutual IPR where this can not be transfered. After
all the problems, much with the excessive use of DNS TXT records, Sender-ID
will not have changed the amount of abuse seen, but will raise the support
required to help customers with their mail.
-Doug
> 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...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
Date: Wed, 4 Aug 2004 15:46:17 -0700
From: David A. Ulevitch
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.
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
I don't choose to get bounces and other headaches from joe jobs.
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.
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.
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
Maybe you should -- draft-ymbk-dns-choices-00.txt
Edward B. Dreger wrote:
> Date: Wed, 4 Aug 2004 15:46:17 -0700
> From: David A. Ulevitch> 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.
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
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.
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
Edward,
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.When an architecture is "maxed out", it's difficult to make
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?
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...
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.
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.
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.
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.)
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.
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.
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/
Date: Mon, 9 Aug 2004 15:08:12 -0700
From: Dave Crocker
>> 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.
> When an architecture is "maxed out", it's difficult to make
> significant improvents that are drop-in.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."
>> 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...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.
*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...
> 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.
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.
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.
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
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...)
> 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.
Well, "That RR looked totally different last month" certainly qualifies said RR
as "weird" 
Folks,
... SPF isn't
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.
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.
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.
If SPF is wonderful, it had better satisfy a higher criterion than that
it "isn't perfect, but it's something now".
d/
Folks,
> ... SPF isn't
> perfect, but it's something now, and IMHO probably better thanThis 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,