An end to spam through Graphnet

Michael Dillon michael at
Fri Aug 1 23:02:49 UTC 1997

>Can anyone elaborate a little more on the "one true" set of procedures
>that one should take to prevent spammers from abusing ones resources.

1. dump sendmail. It can't prevent relaying.

2. install qmail because relaying is disabled right
outr of the box. In fact I had to dig for a while to figure out how to
relay mail to a server behind a firewall.

3. lean *HEAVILY* on the vendors of email client software to *STOP* *THE*
*MADNESS* of using SMTP to send email. They need to do this via the
authenticated POP or IMAP sessions. Standards be damned. If the vendors
can't agree on a standard for doing this then it is less headache to hack
POP and IMAP servers to handle a half dozen proprietary ways of sending
email via POP/IMAP than it is to deal with SPAM relay messes. P.S. get your
customers to lean on their email client vendors as well. In fact, supply
your customers with email addresses at the email client vendors and tell
them to request this enhancement.

IMHO, of course.

Seriously though, don't expect that you can install a simple sendmail
recipe and solve this problem. The best recipe so far comes from Klaus
Assman but it
requires some upkeep to do it this way.

Point 3 is the ideal solution and I really do believe that if an
information campaign is waged with the vendors, this really could be done
within a month or two.

>The current problem that I have is valid customers who are "on the road"
>and want to sendmail through my SMTP server when they dial into
>att or netcom, before their eudora's used to point their SMTP server
>at me, that ain't happenin' after my spam attach so is there some work
>around that they can use?

Basically, you have to have sendmail allow certain email to be relayed
based on whatever you have to identify those customers. Static IPs are
great, no problem. Small corporate LANs with dialin ports are probably OK
because they probably have their SMTP relaying disabled. But if a customer
is roaming with an AOL account then you can't solve the problem. All you
can do is to tell them to use AOL's SMTP servers when they are dialing in
via an AOL account.

I think this discussion is really pushing the bounds of what is on topic
for this list and unfortunately the Eudora Pro I am using does not seem to
support Reply To headers so here are a couple of better mailing lists to
discuss this on.

inet-access   -  high volume, can be over 200 messages per day, sometimes
                 gets overwhelmed by chit-chat

send a "subscribe" message to inet-access-request at

IAP  - much lower volume list. Some days there is only one or two messages
       but the volume can perk up if there is a hot topic.

send a message reading "subscribe IAP Your Name" to listserv at

Please don't reply to this message on the NANOG list. Please change the To
address to either inet-access at or IAP at


Michael Dillon                    voice: +1-415-482-2840
Senior Systems Architect            fax: +1-415-482-2844

"The People You Know.  The People You Trust."

More information about the NANOG mailing list