The Impending End of Traditional .forward-style Forwarding
J'e's back, with a finely detailed scenario of one of the many ways in which
getting clear communications to our constituents, especially students, is becoming
more complicated. It's an issue of utmost importance to institutional missions
but it's not clear that anyone but techies and a few exceptionally alert marketing
people understand what's happening. Enjoy J'e's piece!
Way back when, at the dawn of Internet time, spam was not a scourge upon the
land. Hard to believe, but yes, it is true: There *was* once an online world
without spam. The rules then were "be conservative in what you send, and
liberal in what you accept," and "deliver or return, never discard
any message," and systems acting as open relays were widespread and convenient,
rather than a conduit for abuse and a cause for summary blacklisting.
Another dying artifact of those earlier, simpler, times is (or perhaps I should
say "was") e-mail forwarding using the traditional .forward file.
For those of you who've grown up on Windows, and who may never have seen a Unix
percent-sign shell prompt in your life, let me explain briefly how a .forward
file works--the process is really quite simple.
In a nutshell, by creating a file with the special name ".forward"
in your default directory on a Unix system, the system would begin automatically
forwarding any new mail it received for you to whatever address you listed in
that file. Boop, in comes mail addressed to your old address; boop, out g'es
that same message again, automatically forwarded on to your new address.
In the old days, this was no big deal--who cared where your e-mail came from?
These days, however, how your mail gets routed is a very important issue for
one simple reason: deliverability.
"Deliverability" is a term that has been coined to capture the problem
that sites increasingly face trying to get legitimate mail through anti-spam
measures. Trying to send mail that includes bad keywords? You may have "deliverability
issues" at sites that use content-based filters. Had an accidental configuration
problem that resulted in spammers exploiting your system for a while? You may
be listed on one or more DNSBLs, and have "deliverability problems"
as a result.
Deliverability is particularly closely tied to reputation. Every piece of mail
that gets sent from your campus, whether created by a local user or forwarded
by that user to another account using a dot forward forwarding entry, "counts"
against your reputation at a growing number of providers. As far as they can
tell (and remember, this is all automated because of the hundreds of millions
of messages that are involved), when you hand their mail servers a message,
"you" sent them those messages, even if all you did was innocently
and dutifully forward the mail on behalf of one of your users, as instructed
by that user's .forward file.
As part of that process, are you forwarding along spam as well as good mail?
If so, guess what, you'll get a "bad reputation" and you may then
begin to have "deliverability concerns." All of that, as far as it
g'es, is pretty comprehensible/routine. However, at a growing number of colleges
and universities, the following more *subtle* scenario has begun to occur:
-- Students, coming to school with familiar accounts on Hotmail, Yahoo, Gmail,
whatever, provide those accounts to universities as an initial contact point
during the application process.
-- Upon admission, from the student's point of view, nothing has really changed--they
want to continue using their familiar account on that third party provider,
for any of a variety of reasons. Let's assume that they're allowed to do so,
and that address g'es into the institutional ERP student database as the e-mail
point of contact.
-- The university decides to unilaterally begin generating a bunch of mail
to the student, mail which may be highly germane to the student's program or
status, but which the student may not be interested in (regardless of the objective
facts).
-- The student pushes the "this is spam" button at the free provider
when reading the mail which he or she has received from the university.
-- The university mail sender gets a spam report from the free provider (or
maybe they don't, in the end, it really d'esn't matter in this scenario).
-- The university may ignore the report(s) (if they get them), or the sender
may remove the recipient (sometimes they can't even ID who to remove, due to
anonymization of the complaints), or the sender may contact the student who
pushed the "this is spam" button to talk about the issue (but this
d'esn't scale so well at big schools).
-- Regardless of whether reports generate removals or not, the fact that at
least some users of the free Web e-mail services don't like the university's
mail is Locally Noted. (This may be noted as a result of the reports and removals,
or it may be a result of the institution being rate limited or blocked outright
in more extreme cases).
-- The institution decrees that all mailings must henceforth go *only* to institutionally
provided student e-mail addresses.
-- In some cases, forwarding of those accounts is allowed.
-- When forwarding is allowed, nothing's really changed for the better: students
still get unwanted institutional mailings, and students still complain, which
still "counts against" the institution's reputation with the free
Web e-mail provider. Moreover, now, other mail (including presumably at least
some spam), *also* gets forwarded, making the institutional reputation worse
yet. In the truly degenerate case, institutional mail gets blocked by the free
Web e-mail provider as a result of the forwarding. The institution says, "Shrug,
I sent it to the institutionally provided account." Students say, "HEY,
you never told me that my car was being towed for unpaid tickets" (or whatever),
because their forwarded mail was blocked.
-- When forwarding is not allowed, the students may set up their free Web e-mail
account to suck e-mail from the institutional account to the free account via
POP consolidation. Doing so typically requires storage of institutional account
credentials on the free Web e-mail provider's system. Now *there's* a big help,
security-wise... Alternatively, in the forwarding-not-allowed case, the student
continues to use their preferred account, largely ignoring the institutional
account, and again, communication fails to occur.
I think we're in for some very interesting times as institutions begin to sort
these issues out.
Oh yes: If the above scenario isn't enough to convince you that the stake is
being driven into traditional .forward style forwarding, I encourage you to
review Meng Weng Wong's excellent whitepaper on SPF, as available at http://spf.pobox.com/whitepaper.pdf.
--------
Well, there's the problem - or at least part of it. The fact is that our
messages are not getting through like we need them to. What are we going to
do? One thing I suggested some time ago is by building more institution-wide
communications tools right into integrated course management systems. Presumably
the students do have to log into to their Blackboard or CTools or whatever.
(See Let's
Build More "Learning" into Even Basic IT Tools, June 3, 2004.)
I suspect that's part of the answer, but don't claim to see an overall, integrated
way through the mess yet. -Terry Calhoun