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

Michael Klimczak wrote:
> Okay, I managed to nail down the issue. Thanks for confirming that exim
> in it's standard configuration should not be the cause of our problems.
> Doing a normal 'traceroute' I could follow the route from my home
> computer to the mailserver, doing a 'tcptraceroute' on ports 25 and 587
> revealed that they were already cut off halfway through by one of the
> gates of the university.
>
> Best regards,
> micha

OK - by messing with port 587 they are perhaps being overly cautious, but that's
not a bad thing. Universities are full of 'rule benders'.

;-)

IF there are ports open, and IF it won't get you in trouble (see their Tos or
whatever..) you can run Exim on one or 'many' non-standard ports and configure
MUA accordingly so you can submit or recover POP/IMAP.

You will still need a smarthost to send OUT of Exim, (else fail an rDNS test),
and may have NO practical way for arrivals from 'the wide world' to get IN, as
they expect a listener on port 25 (and no other) - which the Uni is blocking or
intercepting.

Bottom line is you'll need to find a way to VPN to-from a box & IP *outside* of
the Uni's firewall and run the MTA from a point where it CAN listen on (at
least) unblocked ports 25 and 587. Unless that 'place' (leased virtual host?)
includes a fixed-IP with PTR RR as well as MX (or at least A) RR, you will still
need a smarthost.

If you find all that not worth the cost or bother, one can still learn a great
deal about how to configure and admin Exim by aliasing-up a pair of IP on one
box, run a separate Exim instance with its own configure file on each IP, use
entries in /etc/hosts to simulate a DNS (or actually run one or more locally),
and experiment.

No need to even have a hardware NIC, let alone a 'real' connection.

And the only thing you can shoot yourself in the foot with is virtual bullets...

;-)

Bill



>
> On 10/29/2010 07:12 AM, W B Hacker wrote:
>> 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
>>
>