Comtarsia SignOn Solutions

http://signon.comtarsia.com/main/en/LDAP

Mac OS X Server: Alternatives to Windows NT 4.0 domain control (PDC) technology

http://support.apple.com/kb/HT4945?viewlocale=en_US&locale=en_US

mdns and dns-sd

mdns and dns-sd

saw this post when researching an answer for a question on macenterprise.org

mdns uses link local multicast ip addresses. 224.0.0.251 http://en.wikipedia.org/wiki/Multicast_DNS

according to RFC 3171, that range of addresses is reserved for "Local Network Control Block"

http://tools.ietf.org/html/rfc3171 Routers are not allowed to forward these packets between subnets.

Bonjour does support DNS Update http://www.ietf.org/rfc/rfc2136.txt which allows servers to register their services to normal DNS servers. This allows clients to query DNS for services (eg. what are all the ipad compatible print servers?)

Here are the docs on how to set up your unicast DNS server to support Bonjour across subnets: http://www.dns-sd.org/ServerSetup.html

Basically you will set up a dns zone file reserved for dns-sd. For example, macenterprise.local. Your print servers, workgroup manager clients, etc, will not only respond to mdns queries for their service, but also publish to the macenterprise.local DNS server those same services.

On the client side, you set up your clients to query the dns-sd zone, add it to the list of search domains (system preferences -> network -> advanced -> dns).

Now, when your ipad wants to print, it will send out the normal link local multicast packet to 224.0.0.251 port 5353, and it will send out a normal unicast dns query to the name server (NS) for all the configured domains in its search domains (including macenterprise.local). The client will get back available responses from both queries and show them all to the user.

You could get your DNS admin to do the magic on the normal organization DNS server or you could set up a mac server and request that your DNS admins set up an NS record for your mdns domain to point to your mac server. It depends on how much they want to help you. At the very least, if a different group manages your dns servers and they are reluctant to help you, they should have no problems creating an NS record and putting the burden of support on you.

I found a good description of client set up here: http://dyn.com/support/bonjour-and-dns-discovery/

__________________

Apple, release a new MacBook Pro!

RE: Finally blocking some spam - ReadList.com

http://readlist.com/lists/postfix.org/postfix-users/22/111322.html

I agree that these methods are AGGRESSIVE, NO question, but if I'm getting no complaints from clients how can I not continue to utilize this method given that there aren't a whole lot of things that can be done. People have told me over time that I am too aggressive with the RBL's I use, but it has been successful with almost no FP. My list: reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client psbl.surriel.com, reject_rbl_client ix.dnsbl.manitu.net, You reach a point where the money we think we are profiting from services sucks up all our time and resources and somehow we have to reduce that overhead and SPAM. Imagine that we are blocking millions of spam messages a month through various methods and we have clients complaining about spam... what are we to do. It gets really old.