On Thu, Oct 23, 2003 at 09:20:46AM +0100, Karsten M. Self wrote:
| on Thu, Oct 23, 2003 at 05:32:59PM +1000, Rob Weir (rweir@ertius.org) wrote:
| > If you have the level of MTA control neccessary to automatically reply
| > to CR queries, then just block Swen at the MTA level. I've rejected
| > 34552 incoming Swen mails in the past few days, before my MTA even
| > receives them. Unfortunately, my secondary MXs don't know to drop that
| > crap, so they accept it and then try to send it on to my mail server,
| > making that count rather inflated.
|
| Incidentally, a friend tells an anectdote of turning on teergrubing in
| exim4 per Marc Merlin's configuration...and promptly teergrubing the
| hell out of his secondary MXs. Might want to ensure that these are
| excluded from any countermeasures you take.
This brings up the issue of functional versus non-functional secondary
MX set ups.
Your secondaries must enforce the same policies as your primary.
Otherwise you will either receive junk via your secondary that you
would otherwise not see through the primary (eg for HELO or IP based
checks) or your hurt your secondaries when you teergrube them or
reject the message forcing the secondary to try to deliver a bounce
message.
Your secondaries should only be queueing and passing on mail that the
primary would have accepted and delivered anyways.
If you don't have enough control over the secondary to enforce the
same policies, it is probaby better to not have a secondary at all.
If that isn't an option, then you do need to exempt the secondary from
all anti-UCE policy checks.
Note, too, that you should have a comprehensive listing of valid
recipients on each of the primary and secondary mail servers so that
invalid recipients can be rejected as soon as possible during a
transaction.
| > Hm, now I check, 27253 of those did *not* come from my secondary MXs.
| > That is a stupid amount of crap. In fact, it is 3.8985GB of crap.
|
| Do you always measure crap to four significant digits ;-)
ROFL :-). Thanks for the laugh, Karsten.
| > Imagine that instead of dropping that shit on the floor, you sent a CR
| > query. You've just doubled the number of mails flying around (thought
| > not the volume, of course).
|
| Doubled mail. For no useful effect. And required 4GB of spool
| space, extended over the 1-2 weeks you hold your contested mail.
Good point. It hurts the C/R user too. Here's an idea for your
(currently vaporware) automatic challenge-responding bot -- hold on to
the challenge token for the 1-2 weeks, then respond. Then you've
maximed the length of time the crap sits on disk before being received
anyways. Once you've passed the C/R test, your bot can automatically
send a canned "how to handle this better" message.
-D
--
Pleasant words are a honeycomb,
sweet to the soul and healing to the bones.
Proverbs 16:24
http://dman13.dyndns.org/~dman/
Attachment:
pgp3aIWIeCg8z.pgp
Description: PGP signature