[ On Wed, May 14, 1997 at 16:21:09 (+0100), Philip Hazel wrote: ]
> Subject: Re: Prevention of realying offsite.
>
> Anybody can add an MX pointing at you. Have I misunderstood you, or does
> that give them the power to force you to relay to them? Surely I've got
> this wrong...
Yes, of course. Foreign zone operators have always had the ability to
force other zone mailers to relay for them, but this is something we
live with in the design of the DNS. If I have authority over the
nobody.none zone, then I can just as easily redirect
www.nobody.none to
any one of your IP numbers, or whatever. The DNS mechanisms of zones of
authority assume a co-operative internet right to the core of their
design.
Note that if I list your mailer as an MX for my zone, I'm not increasing
or decreasing your ability to reject spam to your own users, and indeed
your concerns of whether I'm a target of either large amounts of spam,
or just receive large amounts of real e-mail, are essentially irrelevant.
I've had discussions with clients where we've installed smail (even in
face of protests from clients who want sendmail!) regarding the general
ability to "ignore" the MXs which point at local hosts in zones that
have not been locally configured as valid MXed zones. I agree that as
the internet becomes a less friendly place it may become more and more
important to have a list of valid MXed zones configured in the mailer.
If this were so then indeed it wouldn't be necessary to look up the MXs
for the target during the verify in "RCPT TO" processing, but rather
just look in the list.
The basic conclusion of my discussions on this issue to date have been
that I'm not prepared to add a config item for such a list of "valid"
MXs to smail. The risk of abuse is extremely low, and the affect of
such abuse is usually trivial, as there must always be a more specific
MX if the foreign zone wants to eventually receive their email.
I did offer one client the option of adding a "bad_MX" list feature for
their own version of smail, but they never coughed up a purchase order
for the work, and I'm not motivated enough to do it on my own. At least
they were able to make the business decision that it wasn't worth even a
few hours of programming expense to defend against a rogue MX -- it's
much more cost effective to just contact the remote zone administrator
and have them fix it.
If this becomes a problem in the future we need to fix the DNS, not put
hacks for work-arounds into a mailer.
As my business partner is fond of saying "Just use the DNS -- that's
what it is there for."
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
