[milters] Archive

Lists Index Date Thread Search

Article: 315
From: April Lorenzen
Date: 2005-01-25 08:14:10 -0500
Subject: Re: milter-ahead on a backup mx

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support


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.

2. I am confused with this wording: "when the backup MX succesfully 
makes an SMTP connection to the downstream server,"

Erik states he has a gateway configuration, and I am assuming that both 
his pri and sec are gateways ahead of all the virtual hosts. That's how 
my own system is set up, or rather we have several 
sendmail-clamav-milter-siq gateways in front of a single 
sendmail-dbmail-pop/imap machine.

But the way I interpret "downstream" is the virtual hosts protected by 
the gateways.

primary gateway ---------------- virtual hosts pool
secondary gateway ------------- virtual hosts pool

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 

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?


- April Lorenzen

Anthony Howe wrote:

>Removal...........: milters-request@milter.info?subject=remove
>More information..: http://www.milter.info/#Support
>Anthony Howe wrote:
>>Erik Hensema wrote:
>>>Now I want to install milter-ahead on our backup MX, but I was thinking to
>>>alter the behaviour a bit: when the backup MX succesfully makes an SMTP
>>>connection to the downstream server, the backup MX should reject the
>>>connection with a 4xx temporary error. This is because when the backup MX
>>>can make a connection to the primary, the client should also be able to do
>>Interesting twist. You are right of course that if the primary is up 
>>that by definition of how MX servers are to be used that the client 
>>should be contacting them always unless. Most spammers abuse secondary 
>>MXes in an effort to slip past spam filters.
>>My only concern is some primary MXes temporary reject a message, using 
>>grey-listing, or simply busy. Some poorly written clients then try the 
>>secondary immediately (most likely spamware) or queue the message to 
>>retry later on the secondary.
>I've been rereading RFC 974 MAIL ROUTING AND THE DOMAIN SYSTEM. In 
>particular section "Interpreting the List of MX RRs", paragraph 7, 
>sentence 2 and 3:
>	The mailer is required to attempt delivery to the lowest
>	valued MX. Implementors are encouraged to write mailers so
>	that they try the MXs in order until one of the MXs accepts
>	the message, or all the MXs have been tried.
>The only requirement above is a client MUST try the primary MXes
>first before trying secondary MXes. It does NOT say that they MUST only 
>delivery to the primary when it is online. The above suggestion might 
>break legit mail delivery in the event of temporary (421 busy signal) or 
>permanent rejection (554 weclome message) from the primary.
>I'm willing to entertain an option to try this, but I have a feeling it 
>will ultiimately be a bad idea. Comments?

Lists Index Date Thread Search