On 18/04/07, pisang <pisang98@???> wrote:
> I have debian with Exim 4.50-8sarg running as a backup
> MX so I added my dc_relay_domains in de config
>
> 1) How many dc_relay_domains can I put in this config
> ? I'm not using the split config and its getting long.
Your question seems to relate to the Debian Exim configuration method,
which is supported on another mailing list - see your Debian Exim
documentation or
http://pkg-exim4.alioth.debian.org/
>
> 2) I do not wish to discuss the need / or not of a
> backup MX. I want to run one but I want the following.
>
> When a message is recieved Exim checks if the primary
> mail server for the recipient domain is up. If its up
> it deny's the message.
> Only when the recipient domain / primary mail server
> is down the message gets queued and relayed when the
> primary mail server is back up.
This is unsafe. Transitory network conditions could have prevented an
MTA from connecting to your primary. Additionally, the remote MTA
might queue a message before trying the secondary - that behaviour is
permissable.
You *will* reject wanted mail this way. Maybe not a lot, but not none, either.
> I have tested this with ACL.
>
> deny
> domains = +relay_to_domains
> verify = recipient/callout=1000s,nocache
> message = Primary MX for $domain is up, please try
> that.
>
> It only works without the nocache. but then my accept
> doesnt work since the recipient lookup is cached and
> it deny's the message.
>
> Is there a way to use verify = to check if the primary
> mx can reply's to ping ? =up&running
You could probably arrange a cron job to ping the primary once a
minute and update a file with the result, and use that file with
${readfile in your ACL. But again, unsafe - respond to ping != MTA is
running and accepting mail. That's what backup MXs are for...... your
way, you *will* reject wanted mail if the primary goes down.
> -------
> I want the behavor of Milter-ahead for sendmail
> http://www.snertsoft.com/sendmail/milter-ahead/index.shtml
>
> -primary-up-reject
> We are a backup MX and we want to reject mail when the
> primary MX is available. This does not conform with
> RFC 974 & 2821 mail routing, which only requires mail
> clients attempt delivery to the primary first, before
> trying other MXes.
RFC974 is historic (and 21 years old) - probably best to let it rest in peace.
You have no idea whether they tried the primary first or not. The
'attempt delivery' could fail for plenty of reasons which are not
dependent on whether your primary server is up and receiving mail or
not. Some of these conditions are indistinguishable (by the sending
MTA) from your primary being down, too.
What you *know* is that they tried the secondary.
> Spammers often attempt to by-pass spam filters by
> sending email directly to secondary MX machines, which
> often have weaker requirements. This option
> essentially demands that a client only deliver to the
> primary MX when it is available.
If you could detect 'available' from the perspective of the sending
MTA, this would be a valid technique.
Peter
--
Peter Bowyer
Email: peter@???
