This is actually a WRONG way of having your mail setup. If gw.mail.com
is not acessible from the public Internet, then it has no business being
listed in the public DNS for any domain.
Its probably a case of the admins at 'mail.com' not knowing how to tell
recv.mail.com to pass on the mail to gw.mail.com via a private routing
config, and deciding to let it use the DNS instead.
In any case, this isn't really a problem for you to fix, but for the
admins of that domain. If you have clients/customers/etc call you and
want to know why their mail wont go through, you would be 100% accurate
to tell them it is a problem with the 'mail.com' domain.
On 30 Aug 2001, Thorkild Stray wrote:
>
> Hi!
>
> I have a small problem with delivering mails to a couple of domains.
> These domains have MX-records like this:
>
> [mail.com is not the real domain]
>
> adm.mail.com MX 5 gw.mail.com
> adm.mail.com MX 10 recv.mail.com
>
> gw.mail.com does not allow connections directly to itself, it is
> firewalled. To send mail, one must send it to recv.mail.com, which is
> allowed to connect to the gw directly.
>
> Now, this all works, because Exim will try recv when gw doesn't work.
>
> The problem is when this has been going on for a while. Then the
> "gw.mail.com" machine is blacklisted in Exim and it is bounced with:
>
> retry time not reached for any host after a long failure period
>
> because the gw has had a long failure period.
>
> I have though of a couple of ways to handle this, amongst other:
>
> 1) Specific routing for this domain (not good, since it probably isn't
> the only one).
>
> 2) setting retry_data_expire to be lower than the final bounce-limit.
> But this means mail will never be bounced because it never reaches
> the limit.
>
> Neither of this seem to be the correct solution. What is the best way
> of handling this?
>
> I searched the archive and found a reference that said deliveries to
> fedex.com had the same problem, but it did not list a better solution. u
>
>
--
