Open Menu Close Menu

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


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

comments powered by Disqus