On Tue, Jan 20, 2004 at 10:31:33PM +0100, Za'mbori, Zolta'n wrote:
|
| How many servers need to be upgraded because of SRS compatibility?
|
There are three groups of verbatim forwarders --- forwarders who don't
change the envelope sender as they forward a message.
Group 1: the organizational / commercial forwarding providers such as
acm.org and pobox.com. This group also includes the vanity domain
providers and the alumni accounts. For these guys, forwarding is a
managed service, even if it may not appear to the end user that way.
In the case of the alumni forwarding industry, most alumni forwarding is
actually outsourced to a very small number of players including
http://www.bcharrispub.com/isd/index.html
That's group one, the forwarding service providers.
Now, for the past ten years, "Intro to System Administration" and "Intro
to Email" books have talked about how to set up verbatim forwarding.
As a result, over the years, most ISPs have acquired an /etc/aliases
file, used for distribution lists. They may also have users with
.forward files or the equivalent. They form group 2. People who move
from one email address to another get this kind of forwarding set up as
a courtesy. Because it's convenient, it gets used for all sorts of
little things.
In group two, it is the paid sysadmin's job to keep things working. The
ISPs want to retain the functionality of that forwarding, but it is not
a managed, primary, revenue-generating service. In fact, if Group 2
forwarding stops working, people might take some time to realize it's
broken, but when they do notice it needs to get fixed.
Group three is similar to group two, except that the commercial
relationship is absent. Forwarding may have been set up as a favour to
a friend. Linux hobbyists set up a vanity server and put entries in for
their friends as a convenience.
In group three, there is no professional sysadmin. If forwarding
breaks, most users don't actually care because those forwarding
addresses aren't being publicized as primary email addresses. Some
users will care but they'll realize that they're getting what they paid
for.
On a purely technical level the solution is the same for all three
groups. Forwarders have to rewrite the sender address.
On a deployment level, we have to introduce those modifications in
slightly different ways, ways that are appropriate to the different
groups.
Group 1 will solve the problem on their own if they have to because it
is a business necessity. Pobox.com found that people were rejecting
mail with the error "sender @yahoo.com not coming from yahoo.com
server." Even before SPF we had to do this.
Group 2 will put in a workaround immediately until they can figure out
what's going on and respond in a more measured manner. The SPF faq
lists a number of workarounds, none of which are perfect, but will cause
the helpdesk phones to stop ringing.
Group 3 will react by upgrading their software to the latest release,
because that is the only thing they can do. Some of them don't really
care if forwarding breaks, and if nobody complains they don't have to do
anything.
Each group could produce complainers who say that because we are
breaking forwarding, we should back off and stop trying to fix what
ain't broke. But the leaders in the email industry have agreed that
email is in fact broke, and they will be making announcements in that
direction soon, so the complainers will be reduced to a minimum.
But it would be even better for everyone if the complainers did not
arise at all. That's next.
We can ease the pain of transition by:
1) getting the forwarding industry involved and prepared for the change.
This is why I wrote http://spf.pobox.com/srs.html
2) writing the necessary patches to MTAs and getting them widely adopted
*before* breaking-of-forwarding becomes a big problem. These patches
can roll out at the same time as SPF, creating a ratchet effect.
3) educating ISPs that they need to upgrade and turn on these new
capabilities.
It is most elegant to let the solution scale along with the problem.
There will be a certain amount of breakage, but if we can spread out
that breakage over time, people will be able to tolerate it. If all the
breakage gets lumped into a short transitional phase, we'll create more
enemies.
As a side note, it is important that people be aware of breakage when it
happens.
We do mitigate the problem by testing trusted-forwarder.org. The known
major forwarding providers are all listed there already. Any providers
which are not known will trigger a false positive. Under SPF, false
positives will cause bounce messages to go to the sender, and the bounce
message will contain a URL with a description of the problem and advice
about what to do. Ordinary people basically care that the mail should
get through. The error message is terse right now but could say: "if
you are sending mail through a forwarding service, try addressing the
recipient directly." This is the best solution we could come up with.
If we want to gain community support for the project, the best scenario
sees all the major MTAs bundling forwarding-compliance patches into
their standard distributions. MTA vendors will need to get involved. A
surprising amount of end-user grumbling can be quelled if we say "that's
fixed in the latest release, haven't you upgraded yet?"
This is why we need people to help write SRS tools for the four major
opensource MTAs, and lobby for those MTAs to switch to the new paradigm
this year.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡