[Mimedefang] OffTopic : Need some sendmail help (access configs)

[Michael Sofka]

On Monday 20 December 2004 01:07 pm, Matthew Hall wrote:
> OK, so access will reject all networks, BUT, because we enable
> delay_checks, that gets delayed long enough to hit the
>
> spam:@ourdomain FRIEND
>
> and be accepted for relay to our smart host? That spam rule
> looks for To:@ourdomain, not From:@ourdomain, right?

That should be "To:@your.domain   SPAMFRIEND"
(Page 320 of the ``Batbook.''  If you run a sendmail MTA you
should keep, and consult, a copy of the Sendmail book. I didn't
consult my copy when I wrote my first reply, and look at
the trouble it's caused. :-(

BTW, I have not tested SPAMFRIEND with just a domain, but it
will probably work.  And, if it doesn't then MIMEDefang is
probably the best way to accomplish your goal.  (It would
certainly be quicker than trying to extend sendmail.cf.)

What delay checks actually does is not delay the decision, but
put off taking action on decisions until more of the header
is read.  To change decisions, you need to use the `friend'
and `hater'  options to delay_check since they override
previous rules. (Not exactly, but close enough for this
discussion.  The not-quite full details on are section
7.5.6 of the Batbook.)

> But if I'm rejected all class A's via above, what is this for?
> I would then have to readd several C's ... if I add those C's,
> would they still be subject to the spam: rule, or will they
> pass through?

You are rejecting all class A's so random machines cannot
find you.  You can also block with the firewall, and that may
be a better choice for your case.  We have several machines
which can only be accessed by our SMTP relays, but we provide
a helpful message via the access file for those users who
(still) attempt direct connections.

The default access action is "OK", which will attempt local
delivery (on your machine) of email.  This is probably not
what you want.

When you add a class C you are applying to the entire class
C whatever rule you add.  So, 1.2.3 RELAY allows relaying to
all machines in that Class C.  This is why I suggest block all,
then add the allowed addresses.

> > Alternatively, if you know who the email is destined for
> > you can use the userdb to keep a list of maildrops.  As
>
> Nope. There will be over 13K possible addresses that
> @ourdomain will cover.
>
> > an administrator of a "theirmailer" (but, not this particular
> > "theirmailer" machine) machine, I would prefer this solution
> > since it keeps the junk off of our machine.  (For example,
> > if a spammer finds you and starts sending undeliverable email
> > to our.domain, "theirmachine" will get stuck with all the
> > undeliverable email, subsequent postmaster bounces.)
>
> Irrelevant, because ourmailer is "internal". Only their
> mailer has world visibility.

And you vouch for the reliability and security of all those
internal machines?  When one becomes a spambot you will, of
course, detect this via your log monitoring and block the
machine?

No matter how restricted the relay, you are still a relay.

Happy Holidays

-- 
Michael D. Sofka              sofkam at rpi.edu
C&CT Sr. Systems Programmer    Email, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY.  http://www.rpi.edu/~sofkam/