From: Albert Chin (postfix-usersmlists.thewrittenword.com)
Date: Sun Jan 06 2008 - 22:31:07 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

A friend of mine came up with an idea for a DNS-based alias whitelist,
somewhat the reverse of a DNS IP black list. Say domain example.com
has two valid email addresses:
  johnexample.com
  doeexample.com

example.com has two MX records, one administered by the example.com
admin, and the second administered by someone else. The example.com
admin creates dnsawl.example.com with:
  $TTL 3600
  ;
   IN SOA ns.example.com. hostmaster.example.com. (
                          1 ; Serial
                          60 ; Refresh
                          300 ; Retry
                          3600 ; Expire
                          60 ) ; Minimum

                          IN NS ns.example.com.
                          IN NS ns.colleague.com.

  john IN A 127.0.0.1
  doe IN A 127.0.0.1

So, if mail comes in to example.com, and
[recipient name].dnsawl.example.com exists, smtpd on example.com
accepts the mail. On a standalone smtpd server, the above is easy to
do with:
  smtpd_recipient_restrictions =
    check_recipient_access hash:[PATH]/recipient-access,
    reject

So, why go through the trouble of moving the recipient-access table to
DNS? When mail arrives at a secondary MX for example.com, like
mx.colleague.com, it will store and later forward the mail to the
primary MX for example.com, regardless of whether or not the address
is valid for example.com. By moving the recipient-access table to DNS,
ns.example.com and ns.colleague.com can share the list of valid
recipients through a private dnsawl.example.com DNS table. A Postfix
policy service daemon would then be used to validate the email
address. So, secondary MX's outside of your direct control can now
deny invalid addresses for mail domains they are not the final
destination for. The rationale behind DNS is simply as a transport,
rather than ssh/ftp/http'ing [PATH]/recipient-access around between MX
servers, and making sure the secondary MX servers have the most recent
copy.

I'm curious what folks think about this. I already have the above
working with a sample policy server daemon. A simple gethostbyname()
validates the recipient email address. The postfix dnsawl policy
daemon is smart enough to check h_errno == HOST_NOT_FOUND before
returning a 554 error, else it returns 'dunno'. With `dnsawl',
secondary MX's now have more intelligence, and are trusted to deny
possibly valid recipients for your domain, hence the small values in
the SOA record above. This trust does make me somewhat leery about
implementing this, but anyone acting as secondary MX for a domain has
as much control as they want anyway.

--
albert chin (chinathewrittenword.com)

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]