Re: [exim] Cannot send mail from outside of local network

Michael Klimczak wrote:
> Hi,
>
> sorry if this question has been asked before but I could not find a
> suitable solution.
>
> Exim is set up to receive mail from users and forward them to another
> smtp for delivery (smarthost setup). Authentication via sasl and TLS
> encryption are working. From the basic setup I would have assumed that I
> now should be abel to send mail over the exim. However, this is only
> working from within the local network.

>
> Am I missing a configuration step in exim to enable connections from
> outside or is it likely that there is an external cause for these issues
> (I am sure there is no conflict with the firewall). Currently,
> connections from outside do not receive a rejection, they just time out.
> So far, I've tried setting auth_advertise_hosts to * (but this should be
> the default anyway).
>
> Any help would be appreciated,
> micha
>

Exim doesn't know care if it is inside or outside. Other parts of the
environment may be less cooperative.

telnet from outside to your domain.tld or IP and whatever port you are using for
submission, and you should be able to 'see' what is happening.

My guess is that you have Exim listening for submissions only on port 25.

Your LAN won't necessarily block or intercept traffic TO that port (though it
can be a good idea..).

'Outsiders', OTOH, may be connecting via an ISP that DOES intercept or block
traffic 'to any port 25' when it originates from 'inside' their customer IP pool.

Accordingly, in order to reach your Exim from the wide world, and not just the
lax ISP's, you will have to use a port NOT ordinarily blocked by ISP's.

Port 587 requiring TLS and valid authentication is the recommended choice.

If that is also blocked (fairly rare) next/also try port 24 (any private
email..), and configure Exim to use TLS and require auth on it.

NB: If blocking arrivals whose IP has no PTR RR or otherwise fails rDSN check,
remember to exempt those connecting via port 587. Rely instead on proper
protocol and valid auth. Few will ever have the sort of 'credentials' an rDNS
check seeks - nor should they.

HTH,

Bill