ietf-822
[Top] [All Lists]

Re: authenticating the source of mail

2002-05-17 10:36:51


More thinking on this, probably the best approach here is to define a
flags sub-field in the MS RR, which allows for domain indirection.

Two flags which could be used right away:

   bit 1 off=value refers to a host
          on=value refers to a domain

   bit 2 off=use A/AAAA RRs associated with value
          on=use MX RRs associated with value

Combining these flags would allow for various functions, with a minimal
amount of overhead. Some examples below.

Use the IP addresses associated with outbound.example.com as the
authorized relay servers for example.com:

 [Answer Section]
  example.com.           MS   0   outbound.example.com.

 [Additional-Data Section]
  outbound.example.com.  A    10.0.0.3


Use the MX RRs associated with mail.example.com as the authorized relay
servers for example.com:

 [Answer Section]
  example.com.           MS   3   mail.example.com.

 [Additional-Data Section]
  mail.example.com.      MX   5   mx-1.example.com.
  mail.example.com.      MX   5   mx-2.example.com.
  mx-1.example.com.      A    10.0.0.1
  mx-2.example.com.      A    10.0.0.2

[note that the MX RRs would not be provided in the Additional-Data section
if a query for ALL resulted in them being provided in the Answer section
of the response]


Any and all hosts in the mail.example.com domain are authorized relay
servers for example.com:

 [Answer Section]
  example.com.           MS   1   mail.example.com.

 [Additional-Data Section]
  <empty>

[the PTR for the current mail session should be examined, and if it
resides within the specified domain, then it is authorized]


These could also be cumulative. EG, use the IP addresses associated with
outbound.example.com PLUS the MX RRs associated with the mail.example.com
domain as the authorized relay servers for example.com:

 [Answer Section]
  example.com.           MS   0   outbound.example.com.
                         MS   3   mail.example.com.

 [Additional-Data Section]
  outbound.example.com.  A    10.0.0.3
  mail.example.com.      MX   5   mx-1.example.com.
  mail.example.com.      MX   5   mx-2.example.com.
  mx-1.example.com.      A    10.0.0.1
  mx-2.example.com.      A    10.0.0.2


The benefit of this approach is that it allows for sender-based
customization of the interpretation (hosts vs MX lists), but minimizes the
risk of overloads. The above needs more smoothing out but I think it is
workable.

Any other flags which would be useful? Any comments on this approach?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/