9 reasons for dynamic authorization records

And here is the second part of the list of arguments.

There are two types of dynamically generated server
replies:

- Either a plain record is generated which is to be interpreted
  by the MTA, but generated at the query time.

- Or the MTA passes all information needed for the decision to the
  server and the server answers "allowed" or "forbidden", thus
  completely hiding the authorization mechanism.


This is not a required mechanism, this is just an option for 
those who want to use it. Those who prefer to have a static
record just put it on the web server like any regular file.


Reasons to do so:


* I received several comments to my RMX draft from people who 
  do not want to publicly reveal their relay structure for
  different reasons. This method allows to hide them.


* Current DNS based proposals make it difficult to verify
  the full e-mail address and not just the domain part.
  
  E.g. a company with 5,000 employees or ISPs with 50,000 customers
  would have to update their zone file every second if the wanted 
  to support their traveling employees/customers. And you don't want
  to have zone files with 50,000 entries. The DNS synchronization
  mechanism between primary and secondary does not support this
  (i.e. only latest versions support differential updates).

* This can be easily adapted to any site-specific authorization 
  scheme. You need to lookup the current authorization state
  only when an e-mail is actually sent and don't need to 
  update your zone tables every time a user logs in or out.

* The reply and it's expiry/validity can depend on more than just the
  sender address, e.g. the recipient address, the message-id, the
  content-type, the receiver's country and legislation.

* The domain owner can detect statistical anomalies and find
  mass mailings, open relays, worm and virus infections, etc.
  It can optionally block hosts which are considered to be
  infected.

* records can depend on who is logged in into a particular
  machine without the need to have distinct DynDNS entries for 
  every user.

* In case of forgery, the owner of the e-mail address can be 
  informed immediately.

* better control over dynamic processes. E.g. if a user
  lost connection without explicitely logging out, the server
  can turn off authorization after a given timeout.

* The server can support multiple formats and versions.
  The MTA just needs to provide a list of supported 
  versions and formats in the request.


  
Hadmut