Here's the note that was sent to Concordia sysadmins in December 1997,
explaining the centralized anti-relay project:
Subject: Despamming e-mail at Concordia by centralising MTAs
From: Anne Bennett <anne@alcor.concordia.ca>
Date: Thu, 04 Dec 97 14:43:45 -0500
[EXECUTIVE SUMMARY: as of next week, incoming e-mail will go through a
"trusted mailer", which will eliminate unauthorised relay attempts, as
well as some sender forgeries. No change is required by sysadmins,
but they should be aware that mail to their systems will now travel
an extra hop. No change is required by end users.]
Dear colleague,
With this note, I am trying to reach the sysadmins of all machines at
Concordia which support incoming IP e-mail; by this I don't mean POP
clients, but only machines which listen for mail connections on port 25.
As you may have noticed, e-mail spam (unsolicited broadcast e-mail)
has reached very discouraging proportions; this material is wasting
our time and our computing resources. Also, and worse from the point
of view of Concordia's reputation as a good net.citizen, spammers are
hijacking our machines to deliver their ads, which brings down upon us
(well, upon me as postmaster@concordia.ca!) the wrath of angry
recipients of this unwanted junk.
It is urgent that we put a stop to unauthorised e-mail relaying through
Concordia. In other words, our mailers should be usable to deliver
mail *from* our users and *to* our users, but not from one user on the
outside to another user on the outside. Methods exist to configure
many mailers to deny such relaying, and in fact most of the machines in
the "big" computer departments, i.e. IITS, Computer
Science, and ECE, have already been "locked down" against unauthorised
relaying. (Congrats also to Biology and to the Computer Users' Group for
locking down their systems very quickly).
However, installing anti-relay provisions requires more expertise in
e-mail transport than most departments can reasonably afford to
develop, and my trying to educate one sysadmin after another as
spammers find and exploit our machines is rapidly becoming unworkable.
Therefore, with the approval of IITS, I am going to
centralise the delivery of incoming e-mail to a small group of "trusted
mailers", which will "despam" the mail, and then complete the delivery
to the target machine.
A few important notes:
* You don't need to change your machine configuration in any way; we
will make the right thing happen automatically with MX records, and
with special configuration of the "trusted mailers".
* Outbound e-mail is not affected. That means that your machine can
still deliver e-mail directly to the target machine, without going
through a trusted mailer. This means I trust you to make sure
your users are not trying to spam! (So far, locally generated
spam has not been a significant problem at Concordia.)
* You *can* opt out of this scheme if you like, but you must assure
me that you can and will lock down your machine so that it can't
be used for offsite relaying.
* If you have people using your machine as a POP server, reading
mail will continue to work as usual, but people won't be able to
submit their outgoing mail to your machine from offsite; in that
case, they should use their ISP's SMTP relay. (Folks using your
machine from the .concordia.ca domain, including our dial-up
lines, will see no change.)
While most sysadmins don't need to understand how we're going to do
this, I'll explain it anyway. If my explanation is not clear, or you'd
like more details, please ask on concordia.dept.iits.help,
the help newsgroup. That way, everyone can benefit from the ensuing
discussion.
To implement centralised anti-relay, we will designate a finite number
of "reliable machines" (trusted mailers) to relay incoming mail for
the University, and install MX records in the DNS, pointing at the
trusted mailers. That way, when any machine wants to send mail for
user@somehost.concordia.ca, it will find the MX record for "somehost"
pointing at "trustedhost", and deliver the mail to "trustedhost". In
turn, "trustedhost" will deny any relay attempts, and any attempts to
use an invalid (well, a detectably invalid!) sender address. Assuming
the message is OK, "trustedhost" will deliver it to "somehost", which
will perform local delivery to the user's mailbox is the usual way.
"Somehost" will therefore require no modifications.
But that's only half the battle, since it addresses only mail which is
delivered according to the MX record. Spammers often ignore MX
records; they simply port scan a whole domain looking for an open port
25, and connect directly to their victim relayers. To protect against
that, we will install router filters at the RISQ gateway (i.e. on the
network router that is the "choke point" between the Concordia network
and the outside world), which will allow mail to be delivered *only*
to our list of trusted mailers. No one outside Concordia will be able
to connect directly to the mail port of "somehost" to try to deliver
or relay mail. (This will *not* affect other services provided by
"somehost", such as telnet or finger.)
Outgoing mail will proceed as it does now, i.e. local machines can make
direct outbound connections if they choose.
The philosophy behind the above implementation is both maintainability
and watertightness; as long as we're filtering everything *except* a
small number of designated mailhosts, we won't have spammers
port scanning the domain and getting in through the cracks. And it's a
lot easier to maintain a list of a half-dozen well-known mailers than
to try to maintain a list of all of the *un*reliable mailers!
I don't want to impose these measures on anyone, though I expect that
the vast majority of sysadmins will be quite relieved to have them in
place. If you'd rather opt out of this scheme, let me know the IP
addresses of the machines you want to withdraw, and also how you
intend to ensure that those machines are not misused for spam
relaying.
The initial list of trusted hosts (just for your information) is:
machine relaying for
---------------------- ----------------------------------
alcor itself
pollen.cs cs subdomain
lemy.cenparmi cenparmi subdomain
pollen.cs encs subdomain
cia.ece ece subdomain
cia.ece vlsi subdomain
TBA me subdomain
TBA civil subdomain
clyde anything not otherwise covered
I have started a mailing list, "postmasters@concordia.ca", to
facilitate future discussions about e-mail transfer services at
Concordia. Any further announcements will be posted there. While
discussion will be allowed on the list, the volume is expected to be
low, so I do encourage you to subscribe, by sending a message to
"postmasters-request@concordia.ca" with nothing but the word
"subscribe" in the body of the message. The list is closed, and I'll
be restricting membership to Concordia sysadmins and similar computer
support staff.
I'd be interested in your reactions to http://maps.vix.com, the
Realtime Blackhole List. It's something I *may* be suggesting to my
management, but because of the type of filtering, (a) I'd want approval
from higher up before doing it, and (b) if I'm MXing for the rest of
the University (except big subdomains), I'd feel I have to announce in
advance and provide some kind of opt-out if people objected. But I
really wonder if people *would* object, since this could despam us to a
very large extent. Your comments would be extremely welcome,
particularly if they were made on the "postmasters" list. Once people
have had a chance to subscribe, I'll re-post some of the discussion
that I've seen so far.
Since all mail coming in for Concordia will now pass through a small
number of machines, we'll have a chance to collect volume statistics.
I'd welcome a move to make these statistics more easily available.
Right now, Sylvain Robitaille, Chris O'Regan, and Michael Assels are
working on evaluating and adapting stats-generating scripts for
sendmail v8; if you're interested in having input on that, please
contact Sylvain. Of course the scripts will be available to all when
they're ready.
I intend to implement the centralised despamming scheme over the space
of a few days next week (December 8 to 12) ; I'll proceed a few
subnets at a time, and monitor the load on the trusted mailers. The
idea is to have this scheme fully in place by the December 15, and have
at least a week of "production" operation before the Christmas break,
which I expect would otherwise be spammer heaven.
If you foresee any problems with the above, please let me know, either
directly, or by joining and mailing to the "postmasters" list.
Anne. (Concordia Postmaster)
--
Ms. Anne Bennett, IITS, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca (514) 848-7606
![[IITS Home]](/style/button_iits_home.gif)
![[Concordia Home]](/style/button_conu_home.gif)