From: Anthony Howe
Date: 2005-01-25 09:23:27 -0500
Subject: Re: milter-ahead on a backup mx
More information..: http://www.milter.info/#Support
April Lorenzen wrote:
> 1. Ignoring what is practical for the moment and asking what might be
> ideal, to reject at the secondar(y/ies) if the primary has not been
> tried in the past X time (configurable) might be useful. If the primary
> (or another server which reports the info of what connections the
> primary has successfully serviced recently) is unable to answer that
> question, secondar(y/ies) handle the connection.
While thinking about this this morning, I figured this sort of tracking
might be interesting to do in some manner, but would require a new
milter or significant changes to milter-ahead to act in client/server
type of configuration between secondary and primary respectively.
For now though, rather than do something semi-intelligent, a simple
option that just enforces a policy is what I've implemented.
> 2. I am confused with this wording: "when the backup MX succesfully
> makes an SMTP connection to the downstream server,"
> milter-ahead needs to not only ask the virtual hosts "do you have this
> user?" --- the existing functionality of milter-ahead
> But for the new function we are discussing, it seems milter-ahead would
> not be asking the downstream virtual hosts pool - it would be asking its
> peer (albeit first in line peer) the primary MX - "are you accepting
No. milter-ahead does not do DNS lookups (yet) or connections to
downstream (secondary --> primary) checks based on DNS. milter-ahead
remains as always using mailertable information of the next hop.
However in some situations where milter-ahead is used on secondary MX,
you want to tweak the behaviour of milter-ahead to take into account
whether the next hop (assumed to be the primary) is online or not. See
the -b option. Erik's original suggestion intended to alter the
definition of -b, but I choose to implemented it as a separate policy
> So I don't understand the logic of deciding anything about whether this
> is a legitimate connection which may have been deferred or rejected by
> the primary MX, by asking the "downstream" anything?
In theory (old times) a secondary MX would have little or no traffic. So
the fact there is now a connection coming in that will eventually go to
the primary, you have to wonder about the state of the primary. If its
offline or busy, you want to accept the message and relay it later. But
if the primary is not busy, then you have to wonder WHY is the secondary
being contacted, given how MXes are to be used by RFC 974. In this case
you might choose to break with RFC 974 and enforce a strict policy that
says: secondary MX rejects if the primary is online and available.
Given how some spamware works these days, its an interesting policy choice.
Some may note that there are some behavioral assumptions that could
result in race-like conditions in the above logic. It assumes that a
secondary is being contacted first or immediately after trying the primary.
For most people the idea of "secondary MX rejects if the primary is
online and available", would be too risque, since you can't be 100%
certain as to why the secondary is being contacted without additional
tracking information communicated between secondary and primary.
Anthony C Howe +33 6 11 89 73 78
7116561 AIM: Sir Wumpus
"Once...we were here." - Last of The Mohicans
Copyright 2009, 2012 by SnertSoft. All rights reserved.