On 21-02-12 20:06, Ed W wrote: > 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? >
I don't run a setup like this, but deal with the DNS verification part of it on a daily basis. I fail to see the real issue here: if a customer actually owns the domain, and he changes the MX records to somewhere else, he'll only scatter his mail delivery (i.e. local mail on your platform, other mail on the new MXen), but this does not harm you, only the customer. Whether the customer is fraudulent or not, he can only influence deliverability of domains he actually added by himself, or that he owns in DNS. The single challenge is that you need to verify that the customer can only add a domain that he actually owns, in order to make sure that no customer can steal mail for remote destinations that aren't his. This last part is relatively easy to solve by creating a procedure to verify that the customer is the owner of the domain in DNS, by requiring him to add a specific key to the zone for ownership verification. Simply said: Google [1] and many others have already solved this issue, I don't see why your situation differs from theirs. Also I fail to see how a fraudulent customer would be able to steal mail for example.net as described in the alias example, if he's not able to prove that he owns the example.net zone in DNS (thus cannot add the example.net zone to your localdomains). Please educate me. [1] http://support.google.com/a/bin/answer.py?hl=en&answer=183895 -- Regards, Tom
