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 [EMAIL PROTECTED] C&CT Sr. Systems Programmer Email, TeX, epistemology. Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/ _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
