Here's a letter that was sent to local ISPs in December 1997:
From: Anne Bennett <anne@alcor.concordia.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: postmaster@cjc.ca
To: postmaster@netcom.ca
To: postmaster@sprint.ca
To: postmaster@aol.com
To: postmaster@axess.com
To: postmaster@compuserve.com
To: postmaster@citenet.net
To: postmaster@colba.net
To: postmaster@generation.net
To: postmaster@jonction.net
To: postmaster@lanzen.net
To: postmaster@login.net
To: postmaster@mlink.net
To: postmaster@montrealnet.net
To: postmaster@proxyma.net
To: postmaster@mtl.ican.net
To: postmaster@canada.psi.net
To: postmaster@mtl.total.net
To: postmaster@mmtl.videotron.net
To: postmaster@mtl.centra.ca
To: postmaster@das.mcgill.ca
To: postmaster@mon-cn.concentric.net
Subject: Concordia e-mail anti-relay
cc: Unix People <smw>, <sheilae>, <syl>
Date: Mon, 08 Dec 97 20:59:38 -0500
Sender: anne
X-Mts: smtp
Dear colleagues at local ISPs,
Concordia University, where some of your customers work or study, is
in the process of implementing anti-spam measures; in particular, we
are making sure that it is not possible for spammers to use our
equipment in an unauthorized way to relay their messages (which means
denying relaying to all non-Concordia hosts).
While I'm sure that you must be aware of the problem of unsolicited
broadcast e-mail, and more seriously of innocent sites being
"hijacked" to deliver such messages, you might still be interested in
the following sites, if you haven't already seen them:
http://spam.abuse.net/
http://www.cauce.org/
http://www.Sendmail.ORG/antispam.html
The reason I'm writing to you about this is that you probably have
customers who use your dial-up services, but read and send mail using
Concordia's facilities. While POP services (reading mail) will
continue to work as usual, your users will not be able to submit mail
for addresses outside Concordia through Concordia machines. Instead,
they should be using your SMTP relay for e-mail submission.
We have had to implement these anti-relay measures fairly rapidly in
view of the seriousness of the unauthorized relay attacks against us,
and it is unlikely that we can reach all of our user community about
the changes beforehand; your support staff may therefore receive
questions. While I imagine that your support staff is sufficiently
skilled and experienced to understand an SMTP "551 Relaying denied"
message, I thought sending extra information might not be amiss. :-)
Just FYI, here's a brief description of our centralized anti-relay
scheme, which is being implemented this week (note that Alcor, our
largest mail machine, has had sendmail anti-relay since late October,
and that its users were informed via the concordia.announce newsgroup):
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.
And, for your entertainment, here's the "debugging guide" I gave our
local help line staff; if you think it might be helpful to your staff,
please go ahead and use it, or adapt it to fit your needs:
You are likely to be contacted in two instances:
(a) An offsite POPper (e.g. a Eudora user) can no longer submit
outgoing mail to one of our machines. This is to be expected.
Anyone not in the .concordia.ca domain should submit outbound
e-mail through their ISP's SMTP relay. This "problem" will
appear in two ways:
* The sender is trying to connect to one of our "trusted
mailers": see "551 Relaying denied" below.
* The sender is trying to connect to any other Concordia
machine's mail port. Once the router filters are in place,
those connection attempts will simply time out.
(b) Someone has a random e-mail problem, and they assume that the new
antispam stuff is causing it. In all cases, we need a copy of
the error message to debug the problem. The antispam stuff may
produce any of the following messages:
* 451 invalid sender hostname
This means that the "envelope sender" had a hostname
that we could not resolve in the DNS. When this
happens, it is usually a spam attempt (e.g.
"CALL-NOW@1-800-555-1212"). Occasionally it's
^^^^^^^^^^^^^^
someone munging their hostname on purpose (e.g.
"anne@alcor-no-spam.concordia.ca"), or a typo in a
^^^^^^^^^^^^^
client configuration (e.g. "anne@aclor.concordia.ca").
^^^^^
* 550 sender domain name required
This means that the "envelope sender" had a username
but no hostname (e.g. just "anne"); this is usually
caused by a misconfigured client.
* 551 Relaying denied
This is caused by an offsite machine (i.e. one not in
.concordia.ca) trying to submit mail
If we can't see the error, we can't help with the problem. If
someone says that mail to Concordia from offsite is disappearing
down a black hole with no error messages, then it has to be
traced from the other end. The sender should get help from
their postmaster, who should be able to determine where the mail
stops. The foreign postmaster can then contact me (well,
<postmaster@concordia.ca>) is s/he believes there is a problem
at our end.
I'm currently putting up information about this project at
/nonalcor/email/concordia_antispam.html
Please don't hesitate to ask me if there's something more you need to
know about this project, or if my explanations are unclear.
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)