From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: news.admin.misc,comp.mail.uucp,comp.mail.sendmail,comp.mail.misc
Subject: Re: Any easy way to filter this type of UUCP traffic?
Date: 7 Nov 92 06:39:56 GMT
Followup-To: news.admin.misc
Organization: Elegant Communications Inc., Ottawa, Canada

In article <1992Nov7.002938.8197@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:
>In <1992Nov5.165936.13003@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes:
>
>> What starting my bitching last year was uunet's refusal to filter out mail
>> traffic routed thru DMSD. I wanted them to ONLY forward mail with a terminal
>> address at dmsd (dmsd.com). My site was being flooded with a high volume of
>> traffic passing thru UUNET/DMSD link due to automated mail routers ... this
>> depleted my lowvolume account in a couple months. And left me with a
>> several hundred dollar unexpected bill

>Does anyone know how the average site can do this?

There's nothing that John can do to his mailer to prevent this.  Because by
the time that his mailer gets to see the message, it's too late - the transfer
cost has already been debitted...

The solution to John's problem (and your potential problem too) is in the
map entries.  Not the mailers per-se.  When you subscribe to uunet, uunet
puts the uunet link in the maps so that everybody else can get to you
via the uunet link.  However, if you're not careful with this map entry,
everything destined to other machines that you talk to go through that
link too.  uunet.ca (and I presume uunet too) give you the option of
being a "terminal" site.  That is, the uunet map entry will look like:

uunet	... <{sitename}>({cost})

The angle brackets indicate that nothing should be routed *through*
"sitename" to other machines.

Furthermore, you shouldn't advertise the uunet link in *your* map entry
at all.  Otherwise, large numbers of systems may choose you to get to
uunet.

I operate this way with uunet.ca.  And I know that if it didn't work, I'd be
getting *lots* of traffic through the link that shouldn't be there.

Remember, if you mention the link to uunet in *your* map entry, you're
advertising it for everybody to use.  So DON'T DO THAT.  And make sure
that uunet's map entry that lists the link marks you as terminal.

I did encounter a few messages passing through my site over the uunet.ca
link.  And that was because rutgers ($%^%^& rabid rerouter) was
ignoring the <> somehow, and autorouting everything through me to
a couple Ottawa sites.

If, after your map entries are fixed up properly, you still have
stuff traversing the link, either:

	- the originator is explicitly requesting the route through you.
	- some smart-routing MTA (rabid or not) in the path has a broken
	  pathalias setup and is ignoring the <>.

A polite request to the originator to desist, or postmaster with the busted
MTA should fix the problem.  If the originator refuses, go after their
postmaster.  If the postmaster refuses, ask uunet for help.  In my case,
uunet.ca was even willing to credit back to me the charges.

>I have a similar problem. My fixed price agreement with PSI says I can't pass
>"third party" email thru them. However, when I asked if they could filter it,
>the answer was NO.

They *can't*, because by the time their mailer sees it, it's already
traversed your PSI link.

>They put it in the contract, but then don't make it easy
>for you to comply. Fortunately I haven't noticed any traffic yet.

If the maps are set up properly, and nobody attempts to manually
route, you won't see any.

>I'm running the stock smail2.5/sendmail that came with my ISC Unix 3.01.
>I don't understand sendmail well enough to know if I could come up with a
>.cf change that would keep me from feeding third party email to PSI, and
>also would drop any third party email from PSI onto the floor.

It's *relatively* easy to hack smail2.5 to bounce mail that is passing
through your site to another.  If you have (or get) source to it.
I have implemented *something* like this (it only sent back nasty
messages to the originator), but it won't do precisely what you want.
If you have questions on how to do this, I can give a bit of an
example, plus point out where and what you have to diddle the source
to implement this.

It's probably even easier to hack sendmail.cf to do it, but I'm not
going to venture any suggestions.

I've not run smail 3, so I can't help there.

PP and MMDF can be configured to do this.

There's one really simple solution:

	mv /bin/rmail /bin/rmail.real

Then, create a shell script /bin/rmail that does something like
(warning, probably incomplete, untested):

	for i
	do
	    case $i in
		*!*)
		    # exitting here drops the mail
		    # you should really bounce it, but
		    # bouncing it requires that you parse
		    # the message body to find the From/From:
		    # lines.
		    exit 0
		    ;;
	    esac
	done

	exec /bin/rmail.real $@

This will work provided that your MTA never calls /bin/rmail for
locally generated mail.  Which should be the case with both
sendmail or smail.  *Provided* that, with smail, you have a /bin/lmail
and smail uses it for local delivery.  Sendmail should be doing
local delivery all by itself.

This will drop *any* mail from passing through your system, but
permit anything destined locally to work.  If you want to
permit passthru to anywhere *but* PSI, you'll have to
replace the "*!*" clause with something like: "uupsi!*".
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca
Newsgroups: news.admin.misc,news.admin