on Sat, Mar 21, 2009 at 12:44:15PM -0500, Frank Bulk wrote: > The recommendations in this draft proposal have worked for me: > http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt
Also: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07 In any case, it depends on whether those IPs will house legitimate sources of mail; I *strongly* recommend indicating whether an IP is dynamically or statically assigned, and (ideally) what sort of tech is in use (dialup? DSL? cable? wifi? etc) so that mail admins can make decisions about whether or not to allow mail from those hosts. (Hrm, do I want mail from a dynamic wifi IP? not so much; static generic dsl? okay, maybe for now). If you want to be friendly to folks who don't necessarily want to have to use regexes to match your dynamics, make sure that if you do use some sort of topology- or geography-based naming, that you put the "dynamic" or "static" token as far to the right as possible, so that you end up with rdu-1-2-3-4.cable.dynamic.example.net instead of dyn-1-2-3-4.cable.rdu.example.net because it's a lot easier for mail admins to block 'dynamic.example.net' than to have to have local access.db entries for every last geography you're serving, or have to use regexes. And please don't mix dynamics and statics under the same naming conventions. Finally, if you *do* intend for these IPs to house legit mail servers (or mail sources, for that matter), whether yours or your clients', for the love of all that is good and holy, give them /custom/ PTRs that indicate the actual domain of the responsible party, rather than just giving them generic names in your domain, unless you really want to act as an abuse report gateway for your clients. HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
