Am 05.04.2014 19:34, schrieb Miles Fidelman: > li...@rhsoft.net wrote: >> >> Am 05.04.2014 17:01, schrieb Miles Fidelman: >>> It strikes me that I haven't seen a general answer to the original question >>> how to set up PTR records when one is serving more than one domain under >>> the same IP address. >> don't setup PTR records and A records for a mailsever >> setup *one* PTR record, *one* A record and *one* HELO-name >> >> just use a generic hostname like "mail.yourcompany.tld" and >> use that as MX records for as many domains you are hosting >> on that mailserver >> >> that: >> >> a) works >> b) is consistent >> c) don't bring you in trouble if it comes to TLS >> d) keeps things simple >> >> proven by hosting some hundret domains for a decade on one hostname > > True. And that's pretty much what I've ended up doing. > > One minor nit, though: when one is hosting email for clients, the generic > hostname needs to be something innocuous > (for example, when you use godaddy's mail services, all the mail goes out > from xxxx.secureserver.net)
well, "mail.yourcompany.tld" should be innocuous enough and if someone asks why you find easily a dozen large mail providers to point here "because they are doing the same and it just works" we had also "mail.customer1.tld", "mail.customer2.tld"... until i stepped in and stopped that because here and there someone forgot the MX or the A-record or both and now instead of fighting with that the mailbackend set's the MX to always he same generic name at that time TLS was no topic because the old Apple based mail server did not support it at all - after i built the new mail systems with encryption i was glad to clean that up long enough before and keep things as simple as possible _________________________________ general rule for administration: if you have 5 ways to achieve the same result chose the simplest one until you find no good reason not to do so - in the best case choose a lot of simple implementations you understand and can explain if somebody wakes you in the middle of the night, stick them together to a big picture if sooner or later one of the pieces will fail you will be thanful if you can fix that or even replace it with a better implementation not known at the first start without touching the other pieces at all that's why postfix has different processes for different tasks and works for decades while not care about storage, sieve, responders and what not because they all can be intergated however someone needs
