[milters] Archive

Lists Index Date Thread Search

Article: 317
From: Anthony Howe
Date: 2005-01-25 09:23:27 -0500
Subject: Re: milter-ahead on a backup mx

Removal...........: milters-request@milter.info?subject=remove
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 
> connections"?

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 
option -B.

> 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
http://www.snert.com/       ICQ:
7116561         AIM: Sir Wumpus

            "Once...we were here."  - Last of The Mohicans


Lists Index Date Thread Search