On 16/02/2012 23:07, Tom Hendrikx wrote:
On 16-02-12 23:52, Dipl.-Ing. Juergen Ladstaetter wrote:
Thank you both very much. That input was very good and I might rethink the
strategy we're aiming at. Probably active DNS checks and periodic re-checks
are better to ensure some security. Thanks guys
Checking DNS at input time would still suffice.
You simply require that domains entered have their MXen pointing to a
predefined set of hosts (your cluster). They might change their own MX
records later on (which will only harm the customer), but ibm.com will
never point to your MXen to your cluster, so no customer can ever enter it.
As long as you don't allow changing the domain itself without a
re-check, no customer will ever be able to configure a domain that has
MX records not controlled by that same customer.
Shops that do hosted exchange etc (google, outlook.com) ask you to
(temporarily) add some unique key/identifier to your DNS zone on order
to prove that you actually own the zone (and the MX records). Same
principle, but a bit more work for the customer.
-----Ursprüngliche Nachricht-----
Von: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] Im Auftrag von /dev/rob0
Gesendet: Thursday, February 16, 2012 3:38 PM
An: postfix-users@postfix.org
Betreff: Re: forcing MX lookups
On Thu, Feb 16, 2012 at 03:20:30PM -0500, Michael Orlitzky wrote:
On 02/16/2012 12:13 PM, Dipl.-Ing. Juergen Ladstaetter wrote:
yet. Is there any way to configure postfix to always make MX record
DNS lookups, or is the only way through a second postfix instance
that has no localdomains specified?
Even with two instances you could have problems.
For example, your users might have aliases that get expanded on the
incoming instance, where the maps are controlled by customers. If one
of your customers sets up example.com, and has u...@example.com
aliased to u...@example.net hosted elsewhere, they could be open to
another customer stealing the example.net mail.
If there is a way to force all alias expansion to go through the "clean"
instance, this might work. Only thing I can think of is to append a domain
component to all such names as used in aliasing, stripping it off on the way
out. Then if it's valid, the "clean"
relayhost would pass it right back.
u...@example.com u...@example.net.Juergen
Maybe either generic(5) maps on the "dirty" instance, or canonical(5) on the
"clean" one, could strip this out and send it properly.
One instance per customer is /probably/ safe, but I wouldn't swear to
it without some more thought.
At least in that case they'd only have themselves to blame. :)
I would also consider periodic automated DNS checks which would disable any
domain where DNS points elsewhere. (Or at least alert administrators to
check on it.)
The alias expansion suggestion above also highlights how/why this is
quite a challenging problem if you can only rely on polling DNS entries
that you don't control to see if some twit changed them on you... Also
the dual instance fix is an imperfect solution... Ideally we would have
support from the MTA itself..
I think this is a general problem for any mail admin who needs to allow
(untrusted) customers to dynamically update the list of domains hosted
on a given machine (ie where the customer controls the DNS, not us). I
have the same problem and don't have a clean solution. I suspect that
the folks arguing in favour of trying to make this solely a "web
application problem" don't have such a customer base?
As the OP suggested, a desirable solution would be for the MTA to only
check the various maps to decide a domain is local *after* having done a
DNS check to see if the MX record points "to this machine". ie the end
goal is if the MX record points to some other machine, then we deliver
to that machine, even if it's listed in our maps as being local...
This does seem problematic to implement though. My first thought would
be a special case for the transport map where the "next hop" can be
short circuited to be a "no-op" if the DNS result actually points back
to us? (Perhaps could be implemented using a daemon providing some tcp
tables based service?).
The challenge seems to be how to identify if a given MX result actually
means "me", especially in the case where there could be a cluster of
machines, multiple A records, hostile reverse DNS or even exotica such
as anycast dns...? I guess if you know all the IPs of your machines you
can do something (fragile)? Or if you can enforce that the MX record
points to a specific named A record? However, seems pretty fragile and
easy to make yourself a mail loop?
Some kind of custom tcp tables seems like the only workable solution
here? Have all the customer (untrusted) mail domains have a dynamic
transport map, then you can have some kind of checking heuristics to
test the MX records point to our server(s). Perhaps look for specific A
record names, followed by a connection to the destination server to
check the mail banner if we aren't 100% sure?
Grateful for better ideas from those who have tried to tackle this?
Thanks
Ed W
