On 2008-04-22 at 16:02 -0700, Jeroen van Aart wrote:
> Below applies to options 1a and 1b?
The first part, yes.
> Would adding the "condition =" statement be enough to allow email to be
> sent out if delivered on port 24? I understand I should ask this on the
> debian exim list, but maybe someone has the answer.
If I understand what you're asking, yes. My head is not very clear
right now, though.
> Exim is configured to send to a smarthost and the below configuration
> section applies:
>
> smarthost:
> debug_print = "R: smarthost for $local_part@$domain"
> driver = manualroute
> domains = ! +local_domains
> transport = remote_smtp_smarthost
> route_list = * DCsmarthost byname
> host_find_failed = defer
> same_domain_copy_routing = yes
>
> Apart from "condition = ${if =={$received_port}{24}}" what would I have
> to add/edit here to make the above work? I assume something like:
I missed something you said originally, because my head wasn't as clear
as I thought it was, which is that the ability to send out via a
smarthost should remain as a default. Sorry.
Drop option 2 from my original answer. It doesn't apply.
Add a new Router, direct_outbound, which should be a dnslookup router as
you suggest; add the condition to this new Router and put the new Router
before the "smarthost" router.
Now, as to how you integrate this into Debian, I can't help you there.
> > If you want to check that the mail was received from this machine, on
> > port 24, then:
> >
> > condition = ${if and{{=={$received_port}{24}}\
> > {match_ip{$received_ip_address}{@[]}}}}
>
> Could I substitute $received_ip_address with the actual IP, 127.0.0.1 in
> this case? Of course this would not really be necessary since localhost
> can't be reached from the outside. But if I wouldn't do that and the
> listening port would be changed to an external there suddenly would be
> an open relay.
First, the $received_ip_address is the actual value it was received on,
you'd want to replace @[] with 127.0.0.1; however, that blocks any
future use of IPv6, so you'd want:
<; 127.0.0.1 ; ::1
to support that; further, it won't let you connect to the public address
of the machine, directly, say "telnet `hostname` 25". @[] is easier,
but if you really want the localhost restriction, go ahead.
There's no open relay risk here; nothing I did changed the logic of
which hosts are allowed to send out, since localhost is already
permitted to do so. We changed the routing policy for host for which we
were already permitted to relay.
Second, localhost can be reached from the outside, by default.
Unix systems, in the absence of packet-filters configured to change
this, implement the Weak End-System Model; this means that packets
received on any interface for the address of any other interface are
accepted as intended for this host and processed accordingly. This is
why the "pf" packet filter (from OpenBSD, used on various BSD systems)
lets you do "antispoof for lo0" as the really trivially easy way to stop
this.
If you have a service configured to listen on 127.0.0.1 and no
anti-spoofing protection, then I on my machine on the same network
remove 127.0.0.1 as a local IP address and insert a static ARP table
entry associating it with your external ethernet adaptor; that value
will be learnt just by exchanging normal traffic with you. Thereafter,
I can send mail from my normal IP address to 127.0.0.1 and you'll reply
to the normal email address and the traffic will flow and your service
is exposed.
In practice, 127.0.0.1 is reachable for anyone on the same network, or
other networks if the attacker can insert routes pointing towards you
onto intermediate routers. You need basic packet filters to prevent
this. It is not secure by default.
-Phil
