[Mimedefang] Previous relay informationy

Whit Blauvelt whit at transpect.com
Thu Dec 14 19:42:46 EST 2006


On Thu, Dec 14, 2006 at 08:54:53AM -0600, Damrose, Mark wrote:

> There is no practical way to know of transient connection problems
> between you and all potential senders at all times.  Just because your
> "primary" is up and has an Internet connection doesn't mean it is
> reachable from all hosts within their timeout.  If you have more than 1
> MX, be prepared for *all* of them to be used.  Best practice is to apply
> the same policy to all of them.

Really? I don't see much evidence of transient problems doing that. Or maybe
it's just that my secondary MX is at my provider, whereas I'm on an SDSL
line downstream from them, so anything transient affects the secondary at
the same time as the primary. In theory you're right, but in practice that
hasn't bit me much in many years of running this way.

> A secondary on a more dependable connection is a good thing, so long as
> it is under your administrative control.

Yeah, there would be an advantage is owning administration of the whole Net.
I do run systems remotely on T-1s - that have more outages problems than
I've had on my SDSL - go figure. It's more important to me as a business to
have the solidest secondary MX available, even if it gives the occasional
spam a chance to slip in sideways.

The question of how to go into those Received headers is interesting though
- not just for secondary MX parsing. Of the spam that still gets through
to me, a fair portion fakes receipt by my own domain as the earliest
Received step. So far the easy way to grab that telltale to drop the spam
eludes me. There's a elaborate header-parsing module in SpamAssassin now,
but if it can be called within Mimedefang I haven't found specs or examples
on doing that yet. Then there's going after
/var/spool/MIMEDefang/mdefang-xxx/HEADERS directly ... probably doable.

Whit



More information about the MIMEDefang mailing list