Margaret, thank you for expressing your position so fully. It gives me
something to agree with :) ... which, in a forum like this, is like a
breath of fresh air.
(I've observed that if one person posts on matters A, B, C, and D, and
if everybody agrees on a A, B, and C, but a few people disagree on D,
it's the "D" part that gets all the attention in followups; you have to
really pay attention to see that everybody does agree on the A, B, and C
parts. This can make consensus hard to detect, especially given the
practice of trimming quoted text and the fact that "me too!" posts are
frowned on. Some web-forum software provides an "instant poll" feature
which can actually be pretty useful. While consensus isn't exactly a
voting operation, there's nothing like seeing a show of hands every once
in a while to nudge the majority out of lurk mode.)
On Sat, Apr 24, 2004 at 03:33:08PM -0400, Margaret Olson wrote:
|
| Just to be clear, here's my current basic position on what appear to be the
| open issues in this group, subject to change of course as I learn more about
| the various problems:
So, for the record, I want to state that I agree with everything I
trimmed from your original message. :)
| I support splitting the solution into protocol validation and sender
| validation; that is, between 2821 and 2822 or HELO and 2822.
|
| I am opposed to 2821 validation at the expense of 2822.
I agree on both counts.
| 1. Accept SPF as the 2821 solution. Add to the current SPF draft an explicit
| recommendation that receiving systems provide white listing for forwarding
| services used by their users.
I am giving the draft another pass this weekend and I will make sure
that language is present.
| If the white listing recommendation is written into the RFC, then those of
| us on the receiving end of "my subscriber is complaining that they didn't
| get the newsletter" messages will have something concrete to site in the
| message that passes back from us to our customer to the subscriber to the
| subscriber's ISP. (Many users complain about non-delivery to the sender, not
| to their ISP.) Is it fair to say that almost everyone has a white list? Is
| it reasonable to add white listing support to the receive side SPF
| configuration (if it isn't already)?
There are two solutions to the forwarding problem: the forwarder
changes, or the receiver changes, or both. I think the spec should
mention both.
I want to suggest one possible future that would encourage forwarders to
change.
To attack the forwarding problem from another direction, imagine if a
critical mass of ISPs jointly announced a deadline, say 12 months away,
to put forwarders on notice that they need to change. I can tell you
firsthand that the biggest obstacle is inertia. If the industry can
agree on a deadline, forwarders get a solid reason to commit resources.
With an external standard of reference, both management and tech are on
the same page. (I can tell you that forwarders are seeing a steady rise
in customer calls due to the *lack* of rewriting, because people are
already doing SPF on an ad-hoc basis.) Forwarders aren't opposed to
SRS; gmx.net, an ISP in Germany that I'd never heard of, is now doing
it. It helps if someone else can light a fire under our ass.
If the industry can announce a deadline for SRS adoption, the forwarding
industry can get over the hump and then a lot of things become easier.
The goal is to minimize customer call costs. Proactiveness and getting
forwarders on our side will save time, money, and aggravation. Having
something in the RFC to point at, while important, strikes me as a
blame-shifting exercise that is better avoided altogether. (Half the
value of having standards is so you can blame the right person who's not
meeting the standard. But the other half is so everyone can just meet
the standard so the blame never appears at all. I don't want this to be
a standard more observed in the breach.)
Now, "deadline" is a pretty strong word. It's not really going to be
"do this or we bounce your mail": it's more "well, we recommend you do
this, because we all have plans, around this time, to tweak our antispam
systems in a certain way, and here's a guaranteed way for you to get a
better rating in our spam filters to make the end-users' lives easier."
We should discuss the details of what we need to tell forwarders: for
2821 purposes, SRS is on the list, but since Caller-ID needs a Resent-*
header to be prepended, we might as well kill two birds with one stone.
The window for making this announcement is short. I think 12 months
notice is fair to everyone and balances the urgency of the problem with
the need to get approval, develop, test, evaluate, plan rollouts, handle
customer education, etc. Uncle Bill has given us a deadline of
end-2005. The sooner the better.
If we aim to get an announcement out by the end of July, that lets us
discuss the specifics over the course of the summer conference season
with a variety of stakeholders. Is that feasible?